Latest / The Digital Warfare Podcast / Digital Warfare Podcast Daily Brief June 25, 2026
Transcript
- Digital Warfare: You're listening to the Digital Warfare Podcast. Today we are covering an active phishing campaign that bypasses multi-factor authentication by operating as a real-time intermediary between victims and AWS authentication servers. This is not a vulnerability in AWS. This is an architectural failure in human authentication. Here is what happened. Between June 16th and 19th, 2026, Datadog security research identified a coordinated phishing campaign targeting fewer than 50 AWS focused individuals, primarily software engineers based in the United States. The campaign was highly selective, not mass phishing. Three domains were registered within a 48 hour window through the Registrar Nicenic International Group and hosted on Cloudflare. Each domain served a near identical clone of the AWS Management Console sign in page. The sophistication lies not in the clone itself. But in how the kit handles authentication behind it. This is where Adversary in the Middle or AITM becomes the critical attack mechanism. Here is the technical flow. When a victim submits their username and password to the fake AWS page, the phishing server does not store those credentials locally. Instead, it relays them directly to the legitimate AWS authentication endpoint in real time. AWS processes the login attempt and responds with the specific multifactor authentication challenge required for that account. The phishing server now knows exactly which second factor to display to the victim. Is it an email code, an SMS text message, a time-based authenticator app token? The phishing page adapts its interface on the fly to prompt for whichever second factor AWS demanded. When the victim enters their MFA code, the phishing server captures it and relays it to AWS simultaneously. AWS validates the complete authentication sequence. The victim is logged in. But the attacker now holds the session. They have captured the credentials. The MFA code and the authentication tokens that AWS issued. The legitimate AWS session belongs to the attacker. The targeting mechanism reveals operational discipline. The phishing kit used a parameter called input underscore 24 to gate access to the fake AWS page. This parameter contained an encrypted identifier that the server decrypted to determine if a specific target should see the phishing page or a blank page. This exact input underscore 24 mechanism has been active since July 2025 and has previously been deployed against cryptocurrency wallets like Trezor and Ledger and Salesforce credentials. This is a reused battle-tested kit. Delivery relied on legitimate email marketing services. Sengrid and Nimbo are trusted platforms. Emails routed through these services pass SPF, DKIM, and DMARC authentication checks. Phishing emails arrived in victims' inboxes as if they were genuine AWS organization security emails. The time between credential submission and active account compromise was shockingly brief. In one observed case, the attacker authenticated to the compromised AWS console within 20 minutes of the victim entering their credentials. The source IP was 185.209.196.132, a MOLVAD VPN egress node. This suggests either an automated credential testing pipeline or an operator actively monitoring an admin dashboard and immediately testing captured credentials. The impact depends on the compromised account's permissions. A WS console access for a DevOps engineer or cloud administrator can provide visibility into cloud infrastructure, stored data, running workloads, and identity configurations. Attackers could view sensitive data, modify cloud resources, deploy additional infrastructure. Or create new identity and access management roles for persistence. Here is what you do immediately. First, treat AWS console phishing as an active threat, not a secondary concern. Monitor Cloud Trail for console login events originating from unexpected IP addresses or VPN infrastructure. Second, implement phishing-resistant multi-factor authentication. FIDO2 hardware security keys cannot be phished through AITM proxies. Because the authentication challenge is cryptographically bound to the legitimate AWS domain. Authenticator apps and SMS are insufficient. Third, enable conditional access policies that flag successful console logins from uncommon geographic locations or non-corporate IP ranges within minutes of phishing submission. Fourth, educate technical teams about AITM phishing. This campaign targeted software engineers who understand technology. Traditional fishing awareness does not cover this attack because the authentication really does succeed. This has been your Digital Warfare Daily Brief. Stay secure, we'll see you tomorrow.