Listen to this Post
A Quiet Cloud Attack With Potentially Serious Consequences
Cloud attacks do not always begin with malware, ransomware, or a dramatic data breach. Sometimes the earliest warning is much quieter: a handful of failed login attempts against one of the most powerful identities inside an organization.
That is what makes the latest AWS security warning particularly important. Datadog Security Research identified a password-spraying campaign targeting AWS root user accounts across more than 150 organizations between July 24 and August 23, 2026. Researchers observed repeated failed authentication attempts against highly privileged AWS identities, with some organizations seeing multiple attempts during the campaign period.
The campaign does not currently appear to have resulted in confirmed successful authentication. However, the targeting itself is significant. The AWS root account is not an ordinary administrator account. It is the identity created when an AWS account is registered and possesses powerful permissions over cloud resources, account settings, billing information, and certain operations that other identities cannot perform.
For defenders, this incident is a reminder that cloud security cannot focus exclusively on malware, exposed servers, or vulnerable applications. Attackers can also spend weeks quietly testing credentials against high-value cloud identities, hoping that one organization has weak password hygiene, inadequate monitoring, or insufficient multi-factor authentication.
Datadog Identifies a Month-Long Password-Spraying Campaign
Datadog Security Research said the activity occurred from July 24 through August 23, 2026, and involved repeated failed authentication attempts against AWS root users at more than 150 organizations. The campaign was not characterized by a huge number of attempts against each individual victim. Instead, its strength appears to have been its broad distribution across many organizations.
Most targeted organizations experienced a relatively small number of attempts. Datadog reported a median of two attempts per organization, while some organizations saw as many as eight attempts during the campaign window.
That low-and-slow approach matters because conventional brute-force defenses often work best when an attacker repeatedly attacks the same account in a short period. Password spraying takes a different route: fewer attempts are distributed across many accounts, making the activity easier to hide in normal authentication noise.
Why Attackers Would Target AWS Root Accounts
The attraction of the AWS root account is obvious. A successful compromise could potentially give an attacker extremely broad control over an organization’s cloud environment.
The root identity has access to AWS resources, billing information, account configuration, and sensitive administrative capabilities. AWS also treats the root user as a special identity because certain actions can only be performed through it.
That makes root credentials fundamentally different from the credentials of an ordinary employee. If an attacker compromises a standard cloud user, their privileges may be limited by IAM policies. A compromised root account represents a much more dangerous situation.
The Attackers May Already Have Had Email Addresses
One of the most interesting observations from the Datadog research concerns the possible source of the targeted identities.
Researchers said the attackers either already possessed a list of root-user email addresses or were systematically working through a list of account email addresses until they encountered valid accounts.
This distinction is important because AWS root accounts are tied to the email address used when the AWS account was originally created. Organizations frequently expose corporate email addresses through websites, public documentation, professional networks, code repositories, domain records, and other sources.
A threat actor does not necessarily need a vulnerability in AWS to begin testing credentials. They may only need a sufficiently accurate list of potential account identifiers.
Proxy Infrastructure Makes Attribution Harder
The campaign also involved infrastructure designed to make the authentication attempts less straightforward to attribute. Datadog’s investigation found activity associated with proxy infrastructure, including source addresses connected with hosting or residential proxy services.
Using intermediary infrastructure can complicate investigations because the visible source IP may not represent the attacker’s actual location or infrastructure.
This also demonstrates why IP reputation alone should not be treated as a complete security control. A login attempt originating from a seemingly legitimate residential network can still be malicious.
Old Browser Fingerprints Can Become a Detection Signal
Another useful clue was the use of a small set of browser user-agent strings. Datadog specifically provided examples involving older Chrome, Edge, and Firefox fingerprints in its detection guidance.
An unusual or outdated browser fingerprint is not automatically malicious. However, when the same fingerprint appears alongside failed root-user authentication attempts, proxy infrastructure, and geographically distributed activity, it becomes a much stronger detection signal.
Security teams should therefore avoid examining authentication events in isolation. The real value comes from correlating identity, source infrastructure, browser characteristics, timing, and authentication results.
No Successful Authentication Was Observed
The most important distinction in the current reporting is that Datadog did not report a successful authentication associated with the campaign.
That means the available evidence supports describing this as a password-spraying campaign targeting AWS root accounts, not as a confirmed mass compromise of 150 or more AWS organizations.
This distinction matters. Security reporting becomes less useful when failed attacks are automatically described as successful breaches.
At the same time, “no successful authentication observed” should not be interpreted as “no risk.” It means the available telemetry did not show successful logins connected to the observed campaign.
The Real Risk May Be Hidden in Individual Organizations
A campaign can fail globally while still succeeding against an individual victim.
For example, if one organization reused a weak password, failed to enforce MFA, or did not properly protect its root account, an attacker could potentially obtain access even if the wider campaign produced no confirmed successes in Datadog’s dataset.
That is why organizations should investigate their own CloudTrail records rather than assuming they are safe simply because no breach has been publicly confirmed.
AWS Root Accounts Should Rarely Be Used
The AWS root user is not intended to function as an everyday administrator account.
Organizations should instead rely on appropriately controlled IAM identities and centralized access mechanisms for normal administrative operations. Datadog’s recommendations include reducing dependence on root credentials, enabling MFA, using hardware-based MFA for the root account, and applying restrictions around root activity.
The fewer circumstances in which a root credential is used, the easier it becomes to recognize unexpected root activity.
MFA Is the Critical Barrier
A strong, unique password is important, but password spraying is specifically designed to exploit password weaknesses.
Multi-factor authentication adds another authentication requirement that an attacker cannot satisfy simply by knowing a password. Datadog specifically recommends MFA for the AWS root account and highlights hardware-based MFA as a stronger option.
For organizations operating valuable cloud environments, root-account MFA should be treated as a fundamental security control rather than an optional enhancement.
CloudTrail Becomes a Critical Source of Evidence
AWS CloudTrail provides an important source of visibility into authentication activity.
Datadog provided a CloudTrail query designed to help organizations search for root-user ConsoleLogin activity associated with the campaign, including both successful and failed authentication results and the relevant user-agent fingerprints.
The broader lesson is more important than the exact query: organizations need centralized visibility into root-user authentication and should retain enough historical telemetry to investigate suspicious activity after the fact.
Deep Analysis: How Defenders Can Hunt for the Campaign
The safest starting point is to search CloudTrail for root-user console authentication events rather than trying to identify attackers through active interaction.
A defensive CloudTrail search can focus on the root identity and ConsoleLogin events:
source:cloudtrail
@userIdentity.type:Root
@eventName:ConsoleLogin
@responseElements.ConsoleLogin:(Failure OR Success)
Organizations using Datadog can extend the search with the browser fingerprints documented by Datadog:
@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" )
A more general investigation should then examine every root-user ConsoleLogin event during the July 24–August 23 campaign period.
Defenders should record the source IP, timestamp, AWS account, authentication result, user agent, and whether MFA was reported as used.
The goal is not merely to count failures. Analysts should look for patterns connecting apparently isolated events.
A single failed root login may be harmless noise.
Several failed root logins from different proxy addresses can be much more interesting.
The same browser fingerprint appearing across multiple source networks is another potentially useful correlation point.
Repeated attempts against multiple AWS accounts may indicate broader credential testing.
A successful root ConsoleLogin surrounded by earlier failures deserves immediate investigation.
Organizations should also determine whether the root account has an active password at all.
Where organizational architecture permits it, reducing dependence on root credentials substantially reduces the opportunity for password-based attacks.
Cloud security teams should verify that root MFA is enabled.
They should also verify that the recovery mechanisms protecting the root account are secure.
Password resets and account-recovery processes deserve the same scrutiny as ordinary login security because an attacker who gains control of recovery channels may attempt to bypass conventional protections.
Security teams should review whether root credentials have ever been used for routine administrative work.
Unexpected root activity should generate a high-priority alert.
Organizations should consider centralizing AWS account visibility so security personnel can identify unusual root activity across multiple accounts.
AWS Organizations can also provide centralized controls that reduce reliance on manually managed root credentials across member accounts.
Datadog recommends several controls around AWS root security, including centralized root access management, root credential management, MFA, hardware-based MFA, and restrictions on root actions.
The most important command is therefore not an offensive command against an attacker.
It is a defensive query against your own logs.
The objective is to determine whether your infrastructure was targeted and whether any authentication succeeded.
Why Low-Volume Attacks Are Dangerous
The
Security monitoring systems often prioritize large volumes of failed authentication attempts. A handful of attempts can disappear into millions of legitimate cloud events.
Attackers understand this.
By spreading activity across organizations and keeping individual attempt counts low, adversaries can potentially remain below simplistic brute-force thresholds.
This is why detection systems need behavioral context rather than relying exclusively on thresholds.
Password Spraying Is Different From Traditional Brute Force
Traditional brute-force attacks commonly involve repeatedly attempting many passwords against one account.
Password spraying reverses the strategy.
Instead of trying hundreds of passwords against one account, attackers may try a small number of commonly used or previously obtained passwords across many accounts.
This approach can reduce the likelihood of triggering account lockout controls.
It also makes the attack particularly dangerous in environments where authentication monitoring is fragmented.
The
Datadog said the available information was insufficient to conclusively determine the attackers’ motive. Researchers also described the targeted organizations as apparently random, making it difficult to establish a clear victimology.
Possible motivations could include credential validation, opportunistic account takeover, preparation for later intrusion, or simply testing a harvested database of cloud identities.
However, these possibilities should not be presented as confirmed explanations.
The evidence currently supports the existence of the targeting campaign, but not a definitive attribution or motive.
Why Cloud Identity Has Become a Prime Target
The broader trend is clear: attackers increasingly have strong incentives to target identities rather than individual machines.
Modern businesses may operate applications, databases, storage systems, containers, serverless workloads, and security infrastructure entirely inside cloud platforms.
Compromise the right identity, and an attacker may not need to exploit every individual system.
That makes privileged identities one of the most important security boundaries in modern infrastructure.
The Root Account Is a Strategic Target
An attacker targeting a low-privilege account may need to conduct several additional steps before reaching valuable resources.
The root account can potentially eliminate many of those barriers.
This explains why even unsuccessful root-account password spraying deserves attention.
Attackers do not necessarily need to discover a new vulnerability when a powerful identity is already exposed to password-based authentication.
Organizations Should Treat Root Login Attempts as High Priority
A failed root login should not automatically trigger an incident response process.
But it should be visible.
Security teams should establish clear baselines for legitimate root-user activity and investigate events that fall outside those expectations.
The ideal root account is an identity that is rarely used, strongly protected, continuously monitored, and tightly controlled.
Detection Needs to Become More Contextual
The Datadog research demonstrates the value of combining several weak signals.
Failed ConsoleLogin attempts alone may not look particularly dangerous.
A suspicious source IP alone may not be enough.
An unusual browser fingerprint alone may not prove malicious activity.
But when these signals appear together against a root identity, the probability of malicious activity increases substantially.
The Human Element Still Matters
Technology cannot completely compensate for weak operational practices.
Organizations should know who controls the root account email address, who has access to recovery mechanisms, how MFA is configured, and what procedures exist for emergency root access.
If those questions cannot be answered quickly, the organization may have an identity-management problem even if no attack has succeeded.
Security Teams Should Investigate Before the Alert Becomes a Breach
One of the strongest lessons from this campaign is that failed attacks can provide valuable intelligence.
An attacker revealing themselves through authentication attempts gives defenders an opportunity to investigate before a successful login occurs.
The right response is not panic.
It is verification.
Check the logs.
Check MFA.
Check the root account.
Check recovery settings.
Check for successful authentication.
Check for unusual activity following any suspicious login.
The 150-Organization Figure Needs Context
The headline number is significant, but it should be interpreted correctly.
More than 150 organizations were targeted according to Datadog’s observations. That does not mean more than 150 organizations were breached.
The distinction between “targeted,” “attacked,” and “compromised” is critical in cybersecurity reporting.
At present, the evidence supports the first two descriptions far more strongly than the third.
What This Means for Enterprise Security
For enterprises, the campaign should trigger a review of cloud identity security.
Organizations should ensure that root accounts are protected with strong authentication, that root activity is logged and monitored, and that routine administrative operations are performed through appropriately scoped identities.
They should also confirm that historical logs remain available long enough to investigate campaigns that may not become known until weeks after the activity begins.
What This Means for Smaller Organizations
Smaller businesses are not automatically less attractive to attackers.
In fact, organizations with fewer security personnel may be more vulnerable to low-volume attacks because suspicious authentication events can go unnoticed.
A small company running production systems on AWS should therefore apply the same fundamental protections as a large enterprise: strong root-account protection, MFA, limited root usage, logging, alerting, and secure account recovery.
The Bigger Cloud Security Lesson
This campaign is ultimately less about one AWS password-spraying operation and more about how modern attackers think.
They look for identities.
They test credentials.
They distribute activity.
They use intermediary infrastructure.
They avoid unnecessary noise.
And they wait for the weakest target.
Cloud security therefore has to evolve beyond the traditional idea of defending servers and networks.
The identity itself is now part of the attack surface.
What Undercode Say:
A Small Number of Attempts Can Hide a Big Campaign
The most interesting part of this incident is not the raw number of login attempts. It is the distribution. More than 150 organizations were touched while individual organizations generally saw only a handful of attempts.
Low Volume Is a Deliberate Advantage
Attackers do not always benefit from making noise. A low-volume campaign can be harder to distinguish from ordinary authentication mistakes, forgotten passwords, automated systems, or background internet activity.
Root Accounts Change the Risk Calculation
A password-spraying attempt against a low-privilege account is concerning. A password-spraying attempt against a root identity is considerably more serious because the potential consequences of successful authentication are much greater.
The Attack Surface Begins With Identity
Organizations often think about cloud attack surfaces in terms of exposed services, vulnerable applications, and misconfigured storage. Those remain important, but identity is increasingly the first doorway attackers test.
Email Addresses Can Become Security Intelligence
If attackers already possessed root-account email addresses, that raises questions about how those addresses were collected. Public corporate information can become useful intelligence for threat actors.
Password Reuse Remains Dangerous
Password spraying becomes more effective when organizations use weak, predictable, or reused credentials. A strong unique root password significantly reduces the probability of success.
MFA Changes the Equation
MFA is one of the strongest defenses against password-only attacks. Even if a password becomes known, an attacker still needs to overcome the second authentication factor.
Hardware MFA Provides an Additional Layer
For especially sensitive root accounts, hardware-based MFA can provide stronger protection against several classes of authentication attacks. Datadog specifically recommends hardware-based MFA for AWS root accounts.
Root Accounts Should Be Boring
A healthy root account should generate very little activity. If an organization sees frequent root authentication, that may indicate excessive dependence on an identity that should be reserved for exceptional operations.
Monitoring Matters as Much as Prevention
Preventing every password attack is unrealistic. Detecting suspicious activity quickly is therefore equally important.
CloudTrail Is an Important Evidence Source
CloudTrail can provide the authentication records necessary to determine whether suspicious root login activity occurred. Datadog specifically recommends querying CloudTrail for the relevant ConsoleLogin events.
Failed Logins Are Valuable Signals
A failed login is not meaningless. A pattern of failed logins can reveal that an attacker has identified an organization’s cloud identity and is testing credentials.
Successful Logins Need Immediate Attention
If a suspicious root login is successful, the investigation should escalate immediately. Defenders should determine what happened before and after the authentication event.
Source IPs Are Not Enough
Proxy infrastructure means the source IP observed by defenders may not identify the actual attacker. IP-based blocking can help, but it should not be the primary security strategy.
Browser Fingerprints Can Help Correlation
Repeated user-agent patterns across otherwise unrelated authentication events can provide another useful correlation signal.
Threat Hunting Should Cross Account Boundaries
Organizations with multiple AWS accounts should look for related activity across their entire cloud estate rather than investigating accounts individually.
Centralized Visibility Is Increasingly Important
The larger the AWS environment becomes, the harder it is to detect distributed identity attacks manually. Centralized logging and detection become essential.
Attackers Benefit From Fragmented Security
When cloud accounts are monitored independently, a campaign spanning dozens of organizations or accounts can look like isolated incidents rather than a coordinated operation.
The Timing Is Also Interesting
The activity continued for roughly one month. That duration demonstrates that credential attacks do not necessarily follow the fast, explosive pattern associated with ransomware.
Persistence Does Not Always Mean High Volume
Attackers can remain persistent while generating very little traffic. This is especially useful when trying to evade simplistic detection systems.
Unknown Motive Should Not Stop Defensive Action
Datadog could not determine the
No Confirmed Compromise Is Good News
The absence of observed successful authentication is an important positive finding. It suggests the campaign did not produce a confirmed mass AWS root compromise within the observed dataset.
No Confirmed Compromise Is Not a Security Guarantee
Organizations must still check their own telemetry. Visibility varies between environments, and an absence of evidence in one dataset does not prove that every targeted organization was untouched.
Cloud Security Requires Continuous Verification
Security teams should not assume that an account is safe because it has never previously generated an alert. Threat actors constantly test new credentials and identities.
Root Credential Exposure Should Be Treated Seriously
If root credentials are stored, shared, or handled casually, the organization may have an avoidable security weakness.
Recovery Channels Deserve Protection
Attackers who cannot directly authenticate may attempt to exploit account recovery processes. Those channels should be secured and monitored.
Privilege Reduction Remains Fundamental
The best way to reduce the impact of an identity compromise is to ensure ordinary users do not possess unnecessary privileges.
Root Should Not Become an Everyday Administrator
Using the root account for routine operations increases both exposure and the difficulty of identifying abnormal behavior.
Organizations Need Clear Root Procedures
There should be documented rules defining who can use the root account, when it can be used, and how those actions are reviewed.
Alerting Should Reflect Identity Sensitivity
A failed login against an ordinary account and a failed login against a root account should not necessarily receive identical priority.
Detection Rules Need Behavioral Context
Security platforms should combine authentication results, identity type, source infrastructure, timing, and device characteristics rather than depending on one indicator.
Password Spraying Will Remain Relevant
As long as organizations maintain password-based authentication, attackers will continue looking for weak credentials that can be tested at scale.
Cloud Identity Is Becoming the New Perimeter
Traditional network boundaries matter less when an attacker can authenticate directly to cloud services from anywhere on the internet.
Security Teams Should Assume Credentials Will Be Tested
The realistic goal is not to prevent every login attempt. The goal is to make successful credential abuse extremely difficult and rapidly detectable.
The Strongest Defense Is Layered
Unique credentials, MFA, centralized logging, behavioral detection, limited privileges, secure recovery, and disciplined root-account management work together.
Undercode’s Assessment
This campaign is a warning shot rather than evidence of a mass AWS compromise. Its significance comes from the choice of target, the broad number of organizations involved, and the quiet nature of the activity.
The attackers appear to have tested one of the most valuable identities in cloud computing while keeping the number of attempts against individual organizations relatively low. That combination is exactly what defenders should take seriously.
The most important question for AWS customers is not whether the campaign made headlines. It is whether their own CloudTrail data shows that their root identity was tested—and whether the account is protected well enough that a stolen password would not be enough.
✅ Confirmed: Datadog Security Research reported a password-spraying campaign targeting AWS root user accounts across more than 150 organizations between July 24 and August 23, 2026.
✅ Confirmed: Datadog reported a median of two failed attempts per organization, with some organizations experiencing as many as eight attempts, and provided CloudTrail detection guidance for investigating the activity.
❌ Not confirmed: There is currently no evidence in Datadog's report that this campaign successfully compromised more than 150 AWS organizations; the research specifically says the available information did not establish successful authentication or the attacker's definitive motive.
Prediction
(+1) More Cloud Identity Attacks Are Likely
As organizations continue moving workloads and sensitive infrastructure into public clouds, privileged identities will remain attractive targets. Attackers have strong incentives to test credentials against cloud accounts because a successful authentication can provide access without requiring an exploit against a vulnerable server.
(+1) Password Spraying Will Become More Distributed
Future campaigns are likely to continue favoring low-volume, distributed activity because it can be harder to detect than conventional brute-force attacks. Instead of attacking one organization aggressively, attackers can probe many organizations with only a few attempts each.
(+1) Root Account Monitoring Will Become Standard Practice
Security teams are likely to place increasing emphasis on root-user activity, particularly because legitimate root usage should generally be rare. That makes abnormal root authentication behavior a potentially powerful detection signal.
(+1) Hardware-Based MFA Will Gain More Attention
The continued targeting of privileged identities will encourage organizations to move beyond passwords and basic authentication controls. Hardware-backed authentication is likely to become increasingly common for especially sensitive cloud accounts.
(-1) Organizations Without Centralized Logging Will Remain Vulnerable to Blind Spots
Businesses that do not retain and correlate CloudTrail authentication events may discover suspicious activity only after a successful compromise. Distributed attacks are particularly difficult to reconstruct when logs are fragmented or retained for too short a period.
(+1) Cloud Security Will Shift Further Toward Identity Protection
The long-term lesson from this campaign is that cloud security is becoming increasingly identity-centric. Organizations will need to protect not only their applications and infrastructure, but also the credentials and authentication pathways that control them.
Tighten repetitive sections for stronger impact
▶️ Related Video (84% 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: x.com
Extra Source Hub (Possible Sources for article):
https://www.discord.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
