BIPI
BIPI

Cloud Account Takeover: An Investigation Flow That Actually Scopes

Cybersecurity

Account takeover in Azure AD or Workspace is the new lateral movement. We walk through the investigation flow from compromised user to full blast radius, including the OAuth grants and session tokens most resets do not invalidate.

By Arjun Raghavan, Security & Systems Lead, BIPI · March 17, 2024 · 8 min read

#ato#identity#incident-response

When a cloud account gets compromised, the first instinct is to reset the password and walk away. That is roughly half the response. The attacker has session tokens, OAuth grants, refresh tokens, and possibly federated app access that survive a password reset. Scoping properly takes a few hours and saves you a re-compromise a week later.

Trigger signals

Impossible travel alerts get the headlines, MFA fatigue prompts show up in user reports, but the most reliable signal is a sign-in from a new device or an OAuth grant to an application the user has never heard of. We have caught more ATOs from anomalous OAuth consent than from impossible travel, because attackers know to use residential proxies but they still need to grant their own app.

Pivot from the compromised user

Treat the user as a pivot point, not as the entire scope. Pull every sign-in record for the user across the last 90 days. Note every IP, user-agent, and country. The clean pattern is usually three or four IPs, two user-agents, one or two countries. The bad pattern shows up as an outlier in any of those dimensions. Then pull every action the user took during the suspect sessions: file accesses, app launches, admin actions, OAuth consents.

  • Azure AD sign-in logs filtered by UPN for the last 90 days, full export to CSV
  • Unified audit log (M365) for the same period, filtered by UserId
  • OAuth consent grants from Azure AD enterprise applications and OAuth permissions
  • Sent Items folder for messages sent during suspect sessions
  • Inbox rules created during suspect sessions, which is where exfil hides

OAuth grants: the part everyone misses

Attackers love OAuth because it survives password reset and MFA enrollment. The attacker grants a malicious app access to mail.read, the user clicks through, and now the attacker reads mail via Graph API forever. Enumerate every OAuth grant for the user. In Azure, that is Get-MgUserOauth2PermissionGrant. In Workspace, that is the OAuth tokens audit log and the third-party app access dashboard. Revoke anything you do not recognize.

Session token invalidation done right

The reset sequence matters. Disable the account first to stop new authentications. Then invalidate refresh tokens and revoke active sessions. Then rotate any application passwords or device-bound credentials. Then re-enable with a forced password change and MFA re-enrollment. Doing it in the wrong order leaves a window where the attacker can re-auth with their existing refresh token before you nuke it.

  1. Disable the account to halt new authentications
  2. Revoke refresh tokens via Microsoft Graph or Workspace admin
  3. Revoke OAuth grants for any unrecognized application
  4. Reset password to a strong rotated value
  5. Re-enable MFA from scratch, force the user to re-enroll on a clean device
  6. Re-enable the account and force change at next sign-in

Scope of access: what could this user actually reach

The compromised user is rarely the prize. Map their access. Group memberships, application role assignments, mailbox permissions, OneDrive or Drive shares, Teams or Slack memberships, SaaS app SSO grants. We have seen ATOs of a marketing intern lead to financial system access because the intern was in a group that inherited a stale permission six rotations ago. Run the access map every quarter on critical users, not just during incidents.

Reset checklist for the wider blowback

  • Rotate any service account credentials the user could have viewed
  • Audit mailbox forwarding rules across all users (attackers create rules on adjacent accounts)
  • Check for new admin role assignments anywhere in the tenant
  • Review API keys and PATs the user may have generated in connected systems
  • Search code repositories for commits authored by the user during the suspect window

Real example from a 2023 case

A finance lead clicked an Adversary-in-the-Middle phishing page. The attacker captured the session token, accessed the mailbox, created a forwarding rule, and registered a malicious OAuth app with mail.read. The user reset their password the next day after a vague suspicion. The attacker kept reading mail for three more weeks via the OAuth grant. We caught it because the OAuth grant showed up in a quarterly review. The lesson was simple: password reset is not response, it is one step of response.

If you reset the password and stopped, you ran half the play. The other half is where the attacker still lives.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.