Listen to this Post
A Quiet Cloud Attack With Potentially Serious Consequences
Cloud security incidents do not always begin with a successful breach. Sometimes, the warning arrives as a handful of failed login attempts—small enough to be overlooked, but coordinated enough to reveal that someone is testing the locks.
That is exactly what security researchers observed in a newly disclosed password-spraying campaign targeting AWS root user accounts at more than 150 organizations. Datadog Security Labs tracked the activity between July 24 and August 23, 2026, identifying repeated failed authentication attempts against highly privileged AWS identities.
So far, researchers have not identified a successful login linked to the campaign. But that does not make the activity harmless.
The campaign demonstrates a familiar cybersecurity reality: attackers do not necessarily need to compromise hundreds of organizations to create significant risk. They may simply need to find one organization where an old password, exposed credential, weak recovery process, or missing security control opens the door.
More Than 150 Organizations Were Tested
Datadog Security Labs observed suspicious authentication activity affecting more than 150 organizations across different industries and geographic regions.
Most organizations saw a relatively small number of attempts, with a median of approximately two attempts. Some organizations recorded as many as eight.
At first glance, numbers like these may appear insignificant. A few failed logins rarely trigger an incident response investigation in isolation.
But the scale changes the picture.
When similar authentication behavior appears across more than 150 organizations during the same period, it becomes much harder to dismiss the activity as random internet noise.
No Confirmed Successful AWS Root Login
One of the most important details is that researchers have not identified a successful login associated with the campaign.
That distinction matters.
A password-spraying campaign can be unsuccessful for several reasons. Organizations may have enforced MFA, used strong passwords, protected root credentials properly, or simply not had their targeted accounts exposed to the attacker.
However, the absence of an observed compromise does not necessarily mean the attacker failed completely.
Security telemetry is rarely perfect, and an attacker can conduct reconnaissance for weeks or months before finding an account that responds differently.
The campaign should therefore be interpreted as a warning signal rather than evidence of mass AWS compromise.
Attackers Hid Behind a Distributed Proxy Infrastructure
Another interesting element of the campaign is the infrastructure used to conduct the authentication attempts.
Rather than relying on one obvious IP address, the attackers used a broad proxy-backed infrastructure to tunnel their requests.
The observed source addresses were spread across multiple countries and autonomous systems. Threat intelligence services associated many of those addresses with hosting providers, residential proxy networks, and other anonymization infrastructure.
This creates an important defensive problem.
Blocking one IP address is unlikely to stop an operation that can continuously rotate its source addresses.
Residential Proxies Make Attribution Harder
Residential proxy infrastructure can make malicious traffic look more like ordinary consumer internet traffic.
Instead of seeing authentication attempts originating from a recognizable cloud server, defenders may see connections appearing to originate from networks used by ordinary residential users.
That makes traditional IP reputation systems less reliable.
It also increases the cost of investigation because defenders must distinguish between the identity of the apparent network source and the identity of the person or group controlling the infrastructure.
The Campaign Appears Opportunistic
Researchers did not identify a clear victimology pattern.
The affected organizations represented different industries and geographic regions, suggesting that the attackers were not necessarily pursuing one specific sector.
That makes the operation particularly interesting.
A targeted campaign usually provides clues about what the attackers want. A healthcare campaign, for example, may suggest interest in patient information, while a financial-sector campaign could indicate an interest in money or payment infrastructure.
An opportunistic campaign is different.
The attacker may simply be searching for any account that can be converted into useful access.
Two Browser Signatures Stood Out
Datadog researchers identified two browser user-agent strings repeatedly associated with the suspicious login attempts.
The first was:
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
The second was:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
These values can provide useful hunting signals, although user-agent strings should never be treated as proof of attacker identity.
They can be spoofed relatively easily, and modern attackers frequently modify or rotate browser characteristics.
Their real value comes from correlation with other signals such as source networks, geographic anomalies, authentication outcomes, timestamps, account identity, and behavioral patterns.
Why AWS Root Email Addresses Matter
One of the most revealing aspects of the campaign involves the AWS root account login process.
A failed AWS ConsoleLogin attempt against a root user requires the email address associated with that AWS account.
That raises an important question:
Where did the attackers obtain the email addresses?
Researchers suggest several possibilities.
The addresses could have originated from previous data breaches, exposed corporate records, credential databases, publicly available information, or other forms of reconnaissance.
Another possibility is that attackers are testing large collections of known corporate email addresses to determine which ones are associated with AWS root accounts.
Either way, the campaign suggests that the attackers may possess—or be building—a useful database of potential cloud-account identities.
The Password-Spraying Strategy
Password spraying is fundamentally different from traditional brute-force attacks.
Instead of attempting hundreds or thousands of passwords against one account, an attacker selects a relatively small number of likely passwords and tries them against many accounts.
For example, an attacker might test a few previously exposed passwords against hundreds of organizations.
That strategy reduces the number of failed attempts against each individual account.
It is designed to stay below the radar of defenses that focus primarily on repeated authentication failures against one identity.
The technique is particularly dangerous when attackers have access to large credential collections gathered from unrelated breaches.
Why Root Users Are So Valuable
The AWS root user is not an ordinary cloud account.
It represents the highest level of authority within an AWS account and can perform extremely sensitive administrative operations.
Depending on the environment and circumstances, compromise of the root identity can potentially expose cloud resources, billing information, account-level configuration, security controls, credentials, and other critical administrative functions.
That makes root credentials fundamentally different from ordinary employee credentials.
A compromised low-privilege identity can be dangerous.
A compromised root identity can be catastrophic.
MFA Is Essential—but It Is Not the Whole Story
AWS strongly emphasizes protecting root users with multifactor authentication, and organizations should treat MFA as a baseline security requirement.
But MFA should not create a false sense of security.
Attackers continue to search for accounts where security controls are incomplete, recovery processes are weak, credentials have been exposed, or authentication workflows contain gaps.
They may also attempt to compromise other identities first and use those footholds to attack cloud environments indirectly.
The broader lesson is simple: MFA reduces risk, but identity security requires multiple layers of protection.
Root Login Attempts Should Never Be Ignored
Organizations should pay particular attention to root-user authentication activity.
A root account generally should not be used for routine daily administration.
That means a direct root console login can be highly unusual in a mature cloud environment.
Security teams should review AWS CloudTrail telemetry for both successful and failed root ConsoleLogin events.
Useful detection fields include:
userIdentity.type = Root
eventName = ConsoleLogin
Teams should then correlate those events with:
responseElements.ConsoleLogin
sourceIPAddress
userAgent
awsRegion
eventTime
The exact available fields can vary by event and logging configuration, so detections should be validated against the organization’s own CloudTrail schema.
Deep Analysis: Hunting the Campaign in CloudTrail
A practical first step is to search CloudTrail for root-user console authentication activity.
For environments using CloudTrail Lake, a query pattern such as the following can help identify root ConsoleLogin events:
SELECT eventTime, eventName, userIdentity.type, userIdentity.arn, sourceIPAddress, userAgent, awsRegion, responseElements.ConsoleLogin FROM aws_cloudtrail_events WHERE eventName = 'ConsoleLogin' AND userIdentity.type = 'Root'
ORDER BY
eventTime DESC;
The field names available in a specific CloudTrail Lake environment should be checked against the organization’s actual event schema before deploying the query operationally.
Search for Failed Authentication Attempts
Security teams should also isolate failed root authentication events.
A conceptual query is:
SELECT eventTime, sourceIPAddress, userAgent, awsRegion, responseElements.ConsoleLogin FROM aws_cloudtrail_events WHERE eventName = 'ConsoleLogin' AND userIdentity.type = 'Root' AND responseElements.ConsoleLogin = 'Failure'
ORDER BY
eventTime DESC;
Repeated failures across different accounts, especially when associated with unusual infrastructure, deserve additional investigation.
Hunt for the Suspicious User Agents
The two reported browser signatures can also be used as threat-hunting indicators.
For example:
grep -Ei 'Chrome/85.0.4183.83|Firefox/120.0' cloudtrail-events.json
However, defenders should avoid creating an overly narrow detection based solely on these strings.
User agents are easy to imitate.
A stronger detection would combine the browser signature with root identity, failed authentication, unusual source IPs, geographic anomalies, and timing patterns.
Look for Geographic Anomalies
Geographic information can provide another useful signal.
For example, if an organization normally performs administrative activity from a small number of predictable locations but suddenly sees root authentication attempts from unfamiliar regions, that deserves investigation.
Geolocation is not definitive because VPNs, proxies, corporate networks, and cloud infrastructure can distort apparent locations.
Still, when combined with other indicators, it can dramatically improve detection quality.
Watch for Root Credential Changes
Root-user activity should not be limited to login detection.
Security teams should also monitor for changes involving:
Root password settings
Root MFA configuration
Account recovery information
Contact information
Security credentials
Account-level settings
Unexpected administrative sessions
An attacker who successfully obtains root access may attempt to establish persistence or weaken recovery mechanisms before carrying out additional actions.
Root API Activity Deserves Special Attention
Organizations should also investigate unusual root-related API activity.
The AWS root user is generally not intended to be used for ordinary programmatic operations.
Therefore, unexpected root API activity should immediately raise questions about how and why the identity was used.
The investigation should establish:
Who initiated the activity?
From where?
Why was root required?
What resources were accessed?
What configuration changes occurred?
Were credentials created or modified?
Was MFA altered?
Did the activity coincide with other suspicious events?
AWS Organizations Can Reduce the Blast Radius
Large enterprises should consider how AWS Organizations can be used to reduce unnecessary root-user exposure across member accounts.
Service Control Policies can help constrain what accounts are allowed to do, providing an additional governance layer.
SCPs do not replace identity security, but they can limit the potential impact of compromised credentials in appropriately designed environments.
The objective is defense in depth.
Even if an attacker obtains powerful credentials, the organization should have additional controls capable of restricting what can actually be accomplished.
AssumeRoot and Short-Lived Privilege
For exceptional administrative operations, organizations can also consider AWS mechanisms that provide controlled, temporary access rather than maintaining persistent privileged credentials.
Short-lived administrative sessions reduce the amount of time an attacker can exploit a compromised identity.
The principle is straightforward:
Privileges should exist for as little time as possible and only when they are actually needed.
This is one of the central ideas behind modern Zero Trust security.
The Bigger Problem Is Identity
The campaign may appear to be about passwords.
At a deeper level, it is about identity intelligence.
Attackers need to know which organizations use a particular cloud provider, which email addresses are connected to those accounts, which identities have administrative privileges, and which credentials might be reusable.
Once attackers have that information, automated authentication attempts become relatively inexpensive.
Cloud security therefore begins long before someone attempts to log in.
It begins with controlling what information about identities becomes available to outsiders.
Data Breaches Can Create Secondary Cloud Risk
An
Yet if the same password was previously exposed in a breach and later reused for a cloud account, attackers can connect those two worlds.
This is why credential reuse remains such a persistent security problem.
A breach at one company can create opportunities for attackers months or years later when the same credentials are used elsewhere.
Cloud identities turn those old credentials into potentially valuable targets.
Why Low-Volume Attacks Can Be More Dangerous
Traditional security monitoring often focuses on volume.
Thousands of login attempts from one address are obviously suspicious.
Two failed attempts can appear harmless.
But sophisticated password spraying deliberately operates at low volume.
The attacker wants to disappear into normal authentication noise.
That means modern detection systems must think in terms of distributed behavior, not simply individual events.
Two failures from one source may not matter.
Two failures across hundreds of organizations can tell an entirely different story.
IP Blocking Alone Is Not Enough
The proxy infrastructure described by researchers reinforces another important security lesson.
IP-based blocking remains useful, but it should not be the foundation of cloud identity defense.
Attackers can rotate IP addresses.
They can use residential proxies.
They can move between hosting providers.
They can distribute requests across different networks.
They can also change browser fingerprints.
Identity-based security controls are therefore increasingly important.
Root Access Should Be Exceptional
A mature AWS environment should treat direct root access as an exceptional event.
The question should not be:
Is this login technically allowed?
The better question is:
“Why does this login need to happen at all?”
If the answer cannot be quickly established, the event deserves investigation.
Reducing the number of legitimate root sessions also improves detection because abnormal behavior becomes easier to distinguish from normal administration.
Security Teams Need Better Context
A failed authentication attempt by itself tells defenders very little.
A failed root authentication attempt from an unfamiliar residential proxy, using a suspicious browser fingerprint, outside normal administrative hours, followed by other account-level activity tells a much richer story.
This is why effective detection depends on context.
Organizations should combine:
Identity information
Authentication outcomes
IP reputation
Geographic information
User-agent fingerprints
Historical behavior
CloudTrail events
MFA changes
Credential changes
Account recovery activity
Together, these signals can reveal patterns that individual alerts miss.
What Undercode Say:
- The Attack Is Quiet for a Reason
The most interesting feature of this campaign is not the number of failed logins.
It is the restraint.
2. Attackers Do Not Need Noise
A handful of authentication attempts can be enough when the attacker is testing hundreds of organizations.
3. Root Accounts Are Strategic Targets
Cloud root identities remain among the most valuable credentials an attacker can obtain.
4. The Campaign Looks Opportunistic
There is no obvious industry-specific victim pattern.
5. That Makes Defense Harder
Organizations cannot assume that being outside a traditionally targeted industry makes them safe.
- Email Addresses May Be the First Objective
The requirement for the AWS root email address suggests that identity discovery may be part of the operation.
- Breach Data Can Have a Long Tail
Credentials and email addresses stolen years ago can continue generating security risks.
8. Password Reuse Remains Dangerous
A password compromised elsewhere can become an AWS security problem.
9. MFA Is Still Critical
Organizations should absolutely protect root users with MFA.
- But MFA Is Not a Complete Strategy
Identity protection requires monitoring, governance, credential hygiene, and response capabilities.
11. Root Logins Should Be Rare
The rarer legitimate root activity becomes, the more valuable every root-login alert becomes.
12. CloudTrail Is a Major Defensive Resource
Organizations should retain and actively analyze CloudTrail data.
13. Failed Events Matter
Security teams should not investigate only successful authentication.
14. Failed Attempts Reveal Reconnaissance
Attackers often reveal themselves before they achieve access.
15. User Agents Are Useful Clues
The reported Chrome/Edge and Firefox fingerprints can support hunting.
16. But They Are Not Authentication Proof
Any attacker can modify a browser user-agent string.
17. IP Reputation Has Limits
Proxy networks make source-address blocking increasingly fragile.
18. Residential Proxies Raise the Difficulty
Malicious traffic can appear to originate from ordinary consumer networks.
19. Behavioral Detection Is More Valuable
Defenders should focus on patterns rather than isolated indicators.
20. Cloud Identity Is the New Perimeter
Traditional network boundaries matter less when critical infrastructure is controlled through cloud identities.
- Root Credentials Should Be Treated Like Crown Jewels
They deserve stronger protection than ordinary administrative credentials.
22. Persistent Privilege Creates Risk
Long-lived privileged access gives attackers more opportunity.
23. Temporary Privilege Is Safer
Short-lived administrative sessions can reduce exposure.
24. AWS Organizations Adds Another Layer
Governance controls can help reduce the potential blast radius.
25. SCPs Are Valuable Guardrails
They can limit actions even when identities become compromised.
26. Recovery Mechanisms Matter Too
Attackers may target account recovery pathways rather than simply attempting passwords.
27. Security Teams Should Monitor MFA Changes
An unexpected root MFA modification can be an especially important warning.
28. Billing Data Is Also Valuable
Cloud compromise can create financial damage even without traditional data theft.
29. Attackers Could Abuse Cloud Resources
A compromised account could potentially become useful for unauthorized infrastructure deployment or other abuse.
30. The Financial Risk Can Escalate Quickly
Cloud resources can generate significant costs when abused at scale.
31. Detection Needs Cross-Account Visibility
Large organizations should look for patterns across their entire AWS estate.
- Low Frequency Does Not Mean Low Risk
Attackers deliberately keep password spraying below obvious thresholds.
33. Automation Favors the Attacker
Testing thousands of identities can be accomplished much faster than humans can investigate individual alerts.
34. Automation Must Also Favor the Defender
Detection systems should automatically correlate suspicious authentication patterns.
35. Root Access Should Trigger High-Fidelity Alerts
Organizations should know whenever root authentication occurs.
36. Security Teams Should Ask Why?
Every unusual root login needs a business and operational explanation.
37. Cloud Security Is Becoming Identity Security
Protecting workloads is not enough if attackers can control the identities managing those workloads.
38. Small Signals Can Predict Big Incidents
A failed login may be the earliest visible stage of a much larger campaign.
39. Prevention Is Better Than Emergency Response
Removing unnecessary root usage reduces the opportunities available to attackers.
- The Real Warning Is Bigger Than This Campaign
The most important lesson is that attackers continue to treat cloud identities as high-value infrastructure—and organizations must do the same.
✅ More Than 150 Organizations Were Targeted
Datadog Security Labs reported suspicious AWS root-user authentication activity involving more than 150 organizations during the observed campaign period.
The available reporting describes repeated failed authentication attempts rather than confirmed compromise of all those organizations.
✅ The Activity Used Distributed Proxy Infrastructure
The campaign relied on infrastructure distributed across multiple countries and autonomous systems, including hosting and residential proxy networks.
This makes conventional IP blocking and straightforward attribution considerably more difficult.
✅ Password Spraying Was the Observed Technique
The activity is consistent with password spraying, where a limited number of passwords are tested against many accounts instead of repeatedly attacking a single
▶️ Related Video (82% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.github.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
