SaaS Account Takeover Response Playbook

What This Playbook Covers

• SaaS account takeovers occur when an attacker gains unauthorized access to a user’s cloud application account — typically through stolen credentials, session token theft, or MFA fatigue push bombing
• This is distinct from on-prem credential theft. SaaS accounts have different detection surfaces (API logs, cloud audit logs, browser sessions) and different containment mechanisms (session revocation, OAuth token invalidation)
• MITRE ATT&CK maps SaaS account takeover under T1078 (Valid Accounts) and T1556 (Modify Authentication Process) for MFA bypass

Common SaaS Takeover Vectors

Phase 0: Detect the SaaS Takeover (0-15 minutes)

Detection Indicators by SaaS Platform

Detection — Anomalous sign-in activity: Monitor these signals across your SaaS platforms:

KQL query — Azure AD sign-in anomalies:

SigninLogs
| where TimeGenerated > ago(1h)
| where RiskLevelDuringSignIn in ("medium", "high") or RiskLevelAggregated in ("medium", "high")
| project TimeGenerated, UserPrincipalName, IPAddress, Location, RiskLevelDuringSignIn, 
          DeviceDetail.browser, DeviceDetail.operatingSystem, Status.failureReason
| order by TimeGenerated desc

Google Workspace — anomalous login detection:

index=google_workspace event_name="login_success" OR event_name="login_failure"
| stats values(event_name) as Events, values(ip_address) as IPs, values(user_agent) as UserAgents by actor_email, _time
| where mvcount(IPs) > 3
| eval alert = "SUSPICIOUS — multiple IPs for " . actor_email . " in one session"

Slack — anomalous workspace access:

index=slack event_type="user_login"
| eval is_new_device = if(match(user_agent, "Mozilla") AND NOT match(user_agent, known_slack_user_agents), 1, 0)
| where is_new_device = 1 AND location NOT IN (known_team_locations)
| eval alert = "SUSPICIOUS — new device login for " . user_name . " from " . location

Phase 1: Immediate Containment (15-30 minutes)

Critical Actions — Do These First

• Force password reset — do not use the user’s last password, and require MFA re-registration
• Revoke all active sessions — sign out of all sessions across the affected SaaS, not just the current session
• Revoke OAuth tokens — revoke all third-party app OAuth tokens granted by the affected user
• Disable the user account — temporarily disable the account in the IdP while investigating
• Check for mailbox rules — if O365 or Google Workspace, check for suspicious forwarding, deletion, or phishing rules
• Cancel pending actions — if the attacker initiated actions (password reset, email forwarding, payment method change), cancel them

Platform-specific session revocation:

What NOT to Do

Phase 2: Evidence Preservation (30-60 minutes)

Evidence to Capture

Phase 3: Investigation (1-4 hours)

Questions to Answer

Phase 4: Recovery and Hardening

Account Recovery

Long-Term Hardening

Related

• Credential Theft Incident Response — detection and response for T1558.001, T1003.001, T1134 techniques
• Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
• MFA Fatigue — detection and response for T1110.004, T1621 techniques
• Phishing — detection and response for T1566 techniques
• Suspicious Authentication — detection and response for T1078 techniques

Sources

• Microsoft — Azure AD Identity Protection
• CISA — MFA Push Bombing
• Google — Workspace Security Best Practices
• MITRE ATT&CK T1078 — Valid Accounts
• OWASP — Credential Stuffing Prevention