Behind the console: Active phishing campaign targeting AWS console credentials

Key points and observations

• Datadog Security Research identified an active adversary-in-the-middle (AiTM) phishing campaign targeting AWS Console credentials.
• The phishing kit proxies authentication to the legitimate AWS sign-in endpoint in real time, validating credentials before redirecting victims and likely capturing one-time password (OTP) codes.
• We observed post-compromise console access within 20 minutes of credential submission, originating from Mullvad VPN infrastructure.
• This campaign does not exploit AWS vulnerabilities or abuse AWS infrastructure.

Background

Datadog Security Research identified a credential-harvesting campaign targeting AWS Console users through typosquatted domains that mimic AWS infrastructure naming conventions. The operation uses real-time adversary-in-the-middle (AiTM) proxying to capture validated credentials and session material.

We identified two active phishing infrastructure clusters and a third related domain sharing registrar metadata. In one observed case, the operator authenticated to a compromised AWS account within 20 minutes of credential submission.

Campaign overview

All domains share Registrar ID 3254 (CNOBIN INFORMATION TECHNOLOGY LIMITED). Cluster 2 was registered and deployed on the same day we first observed it, indicating rapid infrastructure rotation.

Initial access

We identified a partial screenshot of the phishing email shared publicly in a tweet, our only source for the email content. The phishing URL was observed separately via URLscan.

Because we did not obtain the original email headers, the sender address (noreply@security[.]aws) should be considered spoofed.

The lure impersonates an AWS security notification, claiming:

"AWS Security Hub has detected unusual cross-account IAM role assumption patterns within your AWS Organization."

A public URLscan submission reveals details about how the phishing link was structured.

https://rcxm95cx.r.us-east-2.awstrack.me/L0/https:%2F%2Fpost.spmailtechnolo.com%2F...

The awstrack.me domain is a AWS SES click-tracking domain. This has two benefits for the attacker: increasing the reputation of the link within the email and allowing for the tracking of their phishing campaign.

The victim follows a multi-stage redirect before reaching the phishing page:

1. AWS SES tracking URL (awstrack.me) - click tracked and logged by attacker (unverified, but a reasonable assumption)
2. Redirect post.spmailtechnolo.com (mail service)
3. Redirect (signin.aws.cloud-recovery[.]net/lwWyrgEE) - short-lived URL.
4. Redirect (signin.aws.cloud-recovery[.]net/oauth?)
5. Phishing landing page (signin.aws.cloud-recovery[.]net/signin?...) - credential harvesting page

Technical analysis

AiTM proxying

The phishing page is a high-fidelity clone of the AWS Management Console sign-in page. The kit serves static assets that mirror the legitimate AWS sign-in UI:

• AWS CloudFront-hosted assets (d1.awsstatic.com)
• AWS UI framework stylesheets (awsui)
• Identical copyright footer referencing the current year

The URL structure also mimics the legitimate AWS OAuth flow, including PKCE parameters:

/signin?redirect_uri=https%3A%2F%2Fconsole.aws.amazon.com%2Fconsole%2Fhome
       &client_id=arn%3Aaws%3Asignin%3A%3A%3Aconsole%2Fcanvas
       &code_challenge=hzU4QD5OTEZeurPpybAoADh8GnO_URqBECTzHN4CxkY
       &code_challenge_method=SHA-256

The legitimate-looking client_id ARN and SHA-256 PKCE code challenge make the URL nearly indistinguishable from a genuine AWS authentication request.

The kit functions as a transparent reverse proxy, forwarding credentials to the legitimate AWS endpoint in real time and relaying responses back to the victim. Although we have not confirmed it, the kit likely supports real-time 2FA code capture.

Product pages

Navigating to aws.[domain]/ displays product landing pages resembling legitimate AWS product pages, lending additional legitimacy to the phishing site.

Anti-analysis

The only anti-analysis control we observed is an HTTP redirect triggered by specific URL paths and parameters. The redirect target differs by domain:

• cloud-recovery[.]net redirects to amazon[.]com
• cloud-policy[.]com redirects to aws[.]com

Administrative panel

Both infrastructure clusters expose an administrative panel on TCP port 3000. This panel possibly provides the attacker with:

• Real-time visibility of captured credentials
• Campaign management (active phishing URLs, target lists)

We found two other servers (158.94.208[.]32 and 158.94.211[.]216) running the same administrative panel with associations to recently created domains attempting to impersonate M365 and Apple:

o365signin[.]app
o365login[.]app
o365singin[.]com
oauth-icloud[.]com

These domains are not currently live. However, the common administrative panel could point towards a phishing kit that is shared among multiple actors.

Domain infrastructure

Both domain clusters follow a similar subdomain pattern designed to spoof AWS infrastructure:

All three domains were registered through the same registrar, making it a viable pivot point for identifying additional campaign infrastructure. Several other subdomains mimicking AWS services and regions were present but not observed in active use. A selection:

us-west-2.console.aws.cloud-recovery[.]net
us-west-1.console.aws.cloud-recovery[.]net
us-east-2.console.aws.cloud-recovery[.]net
us-east-1.console.aws.cloud-recovery[.]net
signin.aws.cloud-recovery[.]net
sa-east-1.console.aws.cloud-recovery[.]net
phd.aws.cloud-recovery[.]net
me-south-1.console.aws.cloud-recovery[.]net
eu-west-1.console.aws.cloud-recovery[.]net
eu-south-1.console.aws.cloud-recovery[.]net
eu-north-1.console.aws.cloud-recovery[.]net
eu-central-1.console.aws.cloud-recovery[.]net
console.cloud-recovery[.]net
console.aws.cloud-recovery[.]net
cloud-recovery[.]net
cdn.console.cloud-recovery[.]net
ca-central-1.console.aws.cloud-recovery[.]net
b.cdn.console.cloud-recovery[.]net
aws.cloud-recovery[.]net
ap-southeast-2.console.aws.cloud-recovery[.]net
ap-southeast-1.console.aws.cloud-recovery[.]net
ap-south-1.console.aws.cloud-recovery[.]net
ap-east-1.console.aws.cloud-recovery[.]net
af-south-1.console.aws.cloud-recovery[.]net
a.b.cdn.console.cloud-recovery[.]net

Post-compromise authentication

Within 20 minutes of credential submission, the attacker authenticated to the AWS Console from 185.209.196[.]132, a Mullvad VPN egress node. This rapid turnaround suggests either:

• An automated credential-testing pipeline triggered on submission
• An operator actively monitoring the admin panel and acting on new captures

How Datadog can help

Datadog includes out-of-the-box security rules for monitoring suspicious behavior related to AWS cloudtrail:

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

In addition to this, you can hunt in your own environment for indications of this activity:

• ConsoleLogin events from 178.16.54[.]142 or 69.67.172[.]30

source:cloudtrail @evt.name:ConsoleLogin @network.client.ip:(178.16.54.142 OR 69.67.172.30)

• AWS cloudtrail activity from Mullvad VPN IPs

source:cloudtrail @threat_intel.results.additional_data.tunnels.operator:MULLVAD_VPN

• DNS activity to any of the domains listed in the IoC section.

@ocsf.query.hostname:(*.cloud-recovery.net OR *.cloud-policy.com) OR @dns.question.name:(*.cloud-recovery.net OR *.cloud-policy.com)

Conclusion

This campaign remains active at the time of writing. Infrastructure changes observed on February 26, 2026—including updated redirect logic and expanded anti-analysis controls—indicate continued operator maintenance.

We have reported the identified infrastructure to AWS Security who are coordinating on disruption and takedown efforts.

Defenders should treat this campaign as active. Monitoring CloudTrail authentication events, MFA anomalies, and privilege escalation activity remains critical for detecting credential abuse after successful phishing.

Indicators of compromise

Domains (subset of domains included)