Incident type: OAuth grant abuse
OAuth grants survive password resets and session revocations. An un-revoked grant lets an attacker keep reading mail and sending as the user days after you thought the compromise was fixed.
OAuth grants are the way third-party apps get persistent access to a user’s account without storing the password. Every “sign in with Microsoft” or “sign in with Google” button creates one. OAuth grants survive password resets and session revocations. Even if you reset the password, an attacker holding an OAuth token can keep reading the mailbox, sending mail, and downloading files until the grant itself is revoked.
How attackers abuse OAuth
Two main shapes:
Trick the user into granting. Phishing pages or fake consent prompts ask the user to authorise an attacker-controlled app. The app has names that look legitimate: Mail Sync, Office Helper, Document Viewer, MicrosoftUpdate. Once granted, the attacker’s app has whatever scopes it asked for.
Grant from inside a compromised account. Once inside via a stolen password or session, the attacker grants a malicious app from within the user’s account. The app then has persistent access independent of the password. This is the pattern this lesson focuses on, and the most common one the SOC catches in ITDR incidents.
What the SOC flags
OAuth-grant-abuse incidents typically show:
- A new grant authorised during or shortly after a suspicious sign-in.
- A generic or impersonating display name (
MailSync-Free,Office365Helper). - Broad scopes (
Mail.Read,Mail.Send,Files.ReadWrite). - An unverified or unknown publisher.
The Recommendation includes “review and revoke OAuth grants” as one of the playbook steps. Lesson 12 in this course covers the step in detail.
Why revoking the grant matters
A compromise playbook that resets the password and revokes sessions but does not revoke the malicious OAuth grant leaves the attacker with persistent access. Days later the customer asks why mail is still being forwarded externally even though the compromise was “fixed.” The answer is the un-revoked grant.
The playbook step is short: list the user’s OAuth grants, identify the ones added during the compromise window, revoke them. The compromise window runs from the suspicious sign-in (or initial compromise event) to the completion of session revoke. Grants inside that window are suspect. Grants from two weeks ago by a verified publisher are not.
Legitimate grants vs. compromise grants
Most OAuth grants in any tenant are legitimate. The markers of each:
| Legitimate | Compromise | |
|---|---|---|
| Publisher | Verified, recognisable | Unverified, unknown |
| Display name | Matches a real product | Generic, impersonating |
| Scope | Appropriate to what the app does | Broad (Mail.ReadWrite, Files.ReadWrite.All) |
| Timing | No co-occurring compromise events | During or after suspicious sign-in |
| User awareness | User can articulate why they granted | User did not consent, or was compromised at the time |
A worked scenario
High-severity ITDR on priya.nair@example.com. Timeline: 14:08 suspicious sign-in; 14:10 OAuth grant to MailSync-Free (publisher unverified, scopes include Mail.ReadWrite); 14:12 inbox rule created. Recommendation: revoke sessions, reset password and MFA, remove inbox rule, revoke OAuth grant to MailSync-Free.