OAuth Token Abuse: Understanding the Attack and How to Prevent It

Post Views: 1

Persistent access to organizational data can be established through OAuth token exploitation, which remains active even after password resets and multi-factor authentication challenges.

Attack surfaces and threat vectors

Consent phishing remains the primary method for initial compromise

Attackers exploit the permission model by targeting delegated scopes such as Mail.Read or Files.ReadWrite, which allow applications to act on behalf of the user within their existing access limits. A user granting Mail.Read permissions exposes their individual mailbox rather than organizational data. In contrast, org-wide mailbox access requires application permissions like Mail.Read, which necessitate admin approval and are logged as “Add app role assignment to service principal.” Certain high-risk delegated scopes, including Mail.Read, Mail.Send, MailboxSettings.ReadWrite, Files.ReadWrite.All, and offline_access, pose significant risks due to their potential for long-term access.

Credential and role additions to existing applications

Attackers inject credentials (certificates or client secrets) into legitimate applications or assign privileged app roles to malicious entities. This technique was pivotal in the SolarWinds supply chain incident and the Midnight Blizzard attacks on Microsoft. The result is resilient, application-level access independent of user accounts.

Device code phishing

Exploits the OAuth device authorization flow by tricking users into entering a code at microsoft.com/devicelogin, which then grants the attacker a valid token. Since authentication occurs at a legitimate Microsoft endpoint, standard phishing defenses offer limited protection. Admin consent settings do not mitigate this risk. Similarly, preconsented first-party applications, which are granted broad permissions by default during tenant provisioning, enable attackers to leverage existing grants without triggering new consent prompts.

Token scope abuse

Applications request permissions beyond their intended purpose, such as a calendar tool requesting Mail.Send or a file sync tool seeking MailboxSettings.ReadWrite. The OAuth consent interface complicates user evaluation of these permission combinations, increasing the likelihood of unintended access.

Business impact

Compromised OAuth tokens provide sustained access to archives, document repositories, and collaboration platforms. Application-level tokens persist through password resets, account lockouts, and user offboarding if the service principal is not removed, enabling prolonged data exfiltration campaigns. Healthcare organizations face regulatory risks when malicious applications access patient communications via delegated permissions. Financial services entities must address unauthorized access to internal communications, as regulatory compliance frameworks focus on access controls rather than specific audit requirements like SOX.

Detection guidance

Malicious applications are often detected through audit logs, though this occurs post-consent. In Microsoft Sentinel, relevant data resides in the AuditLogs table under InitiatedBy for the acting identity. Permission values appear in TargetResources[*].modifiedProperties, not as flat searchable strings. Example queries include detecting new service principal creation followed by high-risk delegated consent or identifying app role assignments granted to service principals. Credential additions to applications and service principals serve as high-fidelity indicators of post-compromise persistence.

Behavioral checks

Verifying if an application’s data access aligns with its stated purpose requires Microsoft Defender for Cloud Apps app governance, as native Entra audit logs lack this capability.

Mitigation strategies

Configuring user consent settings

Restrict user consent to verified publishers with low-impact permissions or enforce admin approval for all applications. Verify current defaults against Microsoft documentation, as settings have evolved. Admin consent workflows alone are insufficient if user consent remains unrestricted.

Approved application inventory

Maintain an approved application inventory defining authorized OAuth applications, their scopes, business justifications, and user populations. Application consent policies in Entra ID can enforce allow-lists based on publisher status, application IDs, and permission sets.

Monitoring credential additions

Implement alerts for unauthorized credential changes and limit who can perform these actions. Establish remediation procedures for confirmed compromises, including removing delegated permission grants, app role assignments, and malicious service principals, revoking sessions, and reviewing Exchange Online inbox rules.

Getting started checklist

Immediate Actions (First Week)

Review and configure user consent settings under Entra ID > Enterprise applications > Consent and permissions; restrict to verified publishers with low-impact permissions or require admin approval for all apps
Audit existing OAuth permission grants and app role assignments for high-risk scopes (Mail.Read, Mail.Send, Files.ReadWrite.All, MailboxSettings.ReadWrite, offline_access)
Configure alerts for Add service principal, Consent to application, Add app role assignment to service principal, and Add service principal credentials
Identify and document approved OAuth applications, their permission scopes, and business owners

Detection Implementation (Weeks 2–3)

Deploy Sentinel queries monitoring consent grants involving high-risk delegated scopes
Configure alerts for credential additions to existing applications and service principals
Establish baseline of normal OAuth application usage patterns using Entra sign-in and audit logs
Evaluate Defender for Cloud Apps app governance for behavioral monitoring of application data access
Configure monitoring for anomalous post-consent application activity in resource-level logs (Exchange, SharePoint)

Policy Configuration (Weeks 3–4)

Configure application consent policies restricting consent based on verified publisher status and permitted permission sets
Establish formal approval workflow for new business applications requiring OAuth integration
Define and document remediation procedures for revoking malicious OAuth applications, including service principal removal and session revocation
Review device code authentication flow controls and consider restricting where business requirements allow

Ongoing Maintenance

Conduct monthly reviews of OAuth application inventory, permission grants, and application credentials
Audit user consent grants quarterly against the approved application inventory
Monitor Microsoft documentation for changes to Entra consent default settings
Train users to recognize OAuth consent phishing, including device code phishing flows, and to report unexpected consent prompts

Remediation efforts at scale create operational challenges. Investigating widespread consent phishing requires identifying affected accounts, removing grants and service principals, revoking sessions, and checking for secondary persistence mechanisms like inbox rules or delegated mailbox access. Ongoing discoveries of additional compromised accounts are common during investigations.