AiTM Phishing Kit Targets AWS Console Credentials and MFA Codes in Real Time

A targeted adversary-in-the-middle phishing kit has been used to steal AWS console credentials and multi-factor authentication codes in real time. The campaign copied the AWS sign-in experience and relayed victim inputs through attacker-controlled infrastructure before victims could easily spot the fraud.

According to Datadog Security Labs, the AWS phishing activity was observed between June 16 and June 19, 2026. The three AWS-themed domains were registered within the same 48-hour window through NICENIC INTERNATIONAL GROUP CO., LIMITED and hosted on Cloudflare.

The campaign matters because it did not rely on simple password collection. It used an AiTM flow that could capture second-factor codes from email, SMS, or authenticator apps, giving attackers a short but dangerous window to access the AWS console.

How the AWS AiTM phishing campaign worked

The phishing sites served a near-identical copy of the AWS console sign-in page. A victim who clicked a crafted link would see what looked like the normal AWS login flow, including prompts for root or IAM user credentials.

The kit’s main logic lived inside a single JavaScript file. The page read an encrypted value from the URL parameter input_24, sent it to the attacker’s server, and only displayed the fake AWS login page when the visitor matched a known target.

That filtering made the operation harder to inspect. Security scanners, sandboxes, and researchers who did not have a valid target link could receive a blank page instead of the phishing form.

Campaign element	What researchers observed
Target platform	AWS Management Console sign-in
Technique	Adversary-in-the-middle phishing
Target validation	Encrypted email gating through the input_24 URL parameter
MFA support	Email, SMS, and time-based one-time password flows
Hosting	Cloudflare-hosted domains registered through NICENIC

Why this phishing kit is more dangerous than older fake login pages

Traditional phishing pages often collect passwords and store them for later use. This kit works differently. It appears designed to relay login details and MFA responses while the victim is still interacting with the fake site.

The Datadog report says the server-driven flow could branch to the right second-factor page based on the victim’s account, including email, SMS, or authenticator-app challenges. That behavior indicates active interaction with the legitimate AWS sign-in process.

This is the core risk with AiTM phishing. A user may enter the correct password and a valid MFA code, while the attacker relays those values to the real service quickly enough to complete the login.

The campaign used email gating and trusted delivery services

Datadog found evidence that the phishing emails impersonated AWS Support and referenced a fake bandwidth-throttling issue. The message created urgency, which is a common way to make targets click before checking the domain carefully.

The operators also used legitimate sending platforms such as SendGrid and Nimbu. That can help phishing messages pass email authentication checks and reach inboxes more easily than messages sent from obviously suspicious infrastructure.

The targeting appeared selective. Researchers recovered fewer than 50 target email addresses, mostly linked to software engineers and engineering leaders in the United States. That points to a curated operation rather than broad, untargeted spam.

• The phishing page only rendered for preselected targets.
• The fake AWS login flow supported several MFA challenge types.
• The domains used cloud-hosting and newly registered names.
• The email theme tried to create urgency with a fake AWS Support issue.
• The same tooling showed links to SendGrid-themed phishing infrastructure.

SendGrid phishing links show a broader toolkit

Alongside the AWS domains, researchers identified three domains impersonating SendGrid. Those domains shared technical traits with the AWS kit, including a React single-page app structure, encrypted target validation, and support for multiple second-factor flows.

Datadog also linked the input_24 fingerprint to previous activity. The same pattern appeared in older campaigns that targeted cryptocurrency wallets and a Salesforce-themed login page.

That history suggests the AWS campaign was not a one-off build. It appears to be part of a reusable phishing toolkit that operators can adapt across cloud, CRM, email, and cryptocurrency targets.

What AWS logs can reveal after phishing exposure

Security teams should check for successful AWS console logins after any connection to the known phishing domains. AWS documents that CloudTrail logs AWS Management Console sign-in attempts for root users, IAM users, and federated users.

The most important event name to review is ConsoleLogin. AWS examples show that console sign-in events can include details such as source IP address, user agent, login result, and whether MFA was used.

Datadog recommends hunting for DNS or network activity tied to the phishing domains and then checking CloudTrail for successful ConsoleLogin activity. A console login shortly after contact with a phishing site can indicate that credentials and MFA codes were captured and replayed.

Log source	What to search for
DNS logs	Queries to the known AWS and SendGrid phishing domains
Proxy logs	HTTP or HTTPS requests to the phishing infrastructure
AWS CloudTrail	ConsoleLogin events after suspicious domain contact
Identity logs	New locations, unusual user agents, or impossible travel patterns
Email security logs	Messages impersonating AWS Support or warning about throttling

Why phishing-resistant MFA matters

One-time passwords still help against many attacks, but AiTM phishing can reduce their effectiveness by relaying the code in real time. That is why AWS recommends phishing-resistant MFA such as passkeys and security keys whenever possible.

AWS explains that FIDO-based authenticators use public key cryptography and resist phishing, man-in-the-middle, and replay attacks better than time-based one-time password methods. For high-value cloud users, that distinction matters.

Organizations should prioritize passkeys or security keys for administrators, engineers, security staff, root users, and other accounts with privileged access. TOTP-based MFA can remain an interim control, but it should not be the final layer for sensitive AWS console access.

IAM controls should limit damage if one account is phished

Stopping the phish matters, but reducing blast radius matters too. AWS recommends that organizations apply least-privilege permissions, use roles for human users and workloads where possible, and require MFA where IAM or root users remain necessary.

The AWS IAM best practices guidance also recommends temporary credentials over long-term credentials where possible. That can reduce the value of stolen credentials and make unusual access easier to manage.

Security teams should review which users can access the AWS console directly, whether those users still need that access, and whether their permissions match their current job duties. Phished credentials become more damaging when the account has broad permissions.

• Use phishing-resistant MFA for privileged AWS users.
• Review IAM policies for least-privilege access.
• Move human access to IAM Identity Center where appropriate.
• Require MFA for root and IAM users that still need console access.
• Alert on ConsoleLogin events from new countries, VPNs, or unusual user agents.
• Investigate any AWS login shortly after contact with a known phishing domain.

Indicators of compromise

The following indicators were associated with the AWS and SendGrid phishing activity. Defenders should combine these with behavior-based detections because domains can change quickly.

Type	Indicator	Description
Domain	us-west-login[.]com	AWS phishing domain
Domain	aws.us-west-login[.]com	AWS phishing subdomain
Domain	aws-central.us-west-login[.]com	AWS phishing subdomain
Domain	us-east-prod[.]com	AWS phishing domain
Domain	aws.us-east-prod[.]com	AWS phishing subdomain
Domain	loginportal-aws[.]com	AWS phishing domain not observed with input_24
Domain	switch-sglogin[.]com	SendGrid phishing domain
Domain	uslogin-prodsg[.]com	SendGrid phishing domain
Domain	sendgrid.uslogin-prodsg[.]com	SendGrid phishing subdomain
Domain	us-west-prod[.]com	SendGrid phishing domain
Domain	sendgrid.us-west-prod[.]com	SendGrid phishing subdomain

How security teams should respond

Organizations should first search DNS, proxy, and secure web gateway logs for the listed domains. Any match should trigger an AWS identity review for the affected user and related accounts.

Next, teams should search AWS CloudTrail console sign-in records for successful ConsoleLogin events near the time of phishing exposure. They should also check for follow-on activity such as IAM policy changes, access key creation, privilege changes, security group edits, and new console sessions.

Finally, organizations should strengthen access controls. AWS recommends passkeys and security keys for stronger protection, while the IAM best practices guide emphasizes least privilege, roles, and temporary credentials where possible.

Bottom line

This AiTM phishing campaign shows that cloud console credentials remain a high-value target, even when MFA is enabled. Attackers increasingly aim to capture the full login flow, not just the password.

The strongest defense combines phishing-resistant MFA, tight IAM permissions, CloudTrail monitoring, domain-based threat hunting, and fast response when suspicious logins appear. For AWS environments, console phishing should now be treated as a direct cloud compromise risk.

Teams that find traffic to the phishing domains should assume the user may have entered credentials and MFA codes. They should investigate immediately, reset affected credentials, review active sessions, and check for any unauthorized AWS activity.

FAQ