Cloud Identity Attacks: How One Account Becomes a Breach

Cloud identity attacks begin when an attacker gains control of a user, session, token, service principal, or other identity that can authenticate to cloud resources. If that identity can access shared data, manage resources, or reach secrets, one compromise can become the starting point for a broader cloud breach.

What Are Cloud Identity Attacks?

Cloud identity attacks target authentication and authorization rather than relying primarily on malware or endpoint exploitation. Attackers may use stolen passwords, phishing, session tokens, OAuth permissions, exposed API keys, or compromised workload identities to act as legitimate users or services.

That matters because cloud platforms are designed to let authenticated identities reach connected resources. A user might have access to Microsoft 365, SaaS applications, Azure subscriptions, storage, databases, secrets, or administrative functions. If an attacker obtains the same permissions, legitimate cloud features can become part of the attack path.

How One Compromised Account Can Expand Across the Cloud

The most important factor is not simply whether an account was compromised, but what that identity can reach.

A typical escalation path may look like this:

1. An attacker gains control of a cloud user or session.
2. The attacker enumerates users, applications, and privileges.
3. Shared files and SaaS data are accessed.
4. Privileged roles, service principals, secrets, or cloud resources are identified.
5. Additional credentials or tokens are obtained.
6. Access expands into storage, databases, workloads, or administrative functions.
7. Data is collected and exfiltrated.

A low-privilege account with tightly scoped access may limit the impact. A privileged identity connected to several cloud services can create a much larger blast radius. This is why least privilege directly limits what a compromised identity can do.

Storm-2949 Shows How Identity Compromise Can Become Cloud-Wide

Microsoft published a May 2026 investigation into activity it tracks as Storm-2949. According to Microsoft, the intrusion began with targeted social engineering against Microsoft Entra ID users and expanded into Microsoft 365 and Azure. The attackers abused a process consistent with self-service password reset social engineering, persuaded victims to complete authentication prompts, and then registered their own authentication methods. Microsoft’s Storm-2949 investigation

Microsoft reported that the actor used compromised identities to enumerate directory information, access Microsoft 365 files, and later reach Azure resources. The investigation described access to Key Vault secrets, storage, SQL data, virtual machines, and other resources through legitimate management features and permissions rather than a malware-first approach.

The case shows why defenders should not treat a compromised cloud account as an isolated password-reset event.

Human Identities Are Only Part of the Problem

Cloud environments depend on both human and non-human identities. Human identities include employees, contractors, administrators, and external users. Non-human identities include service principals, managed identities, API keys, automation accounts, and application credentials.

Attackers who compromise a human user may search for machine identities because they can provide persistent or broader access. Microsoft observed Storm-2949 attempting to add credentials to a service principal and later trying to use a virtual machine’s managed identity to reach Key Vault resources. Those attempts were not all successful, but they illustrate the value of workload identities.

Why MFA Alone Does Not Eliminate Cloud Identity Risk

Multifactor authentication remains essential, but not every MFA method provides the same resistance to phishing or social engineering.

An attacker may trick a user into approving a fraudulent request, capture a session through an adversary-in-the-middle technique, or abuse an already authenticated session. Microsoft recommends phishing-resistant authentication for privileged roles and identifies passkeys, FIDO2 security keys, and certificate-based authentication among the stronger options. Microsoft guidance on phishing-resistant MFA for privileged roles

Conditional Access can add context by considering user risk, sign-in risk, device state, location, and the resource being accessed.

Exposed Cloud Credentials Can Create a Second Attack Path

Not every cloud identity attack begins inside the identity provider. Credentials can escape through repositories, build artifacts, malware infections, phishing, misconfigured systems, or third-party incidents.

DarknetSearch has covered this risk in its analysis of the Beacon CRM AWS access key exposure. A valid cloud credential with sufficient permissions may give an attacker authorized-looking access without exploiting a vulnerability in the cloud provider itself.

Finding an API key, password, or token in an external dataset does not automatically prove that it was used. It is evidence that should trigger validation, rotation, and investigation. Credential leak detection can help identify exposed authentication data associated with corporate identities and domains, which defenders can then correlate with cloud audit logs.

Stealer Logs Add Another Identity Exposure Channel

Infostealer malware can collect browser passwords, cookies, session information, and other authentication material from an infected endpoint. The resulting stealer log is not the same thing as a breach of the employer’s cloud tenant or database.

However, if the log contains valid corporate credentials or session artifacts, it can create an access path into cloud services. DarknetSearch’s stealer log guide explains that these datasets originate from compromised devices rather than necessarily from a server-side breach.

If a corporate session appears in a stealer log, resetting a password may be insufficient if reusable tokens or cookies remain valid.

How Security Teams Should Detect Cloud Identity Attacks

Cloud identity attacks often use legitimate features, so defenders need behavior-focused telemetry rather than relying only on malware alerts.

Useful signals include:

• sign-ins from unusual infrastructure, devices, or locations;
• unexpected MFA or authentication-method changes;
• new credentials added to applications or service principals;
• unusual Microsoft Graph or cloud API enumeration;
• mass downloads from OneDrive, SharePoint, storage, or SaaS platforms;
• access to Key Vaults or secrets outside normal patterns;
• privilege changes or creation of new administrative accounts;
• unusual cloud control-plane operations.

The value comes from correlating identity, application, cloud, endpoint, and data-access events into one timeline.

What to Do After a Cloud Identity Compromise

Containment should address more than the original password.

A practical response includes:

1. Disable or restrict the affected identity where appropriate.
2. Revoke active sessions and refresh tokens.
3. Reset passwords and remove unauthorized authentication methods.
4. Review privileged roles, group memberships, app consents, and service-principal changes.
5. Rotate API keys, secrets, certificates, and other credentials the attacker may have accessed.
6. Review cloud audit logs for storage, database, Key Vault, SaaS, and administrative activity.
7. Investigate endpoints if infostealer or credential theft is plausible.
8. Determine whether data was actually accessed or exfiltrated.
9. Hunt for persistence created through identities, applications, automation, or cloud resources.

The objective is to remove every access path created during the compromise, not simply restore the original user account.

Frequently Asked Questions

What is a cloud identity attack?

A cloud identity attack targets an account, session, token, service identity, or authentication workflow used to access cloud resources. The attacker attempts to operate with legitimate permissions rather than necessarily exploiting the underlying cloud infrastructure.

Can one compromised cloud account lead to a major breach?

Yes, if the account has broad permissions or can reach secrets and additional identities. The impact depends on role assignments, connected applications, privilege boundaries, and whether the attacker can obtain additional credentials or tokens.

Does MFA prevent cloud identity attacks?

MFA reduces risk substantially, but phishable MFA methods and compromised sessions can still be abused. Phishing-resistant MFA, Conditional Access, least privilege, session controls, and continuous identity monitoring provide stronger protection than relying on a second factor alone.

Are stealer logs proof that a company’s cloud environment was breached?

No. A stealer log normally originates from an infected endpoint. It may contain credentials or session data for corporate cloud services, but that exposure must be correlated with authentication and audit logs before concluding that the cloud environment itself was accessed.

Strengthen Visibility Into External Identity Exposure

Internal cloud telemetry shows what happened inside your environment, while external monitoring can reveal authentication data or organizational information that has escaped it. Dark web monitoring can support investigations by helping teams identify exposed credentials, leaked datasets, or related external signals. Used alongside IAM controls, cloud logging, endpoint security, and incident response, DarknetSearch can add another layer of visibility when teams need to understand whether cloud identities have been exposed beyond controlled systems.