#14.3 SaaS and Cloud Account Takeover

Playbook ID: PB-ATO | Default severity: SEV-3 (SEV-2 if the principal holds a privileged role, a service principal is involved, or regulated data is in reach; SEV-1 for a tenant-wide consent grant, multiple accounts, or a production cloud control plane) | Owner: Operations Lead (Identity)

#When to run this

• Entra ID Protection risk detections — impossible travel, anonymized IP, unfamiliar sign-in properties, or a user at RiskLevel eq 'high'.
• A new Consent to application record in Purview Audit, or a Google Workspace OAuth Token log event for an unrecognized app.
• GuardDuty IAM findings meaning credentials have left the building: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS / .InsideAWS, UnauthorizedAccess:IAMUser/ResourceCredentialExfiltration.OutsideAWS, CredentialAccess:IAMUser/CompromisedCredentials, or the PrivilegeEscalation:IAMUser/AnomalousBehavior family (finding types).
• A user reports approving an MFA prompt they did not initiate, or a help-desk agent reports a reset request that later looked wrong.
• Bulk export or first-ever API-key creation by a SaaS account.

Not for: compromise of the identity provider itself, federation trust, token-signing material, or a Tier-0 administrator — Playbook 14.4. Mailbox rules used to redirect payment — 14.2. A vendor breach that leaked their copy of your tokens — 14.5, then return here for the revocation work. Workload identity inside a cluster — 14.10.

#What you are dealing with

Somebody is logged in as your user, and they no longer need the password to stay that way. Thirty-five percent of cloud incidents involve valid account abuse and 82% of CrowdStrike's detections were malware-free (CrowdStrike 2026 GTR) — no binary to find, no hash to block, and your EDR has nothing to say. The evidence is authentication telemetry, and it expires fast.

Two mechanisms dominate. Adversary-in-the-middle kits — Tycoon 2FA, Evilginx2 — proxy the genuine login page and lift the session token after the victim completes real MFA (Group-IB). MFA was not bypassed; it was made irrelevant. The other is OAuth consent abuse: an app named to resemble a storage or verification service, approved on a real consent screen, granting standing access. The FBI's IC3 has an active PSA on that campaign, running since late 2025 (Help Net Security). A consented grant is a spare key you handed to a contractor — changing the locks does not get it back. Microsoft says it plainly: "normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren't effective against this type of attack" (illicit consent grants).

The non-human half is worse, because nobody gets a push notification about a service principal. In the Salesloft Drift incident, attackers stole the OAuth refresh tokens customers had issued to a chat integration and exported records from 700+ organizations over ten days, with no customer-side vulnerability at all (AppOmni).

The mistake teams make is ordering. They reset the password first, out of 2015 muscle memory — which tips off the adversary, locks out the user, and leaves every refresh token, app session and OAuth grant alive. Tokens first. Then the credential. Every time.

#Roles for this incident

Marking used below: `TIP-OFF = the adversary can see this action. EVIDENCE` = this degrades or ends a telemetry stream.

#Phase 1 — Detection and Triage

# M365: tenant-wide OAuth grant inventory (Microsoft's documented method).
# One row per delegated/application grant. ConsentType = AllPrincipals means that
# client can reach every user's content in the tenant — triage those first.
.\Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

# Who created or changed inbox rules, and what those rules do.
# Without -SessionCommand this cmdlet returns at most 100 records however high you set
# -ResultSize — and Phase 1 step 7 is only a persistence check if the set is complete.
# ReturnLargeSet comes back unsorted; re-run it with the SAME -SessionId until it returns
# zero rows, then sort what you have.
Get-InboxRule -Mailbox <mailbox> | FL Name,Description,DeleteMessage,MoveToFolder,Enabled
Search-UnifiedAuditLog -StartDate <start> -EndDate <end> -UserIds <user1,user2> `
  -Operations New-InboxRule,Set-InboxRule,Remove-InboxRule `
  -SessionCommand ReturnLargeSet -SessionId <id> -ResultSize 1000

#Phase 2 — Containment

Containment is one burst, not a sequence of tickets. Splitting it across an hour hands the adversary a window to re-establish.

# M365 emergency revocation. Steps 1 and 2 run together, not as separate tickets.
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'johndoe@contoso.com' -ConsistencyLevel eventual

Revoke-MgUserSignInSession -UserId $User.Id            # refresh tokens + session cookies
Update-MgUser -UserId $User.Id -AccountEnabled:$false  # only if you have decided to disable
Get-MgUserRegisteredDevice -UserId $User.Id -All | ForEach-Object {
    Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false
}

# Google Workspace: BOTH calls are required. signOut alone leaves the OAuth app working.
# scope: https://www.googleapis.com/auth/admin.directory.user.security
POST   https://admin.googleapis.com/admin/directory/v1/users/{userKey}/signOut
DELETE https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens/{clientId}

# GCP: disable a suspect service-account key. Does NOT kill tokens already minted from it.
gcloud iam service-accounts keys disable KEY_ID \
    --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --project=PROJECT_ID

#Phase 3 — Eradication

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

The clock starts at confirmed unauthorized access to a data set, not at the first alert. Three things move it: the Phase 4 read-scope statement, whether that data is personal or regulated, and whether the account held data on behalf of a customer.

Notify in this order: the affected user, out-of-band, immediately; the service desk, so they do not process a follow-up recovery request from the attacker; Legal Liaison the moment access is confirmed, not when it is quantified; the SaaS or cloud vendor if their platform or integration is implicated; customers and regulators only on Legal's assessment. Chapter 15 holds the notification decision tree and every regulatory clock — do not reconstruct them here, and never commit to a deadline from memory.

#Automation notes

Automate freely — anything that gathers, enriches or preserves: pull the sign-in and audit exports on trigger, snapshot the OAuth grant inventory, run the inbox-rule and forwarding checks, open the eDiscovery hold, enrich source IPs, assemble the draft timeline. Reversible, evidence-generating, verifiable after the fact.

Automate behind a human gate — the containment burst for a single non-privileged user. Revoke-plus-reset is a good one-click, human-triggered action: a false positive costs a help-desk call, not an outage. Rate-limit it and log the approver.

Never automate — tenant-wide grant removal, quarantine SCP attachment, OIDC provider deletion, disabling a service principal, or account disable at scale. Blast radius scales with the false-positive rate. The documented failure modes of agentic triage are overconfident closure on weak proof and hallucinated detail in the narrative, so every automated action here carries the evidence that justified it. "Closed by agent" with no artefact is how a real incident gets buried.

#Pitfalls

Takeaway: the order is the whole playbook — preserve the telemetry, scope in a time box, then revoke sessions, grants and credentials in one burst. A password reset on its own evicts nobody and announces you. And do not close on a quiet screen: record the query time, re-run after the audit lag, and only then call it contained.