Password Spraying Campaign Targets AWS Root User Accounts Across 150+ Organizations
Password Spraying Campaign Targets AWS Root User Accounts (TL-2026-2263) is a medium-severity cloud security threat, first published 2026-08-31. It has no confirmed attribution, affects Amazon Web Services AWS Account Root User Console Sign-In (IAM, maps to 10 MITRE ATT&CK techniques (T1078.004, T1090.002, T1110), and is covered by 9 detection rules and 7 indicators of compromise.
Key facts for TL-2026-2263
- Threat ID
- TL-2026-2263
- Severity
- MEDIUM
- Status
- ACTIVE
- Category
- CLOUD
- First published
- 2026-08-31
- Last reviewed
- 2026-08-31
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Detection rules
- 9
- Indicators of compromise
- 7
Malware and tooling in Password Spraying Campaign Targets AWS Root User Accounts
Malware and tooling: Datadog Cloud SIEM — 'AWS root account activity' default detection rule, Datadog Cloud SIEM — 'Potential brute force attack on AWS ConsoleLogin' default detection rule, Elastic Security — 'AWS Management Console Brute Force of Root User Identity' prebuilt rule
Datadog Security Labs identified a password-spraying campaign that made repeated failed ConsoleLogin attempts against AWS account root-user credentials at 150+ organizations between July 24 and August 23, 2026. The activity required the target's root-user email address, was routed through distributed proxy/hosting infrastructure, and produced no successful authentications or discernible victimology pattern.
How Password Spraying Campaign Targets AWS Root User Accounts works
Between July 24 and August 23, 2026, Datadog Security Labs observed a password-spraying campaign against the AWS account root-user console sign-in flow at more than 150 organizations. The campaign exploited a structural quirk of AWS's authentication API: generating a failed `ConsoleLogin` event (CloudTrail event name `ConsoleLogin`, provider `signin.amazonaws.com`, event type `AwsConsoleSignIn`) for the root user requires the caller to already know the account's registered root-user email address. Attackers either worked from a pre-compiled list of root-user emails or ran enumeration attacks to validate which addresses corresponded to real root accounts, then repeatedly submitted authentication attempts against each. Attempt volume per organization was low and slow — a median of two attempts, with some organizations seeing up to eight — consistent with a password-spraying (low-and-slow, many-targets) pattern rather than a high-volume brute-force against a single account.
Requests were routed through third-party proxy infrastructure; source IPs were flagged by threat intelligence as hosting infrastructure, residential proxies, or similar, and spanned a wide range of countries and ASNs with no single dominant origin. Only two distinct browser user-agent strings were logged across the failed attempts (a Chrome/Edge-on-Windows string and a Firefox-on-Windows string), suggesting a constrained, possibly scripted or shared tooling set behind the requests despite the distributed source infrastructure.
No successful root-user authentication was observed at any of the 150+ affected organizations across the full campaign window, and Datadog found no clear victimology: targets varied widely by country and industry with no discernible sector or geographic concentration. Datadog explicitly states it cannot conclusively determine the actor's motive, and no attribution to a known threat actor, group, or toolset is offered.
Datadog's own detection guidance for this exact activity is a Cloud SIEM query — `source:cloudtrail @userIdentity.type:Root @eventName:ConsoleLogin @responseElements.ConsoleLogin:(Failure OR Success)` — layered across two existing default detection rules: 'AWS root account activity' (tiers Critical for TI-flagged malicious IPs, High for a successful root console login, Medium for sensitive-service writes or suspicious-IP activity, Low for ≥5 failed logins within 5 minutes; mapped to TA0001/T1078) and 'Potential brute force attack on AWS ConsoleLogin' (group-by correlation of failed `ConsoleLogin` attempts, mapped to TA0006/T1110, last revised 2023-07-10). Elastic Security ships an equivalent prebuilt rule, 'AWS Management Console Brute Force of Root User Identity' (KQL: `data_stream.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:failure`; High severity, risk score 73, 6-minute threshold window, capped at 100 alerts per execution, mapped to TA0006/T1110/T1110.001), which independently corroborates that root-ConsoleLogin brute-forcing is a recognized, pre-existing detection use case this campaign fell squarely into.
The campaign lands against a backdrop of AWS's multi-year push to lock down root-user authentication: staged MFA enforcement for root users (standalone accounts from mid-2024, AWS Organizations management accounts from May 2024, and member accounts from June 2025 with a 35-day registration grace period) and the November 2024 launch of Centralized Root Access Management (STS `AssumeRoot`), which lets organizations strip long-term root credentials entirely and broker short-lived, task-scoped root sessions (e.g. `IAMCreateRootUserPassword`, `IAMDeleteRootUserCredentials`, `IAMAuditRootUserCredentials`, `S3UnlockBucketPolicy`, `SQSUnlockQueuePolicy`) instead. Because root retains unrestricted, unrestrictable access to every AWS service in the account — including billing, GovCloud sign-up, KMS key recovery, and clearing misconfigured S3/SQS resource policies that deny all principals — any organization that had not yet migrated off long-lived root credentials and hardware/FIDO2 MFA remained a viable target for this style of attack even though no compromise was confirmed in this campaign.
MITRE ATT&CK techniques used in TL-2026-2263
Initial Access
T1078.004 Valid Accounts: Cloud Accounts
command-and-control
T1090.002 Proxy: External Proxy; T1665 Hide Infrastructure
Credential Access
T1110 Brute Force; T1110.001 Brute Force: Password Guessing; T1110.003 Brute Force: Password Spraying
Resource Development
T1583.003 Acquire Infrastructure: Virtual Private Server; T1583.005 Acquire Infrastructure: Botnet; T1588.002 Obtain Capabilities: Tool
Reconnaissance
T1589.002 Gather Victim Identity Information: Email Addresses
Affected products and versions in Password Spraying Campaign Targets AWS Root User Accounts
- Amazon Web Services — AWS Account Root User Console Sign-In (IAM ConsoleLogin / AwsConsoleSignIn)
Vulnerable versions: All AWS accounts (standalone, AWS Organizations management, and member accounts) that retain a directly usable root-user email/password and have not migrated to Centralized Root Access Management
Fixed in: Not a patchable vulnerability — mitigated operationally via hardware/FIDO2 MFA enrollment on root, AWS Centralized Root Access Management (STS AssumeRoot), and service control policies restricting direct root activity
Remediation for Password Spraying Campaign Targets AWS Root User Accounts
Immediate actions
- Alert on any CloudTrail ConsoleLogin event (success or failure) where userIdentity.type = Root, using Datadog's query source:cloudtrail @userIdentity.type:Root @eventName:ConsoleLogin @responseElements.ConsoleLogin:(Failure OR Success), or the equivalent Elastic KQL rule (data_stream.dataset:aws.cloudtrail and event.provider:signin.amazonaws.com and event.action:ConsoleLogin and aws.cloudtrail.user_identity.type:Root and event.outcome:failure).
- Review CloudTrail for existing failed root ConsoleLogin attempts across all accounts in the AWS Organization to determine if the organization was already targeted; Datadog's default rule flags Low severity at >=5 failures within 5 minutes and Critical when the source IP is threat-intel-flagged.
- Confirm hardware or FIDO2-based MFA is enrolled and enforced on every root user, including newly created member accounts still inside the 35-day grace period.
Workarounds
- Where AssumeRoot migration is not yet complete, enforce hardware MFA on root and monitor ConsoleLogin failures as a compensating control.
Longer-term hardening
- Adopt AWS Centralized Root Access Management (STS AssumeRoot) to remove long-lived root credentials and root password/MFA setup from member accounts entirely, replacing direct root sign-in with short-lived, task-policy-scoped AssumeRoot sessions.
- Deploy AWS Organizations service control policies that deny direct root-user activity in member accounts except through the centralized/AssumeRoot path.
- Establish continuous monitoring and alerting on all root activity — sign-ins, credential changes, and API calls — not just failed logins, and extend the same monitoring to sts:AssumeRoot events once centralized root access is adopted.
- Restrict knowledge/discoverability of root-user email addresses where feasible (dedicated, non-guessable mailbox aliases; avoid reuse of predictable corporate email patterns for the root account).
Timeline of Password Spraying Campaign Targets AWS Root User Accounts
- Datadog updates the group-by fields on its 'Potential brute force attack on AWS ConsoleLogin' default detection rule, the same rule class later used to detect this 2026 campaign's failed root-login pattern.
- AWS publicly announces plans to require MFA for AWS account root users, the first step in a multi-year root-security hardening effort.
- AWS begins enforcing MFA for root users of AWS Organizations management accounts, starting with larger environments.
- MFA enforcement extends to root users of standalone AWS accounts not managed via AWS Organizations.
- AWS launches Centralized Root Access Management (STS AssumeRoot), allowing organizations to remove long-term root credentials and broker short-lived, task-policy-scoped root sessions instead of direct root sign-in.
- AWS extends root-user MFA enforcement to member accounts within AWS Organizations, with a 35-day grace period for MFA registration after first console sign-in.
- Earliest failed root-user ConsoleLogin attempts attributed to the campaign begin appearing in Datadog customer CloudTrail telemetry.
- Last observed failed root-user ConsoleLogin attempt tied to the campaign; no successful authentication was recorded across the entire window at any of the 150+ affected organizations.
- Datadog Security Labs publishes 'Password spraying campaign targets AWS root user accounts across 150+ organizations,' disclosing the campaign, its telemetry, and detection/mitigation guidance.
Sources cited for Password Spraying Campaign Targets AWS Root User Accounts
- Password spraying campaign targets AWS root user accounts across 150+ organizations
- AWS root account activity (default detection rule)
- Potential brute force attack on AWS ConsoleLogin (default detection rule)
- AWS Management Console Brute Force of Root User Identity
- Exploring AWS STS AssumeRoot
- Multi-factor authentication for AWS account root user
- AWS account root user
- Centralized Root Access in AWS Organizations: Benefits, Considerations, and Best Practices
- Amazon to make MFA mandatory for 'root' AWS accounts by mid-2024
- Amazon: AWS root accounts must have MFA enabled
More in cloud
- OAuth Client ID Spoofing Enables Stealthy Enumeration of Microsoft Entra ID Accounts (UNK_pyreq2323 / UNK_OutFlareAZ)
- Frontier AI Agents Compress Full Enterprise Intrusion Chain into Under 10 Hours (Unit 42 Investigation)
- AWS IAM Privilege Escalation Attack Path via iam:CreateAccessKey, iam:UpdateLoginProfile, and iam:UpdateAssumeRolePolicy (Horizon3.ai NodeZero Case Study)
- AWS SSM Agent Abused as a Living-off-the-Land Remote Access Trojan via Hybrid-Activation Hijacking and Parallel Agent Processes
- GCP Cross-Project Compute Image Exfiltration via Compromised Developer Credentials
Detection coverage for TL-2026-2263
As of 2026-08-31, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2263 across Splunk SPL, Microsoft KQL and Sigma, covering 7 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.