Adversaries are skipping passwords: OAuth consent phishing & token theft are now top initial-access paths

What we're seeing

Across recent incident response cases, the dominant initial-access vector is no longer password spray or basic phishing. Instead, adversaries are abusing OAuth application consent and token theft to gain durable, MFA-bypassing access to cloud data. Tactics include:

• Consent phishing: Users are tricked into granting a seemingly legitimate app offline_access, Mail.Read, Files.Read.All, or Calendar.Read. No password is captured; the attacker receives a refresh token.
• Token replay & session hijack: Stealing refresh/session tokens from unmanaged devices, reverse proxies, or infostealer logs, then replaying them from cloud hosts.
• Illicit app registration: Adversaries create multi-tenant apps with benign names (e.g., “Docs Sync Service”) and weaponize publisher verification trust.
• Living-off-the-SaaS-land: Using Graph/Workspace APIs to silently exfiltrate mailboxes, Drive/SharePoint, and chat histories; creating inbox rules and webhooks for persistence.

Why this works

• Consent prompts are expected in modern SaaS — users approve without reading scopes.
• Refresh tokens can be valid for weeks to months; CA policies often evaluate only at sign-in, not token use.
• Security teams watch “logins”, but much less often app grants, service principal activity, and API scope use.

Who’s at risk

Any org using Microsoft 365/Google Workspace with permissive app-consent, unmanaged BYOD, or legacy EWS/IMAP enabled. High-risk roles: executives, legal, finance, IR teams, and anyone with broad Drive/SharePoint ownership.

Fast hunting ideas

Microsoft 365 (Entra ID / Graph) – KQL:

AuditLogs
| where Category == "Consent" or OperationName has_any ("Add service principal","Consent to application")
| project TimeGenerated, InitiatedBy, TargetResources, ResultReason, CorrelationId

SigninLogs
| where AppDisplayName has_any ("EWS","IMAP","POP","Basic Auth") or ConditionalAccessStatus == "failure"
| summarize count() by AppDisplayName, Location, tostring(DeviceDetail)

Exchange – suspicious inbox rules:

CloudAppEvents
| where ActionType in ("Set-Mailbox","New-InboxRule")
| where RawEventData has_any ("forward","delete","markasread","external")

Google Workspace – Admin Activity:

gws_Activity
| where EventName in ("AUTHORIZE_APP","GRANT_DOMAIN_WIDE_AUTH")
| project Time, Actor, AppName, Scopes

High-impact mitigations (rank-ordered)

1. Lock down app consent: Disable user consent globally; require admin approval workflows. Maintain a known good allow-list.
2. Conditional Access + token protections: Enforce device compliance and Token Protection/token binding where available; enable Continuous Access Evaluation.
3. Disable legacy protocols: Turn off IMAP/POP/EWS Basic. Audit service principals still using them.
4. Alerting: Create detections for new service principals, high-privilege scopes, and inbox rule creation to external domains.
5. Just-in-time approvals: Time-limit risky scopes (Files.Read.All, Mail.ReadWrite). Require business justification in the approval form.
6. Session isolation: Use enterprise browser isolation or tenant restrictions to block token exfil from unmanaged hosts.

Response playbook (condensed)

1. Revoke suspect app consents (Remove-MgOauth2PermissionGrant / Workspace Admin API).
2. Revoke refresh tokens for impacted users; force reauth.
3. Rotate secrets/certs for any abused service principals; remove redirect URIs you don’t recognize.
4. Search mail rules/webhooks; export evidence; notify affected users.
5. Deploy consent governance and CA changes; monitor for re-grant attempts.

Bottom line: Treat OAuth grants and token use as first-class security signals. If you don’t own consent, an attacker will.