Datadog Security Labs observed password-spraying attempts against the AWS root-user console sign-in flow from July 24 to August 23, 2026, across more than 150 organizations. No successful authentication was observed. The report therefore does not confirm compromises at those organizations or establish the operators’ intent.
Password spraying tries a small number of passwords against many accounts instead of repeating attempts against one identity. Cyber Security News reports that the observed campaign had a median of two attempts per organisation, with some seeing up to eight.
Why the AWS root user is sensitive
The AWS root user has full access to account resources, settings, and billing. AWS recommends using it only for tasks that require root credentials and creating separate administrative identities for daily work. AWS also recommends against creating long-term access keys for root.
What Datadog observed
Datadog notes that a root console sign-in attempt requires the account’s email address. Its report does not establish whether the operators had a prior list or tested addresses. AWS requires MFA to be configured for all root accounts, with a 35-day grace period after the first sign-in attempt to complete registration if it is not already enabled. Datadog does not say whether the observed attempts reached the MFA step or whether MFA blocked any of them.
Datadog also observed failed logins through proxies and two recurring user-agent strings; these can be spoofed and should not be used alone to block access.
Five checks for AWS teams
- Confirm root MFA is enabled and recovery methods are available through a documented process. AWS recommends a passkey or FIDO2 security key wherever possible.
- Look for long-term root access keys and remove any that exist; AWS recommends not creating them.
- Reserve root for rare tasks and use named, appropriately scoped administrative identities for daily work.
- Review root
ConsoleLoginevents in CloudTrail and alert on sign-ins, credential changes, and root activity. - With AWS Organizations, consider removing root credentials from member accounts and using centralized, temporary root access; protect the management account separately.
If you need to replace a root password, create a unique secret using our secure password generation guide. Protect the recovery email too: it is part of the account access path.
Soclyde and privileged access
Soclyde can help store administrator credentials and other human-held secrets used in operations. AWS-specific controls, such as MFA, IAM policies, and CloudTrail logging, remain essential and are not replaced by a password vault. For a root secret, follow AWS guidance: strict business need, multi-person authorisation where possible, and logging of access to its storage.
Our SMB password policy guide helps separate accounts and document responsibilities. For shared credentials, see the secure team password-sharing guide.
The takeaway
This report documents attempts, not confirmed compromises. Review logs, maintain MFA and other AWS controls, and limit root use to tasks that require it. To clarify team responsibilities, see our SMB password policy guide.
