Chasing the Token: Forensics of OAuth Consent Phishing in Azure AD

Phishing an inbox used to mean stealing a password, bypassing a multi-factor prompt, and logging in via Outlook Web Access. That is a loud approach that requires human interaction at the exact moment of compromise and almost always triggers impossible travel alerts. Modern adversaries prefer persistence mechanisms that look exactly like routine infrastructure. They do not want a password that expires in ninety days. They want a long-lived, high-privileged OAuth token that completely bypasses standard conditional access policies.

Once a user clicks Accept on a malicious consent prompt, the attacker gains delegated access to the Microsoft Graph. The resulting token survives password resets, ignores FIDO2 requirements for subsequent API calls, and blends effortlessly into the background noise of third-party SaaS integrations. This is the exact mechanism Midnight Blizzard weaponized in late 2023, turning a legacy non-production tenant into a persistent backdoor for Exchange Online mailboxes belonging to senior executives.

Catching this requires shifting your defensive posture from traditional identity logs to application authorization telemetry. We are going to walk through the exact steps required to triage OAuth consent phishing forensics, pulling the forensic thread from the initial grant in the Unified Audit Log to the actual data exfiltration via the Graph API.

The Mechanics of the MFA Bypass

The brilliant cruelty of an illicit consent grant is that it weaponizes the user against their own zero-trust architecture. Instead of presenting a fake login page designed to capture credentials, the attacker registers a multi-tenant application in an external, rogue Azure AD tenant they control. They name it something innocuous like E-Signature Document Portal or HR Benefits Upgrader and configure it to request high-value Microsoft Graph scopes.

When the victim clicks the phishing link, they are routed directly to the genuine Microsoft login portal. They authenticate legitimately. They satisfy their hardware security key or authenticator app requirement without issue. Only after they prove who they are does Microsoft present the prompt asking if this newly registered application can read their mail, access their files, and maintain offline access. Because the authentication phase happened on legitimate Microsoft infrastructure, traditional endpoint controls, network perimeter defenses, and secure email gateways are often entirely blind to the exchange. The only place this event is recorded is deep within your tenant administration logs.

Scopes Define the Blast Radius

The permissions requested dictate exactly what the attacker can do once the token is minted in accordance with the OAuth 2.0 framework defined in RFC 6749. Attackers heavily favor Mail.Read, Mail.ReadWrite, and Mail.Send for business email compromise campaigns, alongside Contacts.Read for discovering internal reporting structures and lateral movement targets. The critical scope that turns a brief intrusion into a persistent nightmare is offline_access.

This specific scope grants a refresh token, allowing the adversary to mint fresh access tokens long after the user closes their browser. This completely severs the attack chain from the user's active session. Once that refresh token is acquired, resetting the user password will not terminate the attacker's access to the mailbox.

Hunting the Initial Grant in the UAL

To find the initial compromise, we have to query the Azure AD audit logs for specific application authorization events. The primary indicator of a compromised user granting access to a rogue application is the Consent to application operation. You need to look for two distinct events happening in rapid succession within your tenant logs.

The Add service principal operation occurs when the external multi-tenant application is instantiated in your local tenant directory for the very first time. Immediately following that, the Consent to application event fires, recording the exact scopes the user authorized. Tracking these paired events is the cornerstone of identifying illicit consent abuse.

{ "OperationName": "Consent to application", "ResultStatus": "Success", "TargetResources": [ { "Type": "ServicePrincipal", "DisplayName": "Payroll Update Portal" } ], "InitiatedBy": { "user": { "userPrincipalName": "target@corporate.com" } } } — Unified Audit Log Snippet

Decoding the Delegated Permissions

Extracting the actual permissions granted requires heavily parsing the ModifiedProperties array nested within the TargetResources field of that specific consent log. You are looking specifically for the ConsentAction.Permissions property. If you see high-privilege Graph API scopes attached to an unverified publisher, you are looking at an active incident.

A major blind spot for security operations centers is failing to correlate these consent grants with the publisher verification status. Attackers frequently use newly created tenants with zero reputation to host their rogue applications. Filtering your audit logs to isolate Add service principal events where the publisher domain is missing, entirely blank, or points to a disposable top-level domain will rapidly narrow your investigation window and surface the most critical anomalies.

Tracing Post-Authorization Graph API Abuse

Identifying the illicit grant is only the first phase of the investigation. You must determine if and how the attacker utilized the token to access data. Because the attacker is calling the Microsoft Graph API directly from their own external infrastructure, these actions do not appear in standard Azure AD non-interactive sign-in logs the way a legacy IMAP connection would.

You have to pivot your search to the Office 365 Management Activity API or the Unified Audit Log and search specifically for MailItemsAccessed events. This level of forensic visibility requires Microsoft Purview Audit Standard or Premium logging to be enabled before the incident occurs. The critical differentiator connecting the authorization to the data theft is the AppId field.

{ "RecordType": 50, "Operation": "MailItemsAccessed", "AppId": "8f7e6d5c-4b3a-2109-8765-43210fedcba9", "ClientIPAddress": "203.0.113.88" } — Purview Audit Log Excerpt

You must meticulously correlate the AppId from the initial consent grant to the AppId recorded in the MailItemsAccessed logs. If those identifiers match, the attacker has successfully synced the victim's mailbox. You can calculate the exact scope of the data exfiltration by analyzing the SessionId and FolderPath fields within those access events. A high volume of access events targeting the Inbox or Sent Items folders within a narrow time window strongly indicates an automated syncing script utilizing the Graph API.

If the attacker utilized Mail.Send scopes to weaponize the compromised account for internal spear-phishing or invoice fraud, you will find corresponding Send events in the Exchange message trace logs. Crucially, messages sent programmatically via the Graph API will often bypass local Outlook client outboxes entirely, leaving absolutely no trace for the end user to discover during their daily workflow.

Baseline Tuning and App Reputation

The hardest part of this specific forensic workflow is distinguishing malicious grants from the relentless volume of legitimate software-as-a-service applications your users authorize every single day. Sales teams authorize customer relationship management integrations. Marketing teams authorize calendar scheduling tools. Shadow IT creates a massive, continuously shifting noise floor of third-party service principals connecting to your tenant.

Establishing the Noise Floor

You must build a baseline of known-good applications based on publisher reputation and strict business justification. Microsoft provides a publisher verification framework designed to add trust to third-party applications, but relying on the blue checkmark alone is dangerously insufficient. Verified publishers get compromised, and their highly trusted service principals are occasionally hijacked by threat actors to completely bypass restrictive tenant configurations that explicitly block unverified apps.

Effective detection engineering requires building custom Sigma rules or KQL queries that trigger on highly specific combinations of risk factors. An isolated consent grant from an executive account, authorizing Mail.ReadWrite to an application registered less than thirty days ago, originating from an unverified publisher, should instantly trigger a critical severity page to the on-call analyst. You have to look at the intersection of identity risk, application age, and scope severity to find the true signal in the audit log noise.

The Containment Runbook

When you confirm a rogue application has been authorized, resetting the compromised user's password does absolutely nothing to stop the bleeding. As long as the attacker holds a valid refresh token tied to a permitted service principal, they retain full access to the granted scopes. You have to sever the authorization layer directly at the application level.

The immediate tactical priority is revoking the OAuth authorization. You must locate the malicious enterprise application in Azure AD and delete the service principal object entirely from your enterprise applications list. This action terminates the application's ability to interact with your tenant's data instantly, effectively bricking the attacker's access tokens.

Burning the Sessions and Persistence

Once the rogue application is destroyed, you must aggressively invalidate the user's active sessions. This requires executing the Revoke-AzureADUserAllRefreshToken PowerShell cmdlet for the compromised identity. Taking this action forces a complete re-authentication cycle for all of the user's legitimate applications and burns any lingering access tokens tied to the compromised session.

Containment ends with heavily auditing the tenant for lingering persistence mechanisms. Attackers who gain initial access via consent phishing heavily favor creating hidden inbox rules, external mail forwarders, or even secondary malicious applications to maintain their foothold long after the primary rogue app is discovered. You must treat the entire mailbox configuration and the user's recent administrative actions as entirely untrusted until a comprehensive forensic review is complete.

The takeaway

Relying purely on impossible travel flags and legacy brute-force alerts leaves your security operations center blind to modern identity attacks. When adversaries shift their focus from stealing the credential to minting the token, defenders must follow suit by treating application authorization as a primary, high-fidelity forensic artifact.

Investigating these complex incidents requires parsing deeply nested JSON arrays and correlating application identifiers across disparate log sources while the clock is ticking on a major data breach. If your security team is struggling to piece together these timelines manually, feeding your Unified Audit Log exports into MailSleuth.AI can automate the extraction of malicious scopes and instantly map the attacker's Graph API access patterns. The rogue tokens are already out there hiding in your tenant logs. Make sure you know exactly what they are reading.