ENTERPRISE SECURITY

OAuth Consent Phishing

Risk assessment, KQL detection queries, and incident response playbook for malicious OAuth app authorization in Microsoft 365 / Entra ID.

Entra IDMicrosoft SentinelExchange OnlineSharePointMicrosoft Graph

DEFENSE ARCHITECTURE — 4 LAYERS

0%

Initial

InitialDevelopingDefinedManagedOptimizing

0/22 controls

Prevention LayerStop malicious consent before it happens0/5

Restrict user consent to verified publishers + low-risk scopes only

Entra ID → Enterprise Apps → Consent and permissions → User consent settings → 'Allow user consent for apps from verified publishers'

# PowerShell: restrict to verified publishers + low-risk scopes
Update-MgPolicyAuthorizationPolicy -BodyParameter @{
  permissionGrantPolicyIdsAssignedToDefaultUserRole = @(
    "ManagePermissionGrantsForSelf.microsoft-user-default-low"
  )
}

Admin consent workflow enabled with named reviewers

Entra ID → Enterprise Apps → User settings → Admin consent requests → Enabled. Assign Cloud Application Administrator as reviewer with email notifications on.

Conditional Access: block sign-in to apps by unverified publishers

Create a CA policy scoped to all users → Cloud apps: All cloud apps → Grant: Require app to be compliant OR from verified publisher. Exclude break-glass accounts.

App Governance policy: auto-disable high-risk new apps (MCAS P2)

Microsoft Defender for Cloud Apps → App Governance → Policies → New policy: trigger on 'New app registered', condition: unverified publisher + high-risk scope, action: disable app and alert.

Published approved-app catalog for users to self-serve

Reduces shadow IT and helpdesk load. Users check catalog before submitting admin consent request. Host on SharePoint or your intranet.

Detection LayerAlert on suspicious consent events and post-consent activity0/7

AuditLogs (Entra ID) streaming to Microsoft Sentinel workspace

Entra ID → Diagnostic settings → Add diagnostic setting → AuditLogs → Send to Log Analytics workspace (same workspace as Sentinel).

# Verify AuditLogs are flowing — run in Sentinel Log Analytics
AuditLogs
| where TimeGenerated > ago(1h)
| take 5

SigninLogs (Entra ID) streaming to Microsoft Sentinel workspace

Same diagnostic settings blade — add SigninLogs. Required for non-interactive token usage detection.

SigninLogs
| where TimeGenerated > ago(1h)
| where IsInteractive == false
| take 5

OfficeActivity (Unified Audit Log) connected via M365 Defender data connector

Sentinel → Data connectors → Microsoft 365 (formerly Office 365) → Connect. Verify Exchange, SharePoint, Teams checkboxes are all selected.

OfficeActivity
| where TimeGenerated > ago(1h)
| summarize count() by OfficeWorkload

CloudAppEvents (Defender for Cloud Apps) data connector active

Sentinel → Data connectors → Microsoft Defender for Cloud Apps → Connect. Enable both 'Alerts' and 'Cloud Discovery Logs'.

CloudAppEvents
| where TimeGenerated > ago(24h)
| take 5

MicrosoftGraphActivityLogs (preview) enabled in diagnostic settings

Entra ID → Diagnostic settings → Add diagnostic setting → MicrosoftGraphActivityLogs → Send to Log Analytics. Preview feature — requires Entra ID P1.

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(1h)
| take 5

Sentinel analytics rules deployed for high-risk consent events

Deploy all KQL queries from the KQL Library tab as Scheduled Analytics Rules in Sentinel. Set severity Critical for D1, D4, D7. Set 5-minute check interval.

App Governance anomaly policies enabled in MCAS

Defender for Cloud Apps → App Governance → Policies → Enable built-in anomaly policies: 'App with unusual activity', 'New high-privilege app'.

Response LayerContain and recover from active consent phishing incidents0/4

Sentinel playbook (Logic App) for auto-revoke on Critical consent alert

Automation → Create playbook → trigger: Microsoft Sentinel alert → actions: disable service principal (Graph API) + revoke sessions + Teams/email alert to SOC.

# Manual revoke — run immediately when incident is confirmed
$SpId = "<service-principal-object-id>"
Update-MgServicePrincipal -ServicePrincipalId $SpId -AccountEnabled $false
Get-MgOauth2PermissionGrant -Filter "clientId eq '$SpId'" |
  ForEach-Object { Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id }

IR runbook documented, versioned, and accessible to SOC team

The IR Playbook tab on this page covers the full runbook. Export it and store in your incident response wiki (Confluence, SharePoint, etc.). Review quarterly.

Revocation procedure tested end-to-end in staging (at least annually)

Run a tabletop or purple team exercise: simulate a consent phishing incident, execute the full runbook, measure MTTR (Mean Time to Revoke).

Blocked app watchlist in Sentinel ('BlockedOAuthApps') maintained

Create a Sentinel watchlist named 'BlockedOAuthApps' with AppId as the SearchKey. Add any revoked malicious app. Reference in KQL rules to alert on re-consent attempts.

# Alert if a previously-blocked app is consented again
let Blocked = _GetWatchlist('BlockedOAuthApps') | project AppId = SearchKey;
AuditLogs
| where OperationName == "Consent to application"
| extend AppId = tostring(TargetResources[0].id)
| where AppId in (Blocked)
| project TimeGenerated, AppId,
          AppName = tostring(TargetResources[0].displayName),
          GrantedBy = tostring(InitiatedBy.user.userPrincipalName)

Governance LayerMaintain ongoing visibility and control over OAuth app inventory0/6

All enterprise apps have named business + technical owners in Entra ID

Entra ID → Enterprise Apps → [App] → Owners. Every app needs at least one owner. Apps with no owner = unmanaged attack surface.

# Find enterprise apps with no owner
Get-MgServicePrincipal -All |
  Where-Object { (Get-MgServicePrincipalOwner -ServicePrincipalId $_.Id).Count -eq 0 } |
  Select DisplayName, AppId, CreatedDateTime

Monthly consent event review process in place

Run the 'Hunt: All App Consents' KQL query monthly. Classify each new app as T1–T5. Initiate review for any T3/T4 apps.

Quarterly full app inventory review scheduled and assigned

Identify apps with no sign-in in 90+ days. Initiate owner attestation. Remove apps that fail or have no owner. Review scopes for permission creep.

App risk tiering model (T1–T5 or equivalent) applied to all apps

All apps must be classified. Unclassified = T4 (Restricted) by default until reviewed. See the Governance tab for tier definitions.

App lifecycle process formalized: register → approve → attest → retire

New apps go through security review before consent. Existing apps have annual attestation. No-owner or expired apps are automatically flagged for retirement.

Executive metrics dashboard in place (consent trends, MTTR, apps past review date)

See Governance tab for the 9 key metrics. Build in Power BI over Sentinel Log Analytics or export monthly to CISO report.

Required Data Sources— all 5 needed for full detection coverage