OAuth Consent Phishing: 1-Click OneDrive Theft — Akuity SOC

Identity threat dynamics have shifted: attackers no longer need to spend days bypassing MFA mechanisms via push bombing or adversary-in-the-middle proxies when employees can be tricked into granting direct API access themselves. Categorized as T1566.002 (Consent Phishing) by MITRE ATT&CK, illicit OAuth application consent turns native delegation models into persistent, silent exfiltration conduits.

Attack Anatomy: The OAuth 2.0 Legitimacy Trap

In a typical consent phishing campaign, an adversary registers a multi-tenant application within their own Microsoft Entra ID tenant. They assign the application a deceitful identity (e.g., "OneDrive Sync Assistant" or "Compliance Document Review") and configure an attacker-controlled redirect URI. The targeted user receives a social engineering message across email or Teams prompting them to review an urgent shared file, routing them straight to login.microsoftonline.com.

Because the victim authenticates on the legitimate Microsoft authentication service with their regular MFA credentials, no alarm bells are triggered. The user is then presented with Entra ID's native consent prompt. Clicking "Accept" delegates sensitive Graph permissions directly to the rogue enterprise application. The attacker immediately captures an OAuth refresh token and access token without ever needing the employee's cleartext credentials.

Telemetry and Native Blind Spots

Traditional perimeter and device controls are effectively bypassed: because the app uses the offline_access scope, the adversary can query Microsoft Graph APIs persistently from any external IP address without prompting the user for re-authentication. Furthermore, standard Conditional Access policies targeting user sign-ins do not automatically evaluate continuous token-refresh actions performed directly by rogue delegated apps. While Microsoft Purview records these actions in tenant audit logs, security teams often miss them without specialized detection logic.

Detection with Advanced Hunting (KQL)

To pinpoint suspicious user consents granting sensitive permissions over cloud storage and mailboxes, run this KQL query in Advanced Hunting:

CloudAppEvents
| where ActionType in~ ("Consent to application", "Add delegated permission grant")
| extend Target = parse_json(RawEventData.Target)
| extend AppName = tostring(Target[0].DisplayName),
         AppId = tostring(Target[0].Id)
| extend ModProps = parse_json(RawEventData.ModifiedProperties)
| mv-expand ModProps
| where ModProps.DisplayName =~ "ConsentAction.Permissions"
| extend GrantedScopes = tostring(ModProps.NewValue)
| where GrantedScopes has "offline_access"
    and GrantedScopes has_any ("Files.ReadWrite", "Files.ReadWrite.All", "Mail.ReadWrite", "FullControl")
| project Timestamp, ConsentedBy = AccountDisplayName, IPAddress,
          AppName, AppId, GrantedScopes, UserAgent, ReportId

SOAR Remediation with Akuity SOC

When high-risk OAuth grants appear, Akuity SOC automates full-cycle incident qualification and immediate containment:

• In-App Zero-Trust Qualification: The Akuity SOC built-in AI assistant runs audit_enterprise_apps_permissions in under 2 seconds, exposing dangerous scopes (Files.ReadWrite.All, offline_access) and missing publisher verification without external data leakage.
• Immediate 1-Click SOAR Response: Trigger the revokeOAuthApp() Server Action directly from the incident evidence graph to instantly strip the rogue Service Principal and invalidate all active Entra ID refresh tokens.
• Critical Guardrails & Compliance: Analyst actions require mandatory MFA AAL2 privilege step-up, logging the entire mitigation event into an immutable, audit-ready trail compliant with NIS 2 and SOC 2 Type II standards.

Frequently Asked Questions

Why is the offline_access scope so dangerous in consent attacks?

The offline_access scope allows the application to obtain a refresh token. This allows the attacker to generate new access tokens on demand and interact with Microsoft Graph APIs indefinitely without requiring the victim to be actively logged in or re-prompted.

How does Conditional Access interact with delegated OAuth permissions?

Conditional Access applies policies during the user authentication phase when consent is initially granted. However, unless Continuous Access Evaluation (CAE) or specific application restrictions are enforced, background API access leveraging valid delegated tokens often bypasses device compliance checks.