
Password spraying campaign targets AWS root user accounts across 150+ organizations
Datadog Security Research describes a password spraying campaign against AWS root user accounts at more than 150 organizations, running 24 July to 23 August 2026. Attempts came through proxies using two fixed Chrome/Edge and Firefox user agents, with a median of two attempts per organization. No successful logins were seen. The post gives a CloudTrail ConsoleLogin query, a sample failed event, and root user hardening advice (SCPs, centralized root access, AssumeRoot, alerting).
What it is
Datadog Security Research reports a password spraying campaign against AWS root user accounts at more than 150 organizations, running 24 July to 23 August 2026. Organizations saw a median of two failed attempts each, and some saw up to eight. Datadog saw no successful authentication, so the attacker's intent is unknown.
How it works
Requests came through proxies. Source IPs span many countries and ASNs, and threat intelligence flags all of them as hosting infrastructure, residential proxies or similar. Targets show no clear pattern by country or industry.
A failed ConsoleLogin event can only be generated with the root user's email address. So the attacker either held a list of root emails or cycled through candidate emails until one matched. Datadog does not say which.
Preconditions / Affected
Any AWS account with a root user can be targeted. Since June 2025, AWS IAM enforces MFA for root users on all account types, with a 35-day grace period between the first console sign-in attempt and MFA registration. The sample failed event shows "MFAUsed": "No", with LoginTo pointing at the billing console.
What to do
Search CloudTrail for the two campaign user agents. The query also matches successes, so run it to confirm none occurred:
source:cloudtrail @userIdentity.type:Root @eventName:ConsoleLogin
@responseElements.ConsoleLogin:(Failure OR Success)
@userAgent:("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Edg/85.0.564.41" OR "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0")The second user agent is Firefox 120.0 on Windows. The first is Chrome 85 with Edg/85.0.564.41.
Hardening, as the page states it:
- Use AWS Organizations service control policies to block direct root activity in member accounts.
- Use centralized root access to remove long-term root credentials from member accounts. Privileged tasks then run through short-lived AssumeRoot sessions.
- Alert on direct root sign-ins, root API activity, credential changes and centrally initiated privileged sessions in CloudTrail.
Caveats
The two user agents are the only fixed fingerprints, and the source IPs are too varied to block. A different user agent would not match the query. Neither SCPs nor centralized root access protect the organization's management account, whose root credentials need separate safeguards. Datadog invites reports of similar activity at securitylabs@datadoghq.com.
Organisations named here
- AssumeRoot
- ConsoleLogin
Technologies named here
- AWS CloudTrail
- AWS IAM
- AWS Organizations
- AWS Organizations Service Control Policies
- Datadog Cloud SIEM
- AWS
- Datadog
- AWS account root user (console sign-in)
- AWS centralized root access (AssumeRoot)
- AWS IAM multi-factor authentication (MFA)
- Datadog Cloud Security Management
Techniques named here
- Password spraying
- Service Control Policies
- CloudTrail log query for failed root ConsoleLogin events
- Proxy tunneling of authentication requests
- User agent fingerprinting
Related in Threat Intel
Reverse Engineering the Six Stages of MacSync Stealer and RAT
AI-Coded Malware | Analyzing Vibe-Coded AD Enumeration | Huntress
