Consent Phishing: Detecting Illicit OAuth Grants

The compromise with no failed login

An analyst pulls the sign-in record for a user who reported something odd. The authentication is clean: correct user, result success, MFA satisfied, normal location, no failed attempts, no impossible travel, nothing the anomaly detections would fire on. By every measure the identity-triage playbook teaches, this sign-in is fine. The analyst closes it. They are wrong, and the breach is already running, because the attack never touched the authentication at all. The user clicked Allow on a consent prompt, and an attacker-controlled application has been reading their mail ever since.

This is consent phishing, and it is the reason application triage exists as a separate discipline. Every detection tuned for a compromised login looks for an authentication that should not have happened. Consent phishing produces an authentication that should have happened, by the real user, from their real device, and then weaponizes what that user authorized. The signal is not in whether the sign-in was legitimate. It is in what the legitimate user was tricked into granting.

Consent phishing persuades a user to grant an attacker-controlled application access to their data through the identity provider's own consent mechanism. The attacker does not steal a password, intercept a token, or relay an MFA prompt. They send a link. The user clicks it, sees a familiar consent prompt ("This application would like to read your mail"), and clicks Allow. The identity provider records the consent, issues the application its own tokens, and the application starts reading data. The credentials were never compromised. The MFA was never challenged. The only thing that happened is that the user authorized a delegation, and the delegation is the attack.

This is a different category from the credential and token attacks. A stolen password or a replayed token creates a session that impersonates the user. A consent-phishing grant creates a separate principal that acts alongside the user, using its own authentication, with permissions the user explicitly authorized. The resulting access does not appear in the interactive sign-in logs because the application never interactively signs in. It authenticates server-to-server through the OAuth token endpoint, invisibly, for as long as the consent remains in place.

The attack pattern

The consent-phishing attack follows a consistent sequence. Understanding the sequence is the prerequisite for detecting it, because each stage leaves a distinct trace, and the triage is the act of lining those traces up against the timeline.

The critical thing to internalize is that stage 3 is the only moment the user does anything, and the only thing they do is click a button. There is no credential entry, no challenge to intercept, no session to steal. The consent prompt is a legitimate UI presented by the identity provider, and the user has seen it before for real applications. The attacker's entire play is making the prompt appear when the user expects to see one (usually embedded in a phishing email disguised as a document-sharing notification or a service-activation link) and choosing an application name and scope set that look plausible enough that the user clicks Allow without reading the permission list.

Why traditional detection misses it

Most identity detections are tuned for authentication anomalies: impossible travel, anomalous IP, failed MFA, brute-force patterns. Consent phishing produces none of these signals. The user authenticates normally from their own device and location, their MFA succeeds (if prompted at all for the consent flow), and the consent event records a successful, policy-compliant action by a legitimate user. The event does not fail any rule that looks for authentication anomalies, because there is no authentication anomaly. The anomaly is in the authorization: what the user granted, to which application, at what time, with what permissions.

This means the detection surface is different from everything you have seen in identity triage so far. You are not hunting for a session that should not exist. You are hunting for a consent that should not have been granted. The signals are in the consent record, the application metadata, and the timeline correlation between the consent and a known phishing delivery.

The five signals that separate illicit from legitimate

Not every consent is an attack. Organizations use hundreds of OAuth-integrated applications legitimately, and every one of them required a consent at some point. The triage question is not "was there a consent" but "was this particular consent legitimate." Five signals, weighed together, make the call.

The signals work as a pattern, not a checklist. A consent with an unverified publisher but appropriate scopes, from the user's normal IP, during a documented rollout, is probably legitimate. A consent with an unverified publisher, over-broad scopes, from an anomalous IP, minutes after a phishing email, with no IT ticket or rollout context, is almost certainly illicit. The judgment lives in how many signals align and how strong each one is. Timing correlation with a phishing delivery is the strongest single indicator, because it places the consent inside an attack timeline. App metadata is the weakest on its own, because many legitimate applications are unverified (small vendors, internal tools, early-stage integrations). Weight each signal by how much it changes the probability the consent is attacker-installed, and let the combined reading make the call.

The judgment under uncertainty

The hard case is the consent that sits in the middle: an unfamiliar application, with somewhat broad permissions, from the user's normal IP, with no clear phishing correlation, but no IT ticket either. The user does not remember granting it. Two of the five signals are present (unfamiliar app, no rollout context), but the strong indicators (phishing timing, anomalous IP) are absent.

The resolution is the same principle you learned in identity triage: when the evidence is genuinely undecided, you do not default to benign. You default to unproven, and you use the cost asymmetry to set your next move. Leaving a legitimate consent in place for another hour while you investigate costs the organization nothing. Leaving a malicious consent in place for another hour costs ongoing data exposure. The correct response to an ambiguous consent is to investigate further (check what the application has actually accessed, examine the application's registration details, ask the user) rather than to clear it because you cannot prove it is malicious. The proof, if it comes, comes from tracing what the application did after the consent was granted, which is the subject of later subs in this module.

Seeing it in the evidence

A practical example that does not depend on a specific environment. An organization receives a report from a user who says they clicked "Allow" on something they now believe was suspicious. They received a document-sharing notification from a colleague, clicked the link to view the document, and were presented with a consent prompt for an application called "Document Viewer Pro" requesting Mail.Read, Mail.ReadWrite, and Files.Read. They clicked Allow. The document never loaded.

sourcetype=o365:cloudapp action=ConsentToApplication
| eval permissions=spath(raw_event_data, "Permissions")
| table _time, user, object_name, permissions, src_ip, src_country
| sort _time

CloudAppEvents
| where ActionType == "ConsentToApplication"
| extend Permissions = tostring(parse_json(RawEventData).Permissions)
| project Timestamp, AccountDisplayName, ObjectName, Permissions, IPAddress, CountryCode
| sort by Timestamp asc

# Consent events with scope detail from the directory audit
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application'" -Top 50 |
  Where-Object { $_.InitiatedBy.User.UserPrincipalName -eq 'reporting.user@contoso.com' } |
  Select-Object ActivityDateTime,
    @{n='App';e={$_.TargetResources[0].DisplayName}},
    @{n='Scopes';e={($_.TargetResources[0].ModifiedProperties | Where-Object DisplayName -eq 'ConsentAction.Permissions').NewValue}},
    @{n='IP';e={$_.AdditionalDetails | Where-Object Key -eq 'IpAddress' | Select-Object -Expand Value}}

The reading resolves quickly once you apply the framework systematically. The timing correlation with the phishing delivery is the anchor: a consent granted within minutes of a suspicious link click, for permissions that exceed the application's stated function, from a user who does not recognize the application and has no IT rollout context. You do not need certainty on all five signals to act. Three strong illicit indicators in the context of an active phishing report is sufficient to treat this as a malicious consent and begin containment.

Your turn

A security alert fires on a new consent grant. The application is "Teams Meeting Recorder," the publisher is unverified, and the scopes are Calendars.Read, OnlineMeetings.Read.All, and Mail.ReadWrite. The consent came from the user's corporate IP at 14:22. There is no phishing email in the user's inbox or quarantine, but the user says they clicked a link in a Teams chat from an external contact. Walk through the five signals and state your read.

Where this leads: you can now identify a consent-phishing attack and assess a consent grant against five weighted signals. The next step is understanding what happens after the consent is recorded: the application signs in under its own identity as a service principal, and the triage question shifts from "was this consent legitimate" to "what is this application doing."