This guide explains how a new adversary in the middle phishing kit clones the AWS console login page to capture usernames passwords and live multi factor authentication codes from targeted software engineers.

Picture a login page that looks exactly like the real AWS console down to every pixel and every word. Now picture that page quietly forwarding your password and your one time code straight to a stranger while you still believe you just signed into your own cloud account. Security researchers at Datadog just uncovered exactly that kind of operation running in June 2026 and it targets the kind of accounts that hold the keys to entire cloud infrastructures.

AWS Console AiTM Phishing Kit Technical Explanation

Datadog Security Research found a batch file on VirusTotal that worked as a validation script for this campaign. The script pinged a fake testing domain and ran curl commands against a phishing domain called aws dot us west login dot com along with a SendGrid link built to point toward that same fake page.

The same file also held the structure of a phishing email pretending to come from AWS Support and complaining about a fake bandwidth throttling ticket. This sort of detail shows genuine thought behind a hook and not a quick copy paste job.

The operators sent these phishing emails through legitimate platforms such as SendGrid and Nimbu. Using trusted email infrastructure helps messages pass authentication checks and slip past spam filters far easier than a message sent from a random unknown server. Once a victim clicks the link they land on a page built to clone the actual AWS console sign in screen pixel for pixel.

The entire credential harvesting logic sits inside one single JavaScript file and this file carries adversary in the middle capabilities strong enough to intercept second factor codes sent through email SMS or a time based one time password app.

The page works through a clever gating system before showing anything at all. When the page first loads it reads a URL parameter named input underscore 24 and pulls out an encrypted base64 blob from it. That blob gets sent through a POST request to an endpoint called slash api slash check. The server then decrypts the blob behind the scenes turns it into a target email address and stores that email inside a cookie named validEmail.

A second call to slash api slash me reads that cookie back and returns the victim email in plain JSON form. Only after this whole exchange succeeds does the page decide whether to render the fake AWS login screen or simply show a blank page instead.

This gating trick matters far more than it looks at first glance. Security researchers and automated sandboxes scanning the link without a valid target email attached will only ever see a blank page and walk away thinking nothing malicious exists there. The kit essentially refuses to show its real face unless the visitor matches a pre approved target on a curated list built around specific email addresses.

Once a victim enters their root or IAM credentials the form sends everything to an endpoint called slash api slash login. The server response includes a type field and the page navigates to whichever path matches that type whether that path leads to email sms or gauth.

This detail carries huge weight because the only way the phishing server could possibly know which verification method belongs to that specific account comes from actually talking to the real AWS sign in flow behind the scenes in real time. Each of those three verification pages carries copy tuned almost word for word to match the real AWS prompts such as confirm you are you or additional verification required.

Once the victim types in their verification code the page forwards everything including the account ID username password and that code to a final endpoint called slash api slash auth. From there the server again decides the next route which strongly suggests the phishing infrastructure relays stolen credentials to the real AWS console behind the curtain and waits for AWS to respond before showing the victim what to do next.

Datadog researchers also found three related domains built to impersonate SendGrid itself registered between June 16 and June 18 2026 through the same registrar and hosted on Cloudflare. These domains share matching technical fingerprints with the AWS kit including a React based single page app and the same encrypted email gating logic only using a parameter called email instead of input underscore 24.

This pattern strongly resembles a phishing kit documented by NVISO Labs back in August 2025 known for impersonating SendGrid and other CRM platforms. The fingerprint built around the input underscore 24 parameter actually traces back even further since a version of this same kit targeted cryptocurrency wallets such as Trezor and Ledger starting around July 2025 and even cloned a Salesforce login page under a domain called dashboard salesforce dot com using the exact same gating function.

AWS Phishing Campaign Detection Indicators And Hunting Guide

Because the kit only renders for pre validated email addresses Datadog managed to confirm fewer than fifty actual target addresses during their analysis. This small curated number points toward a deliberate and targeted operation rather than a mass spam blast aimed at random internet users.

Most identified targets sat inside the United States and most held job titles tied to software engineering and engineering leadership roles which lines up perfectly with accounts likely to hold real AWS console access.

Defenders running cloud security monitoring can hunt for DNS activity reaching out toward known phishing domains such as us west login dot com aws dot us west login dot com aws central dot us west login dot com loginportal aws dot com and us east prod dot com along with their subdomains.

Any match found through DNS or network logs should immediately trigger a deeper look into CloudTrail logs filtered for ConsoleLogin events. A successful ConsoleLogin event following contact with one of these domains strongly suggests a threat actor captured and replayed stolen credentials against the real AWS environment.

Security teams using Datadog Cloud SIEM already get built in detection rules covering AWS ConsoleLogin events that trigger impossible travel scenarios both with and without MFA enabled. These rules catch the exact kind of behavior this campaign produces since a stolen session replayed from attacker infrastructure naturally creates a login pattern that looks geographically impossible compared to the real user.

AWS Console Phishing Mitigation And Defense Strategy Guide

The biggest mistake many organizations still make involves treating AWS console phishing as a secondary risk compared to stolen access keys. Datadog internal telemetry along with wider public reporting both confirm that access key theft dominates most AWS credential compromise cases. This campaign proves that username and password phishing against the console itself remains very much alive and now comes packaged with real time MFA relay capability that traditional credential harvesting pages never had.

Organizations should treat any phishing email referencing AWS Support tickets bandwidth throttling or urgent account action with heavy suspicion especially when the email arrives through a trusted third party sending platform.

Security awareness training should specifically call out that legitimate AWS support communication never asks users to click through external login portals to resolve billing or throttling concerns. Enforcing hardware based security keys for AWS root and IAM accounts rather than relying purely on SMS or TOTP codes removes the biggest weakness this kit depends on since hardware keys cannot get relayed through a phishing proxy the same way a typed code can.

Cloud security teams should also enable continuous monitoring for impossible travel patterns tied to ConsoleLogin events and pair that with strict conditional access policies that flag logins from unexpected geographic regions or unfamiliar devices. Rotating credentials immediately after any suspected phishing click and reviewing CloudTrail history around that timeframe gives defenders a fighting chance to catch session replay before real damage spreads across connected cloud resources.

This entire campaign sends one clear message to every organization running critical infrastructure on AWS. A phishing kit built with this much precision targeting specific engineers by name proves that attackers now study their cloud targets just as carefully as defenders study their own environments. The only real answer comes from treating every login page request with healthy suspicion and building defenses that assume credentials alone will eventually get stolen no matter how careful any single employee tries to stay.