Playbook: Investigating Suspicious OAuth Activity

OAuth turns a one-time approval into standing access. A user clicks “Accept”, or an administrator grants a permission, and an application can then read mail, files or directory data through tokens that keep working. Resetting the user’s password does not remove the grant. The investigation has to find the app, the permission and the tokens, not only the person.

This playbook covers suspicious OAuth activity in a Microsoft Entra ID tenant, with notes for third-party SaaS platforms. The reasoning carries over to other identity providers. Use it when an alert, a user report or a hunt gives you an app, a consent event or unusual application access to look at.

Know which of three situations you are in

The three patterns below need different containment, so classify early.

Step 1. Capture the identifiers before anything else

Write down the facts below before you click anything. They let you work across logs and they survive if the app is later deleted.

• application (client) ID and service principal object ID,

• display name, publisher and whether the publisher is verified,

• whether the app is single-tenant or multi-tenant, and which tenant owns the registration,

• reply URLs and the date the app was registered,

• consent type (user or admin), who granted it, when, and the exact scopes,

• owners of the app registration and the service principal.

Export the app object, its grants and the related audit events to a case folder now. Deleting an app removes the easiest way to reconstruct what it was.

Step 2. Classify the app

Application permissions deserve most of your attention. They let the app act with no user present, so there is no sign-in prompt, and no MFA, to interrupt it.

Step 3. Scope what the app touched

The consent event tells you what the app could reach. The data-access logs tell you what it did reach. Your notification and recovery decisions depend on that difference.

• Mail: review mailbox audit events, including mail item access events where your license provides them, and Exchange Web Services activity. Microsoft’s responder guidance identifies EWS activity as how the Midnight Blizzard intrusion was found.

• Files and collaboration: review SharePoint, OneDrive and Teams file access by the app identity or the consenting users.

• Directory: review reads and changes through the Microsoft Graph, using Graph activity logs if they are enabled.

• Third-party SaaS: use the platform’s own event logs. In the Drift campaign, Google reported that the actor deleted query jobs, but the underlying logs remained and were still worth reviewing.

Check logging before the incident teaches you the lesson. Microsoft’s own guidance notes that a full scope analysis of an illicit consent grant requires mailbox auditing and administrator and user activity auditing to have been on before the attack. If it was off, the honest finding is “cannot rule out access”, not “no access”.

Also look for what the actor did with the data. In the Drift campaign, Google assessed that the actor searched stolen records for secrets such as cloud access keys, passwords and Snowflake-related tokens. Treat any secret an app could read as exposed, and rotate it.

Step 4. Find the origin

Every grant has an origin. Finding it tells you whether you have one victim or a campaign.

1. Pull the sign-in and consent events for the consenting user at the time of consent. Check device, network and whether the sign-in was risky.

2. Search email and chat for the lure: the link, the sender, the lookalike domain. Search for everyone who received it.

3. For an app you own, find who added credentials, certificates, owners or permissions, and from where. Attackers add their own credentials alongside the legitimate ones, which is the technique MITRE tracks as Additional Cloud Credentials.

4. Look at what the acting account did next. A compromised account that registers apps may also have added roles, mail rules or forwarding.

MITRE ATT&CK tracks stolen or granted OAuth access as Steal Application Access Token (T1528). Its detection notes focus on an unusual app registration followed by user-granted tokens and high-privilege resource access, and on third-party apps reading mail, calendar or files soon after a grant.

Step 5. Contain in the right order

Preserve evidence, then cut access, then rotate. The order matters. Deleting first loses data. Rotating first, while the attacker still holds a valid token, achieves little.

Microsoft’s guidance does not state whether revoking a consent grant invalidates tokens already issued, so confirm the behavior in your tenant and assume the one-hour window applies. If time matters, also disable the affected user sign-in as a short-term step. Blocking all user consent across the tenant is a heavier option with large business impact, and it is better treated as a hardening decision than as incident containment.

Step 6. Reach a scope decision you can defend

End with a statement about data exposure. Use the evidence you have, and say what you could not see.

You are producing the factual basis for a notification decision, not making that decision. State what the evidence supports and where it ends.

Step 7. Hunt for siblings, then harden

• Search for other apps with the same publisher, reply URL, naming pattern or creating account.

• List every user who consented to the app and every other grant with the same scopes.

• List apps in the tenant with application permissions to mail, files or directory data, and confirm each has a business owner.

• Restrict end-user consent, or require an administrator approval workflow.

• Review owners and credentials on high-privilege app registrations regularly. Remove unused apps and test or legacy registrations. The Midnight Blizzard intrusion turned on exactly such a legacy test application.

• Alert on new credentials added to apps, new high-privilege grants and application permissions to mailboxes.

Use this to improve investigation quality and scope determination: open the case with the identifiers in Step 1, classify the pattern before you contain, and end with a scope statement that names what the logs could and could not show.

Sources

• Microsoft Learn: Detect and remediate illicit consent grants — audit review, grant inventory, revocation and auditing prerequisites.

• Microsoft Learn: Revoke user access in Microsoft Entra ID — refresh tokens, access token lifetime and Continuous Access Evaluation.

• Microsoft Security Blog: Midnight Blizzard guidance for responders on nation-state attack — attack chain and OAuth app detection guidance.

• Google Cloud Threat Intelligence: Data theft from Salesforce instances via Salesloft Drift — token theft, actor behavior and recommended response.

• MITRE ATT&CK: Steal Application Access Token (T1528) — detection analytics and mitigations.

• MITRE ATT&CK: Additional Cloud Credentials (T1098.001) — credentials added to applications and service principals.