Executive Summary

Adversary-in-the-middle phishing built its reputation on Microsoft 365. The reverse-proxy kits that dominate public reporting — Tycoon 2FA, EvilProxy, and their successors — are overwhelmingly documented against Entra ID sign-in. A campaign Datadog Security Research observed between June 16 and 19, 2026, is a reminder that the mechanic was never Microsoft-specific. It targeted the AWS Management Console.

Three domains registered inside a 48-hour window impersonated the AWS login page and used an AiTM design to capture credentials and second factors in real time. The kit did not clone AWS and hope; it relayed the victim's sign-in to the genuine AWS backend, read which MFA method the account actually used, and presented the matching prompt. Targeting was narrow and deliberate: fewer than fifty recipients, primarily US-based software engineers and engineering leadership, which points to a curated list rather than a spray campaign. The kit's plumbing links it to the `input_24` / PoisonSeed lineage active since mid-2025 — the same architecture previously pointed at cryptocurrency wallets and Salesforce, now retooled for cloud infrastructure credentials. For defenders, the takeaway is that console access is a phishable identity surface, and AiTM detection cannot stop at the Microsoft boundary.

AttackAttack Overview

The kit's flow reads like a Microsoft 365 AiTM kit with the target swapped. A victim who reaches the phishing domain is first validated server-side. The page carries an encrypted `input_24` URL parameter encoding the intended target's email; the backend checks that parameter before rendering anything, so a sandbox or researcher arriving without a valid, expected value is served nothing analyzable. This is the same anti-analysis gate the PoisonSeed kit family used to confirm a real target before showing a login form.

When a validated victim submits credentials, they go to the kit's `/api/login` endpoint, and the backend relays them to the legitimate AWS sign-in to determine the account's MFA configuration. The server's response tells the phishing page which second-factor path to display — `/email`, `/sms`, or `/gauth` — which is only possible because the kit is in live conversation with the real AWS backend. The victim then supplies the second factor, which, together with the credentials, is forwarded to an `/api/auth` endpoint. The kit captures second factors delivered by email, SMS, or a TOTP authenticator, completing the exchange and leaving the operator with authenticated session material for the console.

AttackInfrastructure & Tradecraft

The three domains — `us-west-login[.]com`, `us-east-prod[.]com`, and `loginportal-aws[.]com`, along with AWS-themed subdomains such as `aws.us-west-login[.]com` — were registered June 16 through 18 through the registrar NICENIC INTERNATIONAL GROUP and fronted by Cloudflare. The naming leans on plausible-sounding AWS regional and environment terms rather than obvious typosquats, consistent with the broader operator trend away from hyphenated look-alikes toward keyword-and-subdomain constructions that evade automated brand-impersonation matching.

The tradecraft is notable less for novelty than for portability. The `input_24` encrypted-parameter design, the server-side victim validation, the React-style front end, and the real-time MFA-path relay are the same building blocks NVISO documented in the PoisonSeed kit in August 2025, when the target was crypto and CRM logins and related domains impersonated Salesforce and SendGrid. Reusing that architecture against AWS required changing the impersonated brand and the relay target, not rebuilding the kit. That reusability is the story: an AiTM chassis proven against one identity provider is cheap to point at the next.

The curated targeting reinforces the intent. Fewer than fifty recipients, concentrated among US software engineers and engineering leaders, is a profile aimed at people who hold console and IAM access, not at volume. Console credentials from an engineering lead are worth more per target than a mailbox, and the narrow list reflects that.

DetectionDetection Opportunities

The console is instrumented; the trick is treating its sign-in telemetry the way you already treat Entra sign-in logs. CloudTrail records console authentication as `ConsoleLogin` events, including whether MFA was used via `additionalEventData.MFAUsed`. A stolen-session takeover typically surfaces as a `ConsoleLogin` from infrastructure and geography inconsistent with the user's normal pattern, often shortly after the legitimate sign-in the AiTM proxy relayed. Impossible-travel logic over `ConsoleLogin` events — the same 500km/1000km-per-hour class of rule defenders run elsewhere — flags both the MFA and non-MFA variants of this pattern.

The highest-fidelity correlation joins two data sources: DNS or proxy logs showing a user's host resolving one of the phishing domains, followed by an anomalous `ConsoleLogin` for that user. The DNS hit establishes exposure; the subsequent console session from unexpected infrastructure establishes likely takeover. Hunt the six phishing domains and their subdomains in resolver logs, and alert on `ConsoleLogin` events that follow a resolution of an untrusted AWS-themed domain.

// Correlate exposure (DNS to an AWS-themed phishing domain) with a
// subsequent anomalous console sign-in. Adapt table/field names to your
// CloudTrail + DNS pipeline; the pattern is exposure-then-login, not a
// single static IOC.
let phishDomains = dynamic(["us-west-login.com","us-east-prod.com","loginportal-aws.com"]);
DnsEvents
| where QueryName has_any (phishDomains)
| project ExposureTime = Timestamp, DeviceName, User = AccountName, QueryName
| join kind=inner (
    CloudTrailConsoleLogin
    | where EventName == "ConsoleLogin"
    | project LoginTime = Timestamp, User = UserIdentityUserName,
              SourceIP = SourceIpAddress, MfaUsed = MFAUsed, AwsRegion
  ) on User
| where LoginTime between (ExposureTime .. (ExposureTime + 2h))
| project ExposureTime, LoginTime, User, DeviceName, QueryName,
          SourceIP, MfaUsed, AwsRegion

ValidationValidation Workflow

Confirm the console side is actually observable before relying on it. In an authorized AWS account, verify a multi-Region CloudTrail is capturing `ConsoleLogin` events with the `MFAUsed` field populated, and that those events reach your detection pipeline with source IP and region intact. A detection that assumes console sign-in telemetry you are not actually collecting is a gap dressed as a control.

Then exercise the correlation. From a test host, generate a DNS resolution to a benign stand-in domain on your watchlist and a console sign-in for a test principal, and confirm the exposure-then-login join fires within the time window. Separately, validate that phishing-resistant MFA on console access behaves as intended: a FIDO2 security key or passkey registered against the real AWS origin cannot be satisfied by a proxy sitting at a different domain, so confirm your privileged principals are enrolled and that fallback factors are not quietly available. Keep this to authorized accounts and test principals; the objective is proving detection and MFA posture, not standing up a working relay.

GapsEvasion & Gaps

The kit's design targets the analyst as much as the victim. Server-side validation via the encrypted email parameter means the phishing page shows nothing to a crawler or sandbox that lacks a valid target value, which slows sample collection and automated verdicts. Short-lived domains behind Cloudflare rotate faster than blocklists propagate. And because the victim completes a real sign-in and a real MFA challenge, the authentication succeeds legitimately from AWS's perspective — there is no failed-login signal to catch, only an anomalous successful one.

The gaps that remain are the ones defenders can close deliberately. Any second factor that a proxy can relay — SMS, email codes, TOTP — is defeated by this design, so their presence gives false comfort on console access. Detection that watches only email or only Entra sign-in will not see an AWS console takeover at all. And environments that treat the console as an internal, low-risk surface tend to under-instrument it, leaving the very `ConsoleLogin` telemetry this attack is caught by uncollected.

Defensive Recommendations

Extend the AiTM playbook to every browser-based identity provider, starting with the cloud consoles. Require phishing-resistant MFA — FIDO2 security keys or passkeys — on AWS console and IAM access for engineers and administrators, because origin-bound authentication is the control a reverse proxy cannot satisfy regardless of which brand it impersonates. Where full rollout is in progress, prioritize principals with IAM, billing, and production access.

Instrument the console like an inbox. Ensure a multi-Region CloudTrail captures `ConsoleLogin` events into your detection pipeline, run impossible-travel and new-source-infrastructure logic over them, and correlate with DNS exposure to AWS-themed look-alike domains. Feed the campaign's domains and the `input_24` / PoisonSeed lineage into resolver and proxy blocklists, but treat those as perishable and lean on the exposure-then-anomalous-login pattern for durability. Finally, brief the engineers who are the target profile: the lure is a convincing AWS sign-in, the MFA prompt will be the real one for their account, and a security key is what makes the difference between a relayed session and a blocked one.