Investigating malicious OAuth consent grants
Illicit OAuth consent grants let an attacker keep access to a mailbox or tenant without a password, surviving password resets and MFA. The alert is easy to miss and easy to dismiss. Here is how OwlSOC investigates an OAuth consent-grant alert in Microsoft 365 — what it checks, the verdict it returns, and how containment stays under your control.
Why OAuth consent abuse slips through
In a consent-grant attack, a user is tricked into approving a malicious application's request for permissions — often to read mail and files, or send on their behalf. Once granted, the app has token-based access that does not depend on the user's password, so resetting credentials or enforcing MFA does not remove it. The grant itself can look like routine app onboarding.
Triaging it means asking the right questions about the app and the permissions, not just noting that a consent happened. That context is what usually gets skipped under load.
What OwlSOC checks
When a consent-grant alert fires, OwlSOC investigates the application and the grant in context.
- The application: publisher, age, prevalence in your tenant, and whether it is known or unfamiliar.
- The permissions: how broad and how sensitive the granted scopes are, especially mail and offline access.
- Who consented and how: the user, the sign-in context, and whether it followed a suspicious sign-in.
- What followed: mailbox access, forwarding rules, or data access consistent with abuse.
The verdict, and the evidence behind it
OwlSOC returns a hedged verdict — likely true positive, likely false positive, or uncertain and needs review — with calibrated confidence and an evidence-linked timeline. Every claim cites its source record, so your team can pivot back to the exact consent event and app registration in Microsoft 365 and verify it. The activity is mapped to MITRE ATT&CK.
Because a legitimate business app and a malicious one can look similar at first glance, the hedge and the sourced reasoning matter: you see why OwlSOC leaned the way it did, and can overrule it.
Containment stays human-approved
For a likely malicious grant, OwlSOC will recommend an action — commonly revoking the app's consent and the associated tokens — but a human on your team approves the specific action before it runs, and only on the write scopes you have granted. Read-only by default, every action logged, and reversible actions undoable.
This is a synthetic scenario for illustration; the app, user and tenant are not real customer data. On your tenant, the investigation runs on your own Microsoft 365 signals.
Frequently asked
What is a malicious OAuth consent grant?
It is an attack where a user approves a malicious application's request for permissions — often to read mail or send on their behalf. The app then has token-based access that survives password resets and MFA, because it does not rely on the user's credentials.
How does OwlSOC investigate an OAuth consent-grant alert?
It examines the application's publisher and prevalence, the sensitivity of the granted permissions, the consent context, and any follow-on mailbox activity, then returns a hedged verdict with an evidence-linked timeline and MITRE ATT&CK mapping. Every claim traces back to the source event in Microsoft 365.
Can OwlSOC revoke the app's consent automatically?
No. It recommends revoking the consent and tokens, but a human on your team approves the action before it runs, and only on the write scopes you have granted. By default OwlSOC is read-only, and every action is logged.
Which Microsoft signals does this use?
OwlSOC connects read-only to Microsoft Defender for Office and Microsoft Sentinel, where consent-grant and related identity signals surface. It investigates the alerts those tools raise rather than replacing them.
Start with a 30-day refundable pilot. £495, one environment, every alert investigated, a full report at week four. Read-only, live within 48 hours of access.