OAuth token abuse: how the attack works and how to stop it

OAuth token abuse creates persistent access to organizational data that survives password resets and MFA challenges. Because tokens are held by the application rather than the user, resetting a compromised account's password does not revoke existing tokens—particularly those held by confidential client applications or those representing application permissions with no user binding at all.

Eliminating unauthorized access requires removing the permission grant and the service principal, not just resetting credentials. Attackers exploit this to maintain access for months while appearing as authorized applications in audit logs.

Attack surfaces and threat vectors

Consent phishing remains the most common entry point. Attackers register a malicious application in their own tenant—so no application registration event ever appears in the victim's tenant—then distribute phishing links that initiate an OAuth authorization flow. Users who click "Allow" create a service principal in their tenant and grant the attacker's application delegated permissions to act on their behalf. The events that appear in the victim tenant are Add service principal, Consent to application, and Add delegated permission grant.

Understanding the permission model matters here. Delegated permissions—scopes like Mail.Read or Files.ReadWrite—let the application act as the consenting user within that user's existing access. A user consenting to Mail.Read exposes their mailbox, not the entire organization. Org-wide mailbox access requires application permissions such as Mail.Read granted as an app role assignment, which always require admin consent and are recorded as Add app role assignment to service principal. Permissions like Directory.ReadWrite.All cannot be granted by regular users under any circumstances, making them less useful as examples of user-consent abuse; the more realistic high-risk delegated scopes are Mail.Read, Mail.Send, MailboxSettings.ReadWrite, Files.ReadWrite.All, and offline_access, which provides a refresh token enabling long-lived access.

Credential and role additions to existing applications represent a larger persistence risk that often receives less attention. After gaining a foothold—through a compromised admin account or an exploited application—attackers add credentials (certificates or client secrets) to legitimate existing applications or service principals, or assign privileged app roles to an application they control. This technique was central to both the SolarWinds supply chain compromise and the Midnight Blizzard attacks against Microsoft. The result is durable, application-level access that persists independently of any user account.

Device code phishing abuses the OAuth device authorization flow. Attackers trick users into entering a device code at microsoft.com/devicelogin, which transfers a valid token to the attacker's session. Because the user authenticates against a legitimate Microsoft endpoint, standard phishing controls offer limited protection. Admin consent settings do not block this vector.

Abuse of preconsented first-party applications is another vector that admin consent policies do not address. Certain Microsoft applications are granted broad permissions by default at tenant provisioning. Attackers who compromise a user account can leverage these existing grants without triggering any new consent event.

Token scope abuse occurs when applications request permissions beyond their stated purpose—a calendar integration requesting Mail.Send, or a file sync tool requesting MailboxSettings.ReadWrite. The OAuth consent prompt design makes it difficult for users to evaluate what a permission combination actually enables.

Business impact

Compromised OAuth tokens provide ongoing access to email archives, document repositories, and collaboration platforms. Because application-level tokens are not tied to a user session, they persist through password resets, account lockouts, and even user offboarding if the service principal itself is not removed. This enables data exfiltration campaigns that operate long after the initial access event is remediated.

Healthcare organizations face regulatory exposure when malicious applications access patient communications through delegated email permissions. The appropriate framing for financial services organizations is around unauthorized access to confidential internal communications rather than SOX specifically, since SOX audit requirements attach to financial reporting controls rather than general email access. Organizations must demonstrate adequate access controls to regulators regardless of the specific framework.

Remediation at scale creates operational disruption. When consent phishing affects many users, identifying all affected accounts, removing grants and service principals, revoking sessions, and checking for secondary persistence (inbox rules, delegated mailbox access, data already exfiltrated) requires significant effort. Discovery of additional affected accounts is common as investigations proceed.

Detection guidance

Because malicious applications are registered in the attacker's tenant, detection in the victim tenant focuses on service principal creation and consent events rather than application registration events. The relevant Entra ID audit operations to monitor are Add service principal, Consent to application, Add delegated permission grant, and Add app role assignment to service principal.

Note on timing: detection from audit logs is inherently post-consent. The token is issued when consent completes. Prevention through consent configuration is therefore more effective than detection for blocking initial access; detection should focus on identifying successful grants before sustained access causes damage.

The correct table and field names in Microsoft Sentinel use AuditLogs with InitiatedBy for the acting identity. Permission values appear in TargetResources[*].modifiedProperties, not as a flat searchable string. The following patterns illustrate the logic; validate field paths against your tenant's actual log schema before deploying.

// Detect new service principal creation followed by high-risk delegated consent
// Logic pattern — validate field paths for your environment
AuditLogs
| where OperationName == "Consent to application"
| where TimeGenerated > ago(24h)
| extend ConsentedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend AppId = tostring(TargetResources[0].id)
| extend ModifiedProps = TargetResources[0].modifiedProperties
// Permissions live in modifiedProperties; parse for high-risk scopes
| where ModifiedProps has_any ("Mail.Read", "Mail.Send", "Files.ReadWrite.All",
    "MailboxSettings.ReadWrite", "offline_access")
| project TimeGenerated, ConsentedBy, AppId, ModifiedProps

// Detect app role assignments (application permissions) granted to service principals
// These always require admin action and represent high-impact grants
AuditLogs
| where OperationName == "Add app role assignment to service principal"
| where TimeGenerated > ago(7d)
| extend GrantedBy = tostring(InitiatedBy.user.userPrincipalName)
| extend TargetApp = tostring(TargetResources[0].displayName)
| project TimeGenerated, GrantedBy, TargetApp, TargetResources

Credential additions to existing applications and service principals are a high-fidelity signal for post-compromise persistence. Monitor for Add service principal credentials and Update application – Certificates and secrets management events, particularly when the actor is not the registered owner of the application or when the target application is a Microsoft first-party app.

Post-consent application activity is often a better investigative signal than the consent event itself. The IP address recorded at consent is typically the user's normal location—not the attacker's infrastructure. Anomalous application activity appearing in Entra sign-in logs, Defender for Cloud Apps, or resource-level logs (Exchange message trace, SharePoint audit logs) from unexpected IP ranges after a consent grant provides higher-fidelity evidence of active exploitation.

Behavioral checks—such as whether an application's actual data access matches its stated purpose—are not available natively through Entra audit logs or Conditional Access. This capability comes from Microsoft Defender for Cloud Apps app governance, which provides policy-based controls on application behavior and data access patterns.

Mitigation strategies

Configure user consent settings as the highest-priority control. Under Microsoft Entra ID > Enterprise applications > Consent and permissions, restrict user consent to applications from verified publishers requesting only low-impact permissions, or disable user consent entirely and require admin approval for all applications. Verify current defaults against Microsoft's current documentation, as these settings have changed in recent product updates. Admin consent workflow configuration has limited value if user consent is not simultaneously restricted—enabling the workflow while leaving user consent unrestricted does not prevent users from granting permissions directly.

Require admin consent for all high-risk permission scopes. Application permissions always require admin consent by design. For delegated permissions, the consent settings above control what users can approve; scopes like Mail.Read, Mail.Send, Files.ReadWrite.All, MailboxSettings.ReadWrite, and offline_access should require administrative review before approval.

Maintain an approved application inventory that defines authorized OAuth applications, their permitted scopes, the business justification, and approved user populations. Application consent policies in Entra ID can enforce allow-lists based on verified publisher status, specific application IDs, and permission sets. These policies filter on publisher, application ID, and requested permissions; they do not natively evaluate whether permissions match an application's stated purpose—that analysis requires Defender for Cloud Apps app governance.

Monitor and restrict credential additions to applications and service principals. Implement alerts for any credential addition to existing applications, particularly those not following your change management process. Restrict which roles can perform these operations and review existing applications for unexpected credentials regularly.

Establish remediation procedures for confirmed compromises. Password reset alone is insufficient. A complete remediation sequence for confirmed OAuth abuse includes: identifying all delegated permission grants and app role assignments associated with the compromised application or account; removing grants using Remove-MgOAuth2PermissionGrant and removing app role assignments; deleting the malicious service principal from the tenant; revoking all active sessions for affected users; reviewing Exchange Online inbox rules and delegated mailbox permissions for secondary persistence; and reviewing audit logs for data access during the exposure window.

Conditional Access cannot be scoped to intercept OAuth consent flows directly. The effective controls for consent are the user consent settings and app consent policies described above, combined with risk-based step-up consent where supported. Claims that Conditional Access automatically causes malicious consent attempts to fail are overstated—verified publisher status has been obtained by malicious actors in documented cases, and Conditional Access policy does not evaluate the content of a consent request.

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 events
- [ ] 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