One of the great inversions of the post-2020 attacker playbook is that the user no longer needs to give up a password, they need only to consent. In an illicit consent-grant attack, the entire compromise chain hinges on a single screen the target is already trained to click: the Microsoft "Permissions requested" dialog. No password phish. No MFA-fatigue push storm. No EDR alert. Just a short consent flow and, moments later, an attacker-controlled application holding delegated read/write access to a mailbox, or, with the right scopes, every mailbox in the tenant.

What follows is an explainer of how the technique works, drawn from publicly documented consent-grant attacks and Microsoft's own guidance; the detection-engineering gaps that let it slip past a SOC; and the four Sigma-style rules every team should have shipped to production by the time they finish reading.

1. The mechanism

OAuth 2.0 consent grants are, by design, a delegation primitive. A user authorizes a third-party application, say, a calendar add-on, to act on their behalf against their Microsoft Graph data. The token issued is a legitimate access token signed by the tenant's own identity provider. From the SOC's perspective, the resulting Graph API traffic is indistinguishable from any other authorized app.

The attacker's playbook is now: register tenant app → name it something boring → request Graph permissions → send the consent URL. The target sees a Microsoft-branded dialog asking them to grant "Mail Backup Helper" access to read their mail. Most enterprise users have been conditioned to accept this kind of prompt during routine onboarding.

The attacker has not stolen a credential. They have been given a delegated one. There is nothing for the password-reset playbook to rotate.

2. How it appears in the wild

Publicly documented consent-grant campaigns, from the 2020 wave Microsoft flagged in its own guidance through to the token-abuse tradecraft catalogued by MITRE ATT&CK as T1528 (Steal Application Access Token), tend to reduce to a few recurring variants. None of them require a stolen password.

Variant A, Email-delivered consent

The classic form. A phishing email from a recently registered look-alike domain, often styled as an internal-IT or security-audit notice, links straight to a Microsoft-hosted consent URL for an attacker-registered app. Typical scopes requested are Mail.ReadFiles.Read.All and offline_access, the last one buys a refresh token, so access survives long after the sign-in that granted it. Because both the link and the consent screen are genuine Microsoft endpoints, the lure passes most URL-reputation checks.

Variant B, Low-privilege first, step-up second

A more careful variant asks for almost nothing up front. The first consent requests only User.Read, a low-risk-looking prompt that users wave through, then a second dialog steps the grant up to Mail.ReadWrite once the session is warm. The step-up prompt inherits visual trust from the first one, so a user who has already accepted a harmless-looking scope is more likely to accept the second.

Variant C, Help-desk-assisted consent

Where end-user consent is locked down, the social-engineering target shifts to whoever can consent. A vishing call to the Service Desk requesting an "app re-registration" via a sent link mirrors ordinary SaaS-provisioning procedure, and a help desk empowered to grant admin consent will click it through on a user's behalf. This is why any workflow that lets the help desk consent for others is effectively a Tier-0 privilege.

3. Why your detection stack missed it

Three reasons. First, the Graph API traffic generated by the malicious app is, in network terms, traffic from graph.microsoft.com to itself. No anomalous egress. No callback to an attacker IP. Second, the consent event itself is logged in the Microsoft Entra audit trail under Consent to application, but most SOCs route only sign-in and risky-user events to their SIEM. Third, the application name itself is chosen by the attacker. Defenders are looking for EvilCorp; the attacker named theirs Mail Backup Helper 2026.

4. The four rules you should ship today

  • Detect any consent grant to a non-allowlisted application. Pipe Microsoft.Graph.Audit.ConsentToApplication events to your SIEM. Alert on any consent where the application owner is outside your tenant.
  • Flag step-up consent within 90 seconds of a low-priv consent. The two-step warm-up is one of the strongest behavioural indicators of consent abuse.
  • Alert on any new application requesting Mail.ReadFiles.Read.All, or full_access_as_app. Treat these as Tier-0 grants. Default deny.
  • Audit the Service Desk's consent workflow. If your helpdesk can consent on behalf of users, the helpdesk is now a Tier-0 system. Treat it as such.

5. What we recommend now

Three things, ordered by ROI:

  • Turn on Microsoft Entra's "User consent for applications" setting to Do not allow user consent. Push all consent through an admin-reviewed workflow.
  • Read the dispatch on detection gaps in banks alongside this one, the consent-audit rule it covers is exactly the kind of control that turns an OAuth grant into an alert within minutes instead of a silent foothold that can persist for weeks.
  • If you are not running quarterly adversary simulations that explicitly include OAuth consent abuse in scope, your red-team contract is one quarter behind your threat model.