How Cloud Identity Attacks Lead to Account Takeover

Contents

Cloud account takeover is no longer just a story about a stolen password. In a recent Google Cloud Threat Horizons report, identity issues were involved in 83% of compromises used for initial access across Mandiant Incident Response and Threat Defense engagements involving major cloud and SaaS environments.

The same report found that 73% of cloud-related incidents targeted data theft. Those figures come from a specific observed incident population, not every cloud breach, but they show where defenders are getting hit.

The uncomfortable part is what happens after the first successful login. An attacker can steal a browser session, abuse an OAuth authorization, register a new authentication device, manipulate account recovery, compromise a service principal, or inherit permissions through a trusted workload. At that point, the attacker may be using legitimate cloud features rather than exploiting an obvious software flaw.

I think this is where many cloud-security explanations become too shallow. They stop at “enable MFA.” MFA is useful, but it protects an authentication event. It does not automatically protect the session created afterward, the OAuth grants attached to the identity, the recovery process, or the permissions assigned to that identity.

The Cloud Identity Attack Chain

A typical cloud identity attack is easier to understand as a sequence:

Initial access → authenticated identity → session or token access → persistence → privilege discovery → privilege escalation → data or resource access

The first step could be ordinary phishing. It could also be a stolen browser session, an exposed API credential or social engineering against an employee or help desk. The route changes, but the objective is similar: obtain something the cloud platform already trusts.

token theft, OAuth abuse, account recovery and workload compromise

1. Attackers Do Not Always Need the Password

After authentication, cloud services issue sessions, tokens and other forms of authentication material. MITRE ATT&CK documents web session cookie abuse as a technique because a stolen authenticated session can be reused to access a web application as the victim. In some cases, the attacker can bypass another MFA prompt because the session has already been authenticated.

Recent research from Okta illustrates how much authentication material can end up outside the identity provider itself. In a 7 GB infostealer dataset containing 5,871 infected-machine folders, researchers found 2,491 Microsoft authentication tokens, of which 1,763 were still unexpired when the dataset was released. They also found 9,829 Google authentication tokens, with 9,213 unexpired. These numbers describe that particular leaked dataset, not the total number of compromised accounts in the wild.

An attacker may not necessarily need to break the login. They may steal the evidence that the login already happened.

2. MFA Can Be Defeated by Attacking the Process Around It

Attackers increasingly target the workflows surrounding MFA rather than trying to crack the factor itself.

Device-code phishing is a good example. Microsoft described the EvilTokens campaign in September 2026. Instead of stealing a victim’s password directly, the attacker starts a device authorization flow and convinces the victim to enter a code on Microsoft’s legitimate authentication page. The victim is then authorizing the attacker’s session.

Microsoft recommends blocking device-code flow where possible and restricting exceptions to devices that genuinely require it.

Account recovery creates another opening. In Microsoft’s investigation of Storm-2949, the threat actor used social engineering consistent with abuse of Self-Service Password Reset. After gaining access, the attackers were able to reset credentials and establish their own authentication methods. The attack then expanded into Microsoft 365 and Azure.

That should change the question security teams ask. “Does this user have MFA?” is not enough. You also need to ask who can reset the account, who can enroll an authenticator, and what happens when an existing authentication method is replaced.

3. OAuth Can Turn Trust Into Access

OAuth creates another path because applications can receive permission to act on behalf of users.

A victim may see a normal authorization screen and approve an application without realizing the requested permissions are excessive. The attacker then gets access through the application rather than through the user’s password.

Microsoft’s guidance on malicious app consent recommends controlling who can consent to applications and closely reviewing high-risk permissions and unfamiliar app registrations.

This is one of those attacks that can look deceptively normal in logs. There may be no failed login storm. There may be no malware alert. There may simply be a new application, a valid consent event and API activity that technically came from an authorized application.

4. Attackers Establish Persistence

Getting into an account once is useful. Staying there is better. One way to do this is through device registration. MITRE ATT&CK’s device-registration technique describes attackers enrolling a device they control into an MFA or device-management system. The attacker can then have an additional trusted path back into the environment.

Other persistence mechanisms include new application credentials, OAuth grants, mailbox forwarding rules, API keys and additional cloud roles.

This is why a password reset can fail as a containment step. If the attacker still has an active session, a refresh token, a newly registered authenticator or an application credential, the original password is only one part of the problem.

compromised user connected to session cookies, refresh tokens, OAuth grants, registered devices, mailbox rules and application credentials

5. IAM Turns One Account Into a Bigger Problem

The next question is what that identity is allowed to do.

A compromised user with limited permissions may only reach email or shared files. A user with privileged cloud roles can reach far more. This is where excessive IAM permissions, custom roles and trust relationships become dangerous.

Storm-2949 provides a concrete example. Microsoft reported that the actor used compromised identities with privileged Azure RBAC roles to move from Microsoft 365 into production Azure resources. The attackers accessed services including Key Vault, Storage and SQL. In one case, Microsoft said the actor accessed dozens of secrets in a Key Vault and found credentials that helped them reach a production application.

The attack was not a dramatic “break into Azure” event. The attacker used legitimate administrative functionality after obtaining an identity that already had authority.

6. Non-Human Identities Can Be Taken Over Too

Cloud identity security is not limited to employees. Service principals, service accounts, managed identities and CI/CD credentials can hold substantial permissions. If one of those identities is compromised, the attacker can operate through the cloud’s own APIs.

Microsoft’s September 25, 2026 investigation into Storm-3168 found compromised Azure service principals performing extensive resource discovery followed by destructive operations and credential collection. Microsoft observed more than 150 destructive or credential-related operations over 35 minutes.

The case also reinforces a basic security rule that developers still get wrong: a credential sitting in a public repository, issue tracker or configuration file is still a credential until it is revoked or rotated.

7. Federation Can Expand the Blast Radius

Federated identity creates another high-impact trust relationship. When a cloud service trusts an external identity provider, the security of that trust extends beyond the cloud platform itself.

NIST’s September 2026 IR 8587 focuses specifically on protecting identity tokens and assertions from forgery, theft and misuse across SSO, federation, API access and workload scenarios. The report recommends stronger token lifecycle controls, key protection, verification, monitoring and narrowly scoped trust.

That guidance reflects a larger reality: if an attacker can influence the system that issues trusted identity assertions, compromising one user may no longer be the main objective. The attacker may be looking for a way to influence how the cloud decides who is trusted in the first place.

How Defenders Should Detect Account Takeover

Individual events are often ambiguous. The sequence is much more revealing.

New device registration followed by privileged activity.
Password reset followed by a new authenticator enrollment.
Device-code authentication followed by unusual API access.
New OAuth consent followed by bulk file or mailbox access.
Service-principal authentication followed by rapid resource enumeration and deletion.

MITRE’s guidance for detecting stolen session cookies recommends looking for token use without a corresponding login or MFA event, changes in browser or device fingerprints, and session reuse inconsistent with the user’s normal pattern. That is much stronger than relying on IP reputation alone.

Correlated identity attack sequence.

How to Reduce the Risk

The controls that help most are the ones that close the gaps between authentication, authorization and persistence.

Use phishing-resistant authentication. Prefer FIDO2 or passkey-based authentication for privileged accounts and sensitive workflows.
Secure recovery and enrollment. Protect password resets, authenticator changes, passkey enrollment and device registration with stronger verification.
Restrict OAuth consent. Require approval for risky applications and high-privilege permissions.
Reduce identity privileges. Review role assignments, service-account impersonation paths and workload permissions.
Protect tokens. Use short-lived credentials where practical, enforce audience restrictions and apply token revocation controls.
Monitor identity changes. Alert on new authenticators, devices, applications, credentials and privileged role assignments.
Protect workload secrets. Rotate exposed service-principal credentials and avoid long-lived secrets embedded in source code.

Manually entered one-time codes can be relayed, while properly implemented phishing-resistant authentication is designed to prevent an impostor verifier from obtaining a usable authenticator output.

The Real Problem Is the Trust Chain

Cloud account takeover rarely ends with the first compromised identity. That identity becomes a starting point for discovering permissions, sessions, applications, devices, secrets and connected workloads.

That is why cloud identity security needs to be treated as a chain of trust. Passwords are one link. MFA is another. Sessions, OAuth permissions, recovery systems, device registration, IAM roles, workload identities and federation are the others.

Break one link and an attacker may get a foothold. Leave several links exposed and a stolen identity can become a path into the wider cloud environment.

The practical test for any cloud environment is therefore simple: if one user’s identity is compromised today, exactly how far can that identity go, what can it change, and which trusted credentials can it create? If the answer is unclear, the identity perimeter has probably not been mapped as tightly as the cloud infrastructure itself.