There was no breach notification. No ransom demand. No EDR alert.
The client's security team found out only when a routine audit surfaced an unfamiliar third-party application sitting quietly inside their Microsoft 365 tenant — an app that had been reading executive emails and exfiltrating files for eleven weeks.
The attacker never touched a single endpoint. They didn't need to.
This is what modern OAuth abuse looks like in the wild.
WHAT MOST PEOPLE THINK OAUTH IS
OAuth is the plumbing behind "Sign in with Google" and "Connect your calendar."
It lets an app request access to your resources without ever seeing your password. You click Accept, the app gets a token, and it can act on your behalf within the permissions you granted.
Sounds safe. And in theory, it is.
But the "you click Accept" part — that's where attackers have built an entire playbook.
The critical insight: OAuth tokens are not credentials. They're pre-approved keys. And once issued, they don't disappear when you change your password or enable a new MFA factor.
THE ATTACK REALITY
Consent Phishing
The attacker registers a malicious app — often with a convincing name like "Microsoft Teams Helper" or "IT Security Scanner" — and crafts a URL that triggers an OAuth consent prompt.
The email or message looks legitimate. The consent screen itself looks legitimate, because it IS a real Microsoft or Google consent dialog. The only malicious thing is the app behind it.
The victim clicks Accept. Game over — without a single credential being stolen.
Rogue App Registrations
In many enterprise tenants, any authenticated user can register an OAuth application.
Attackers who gain even temporary access — through phishing, leaked tokens, or insider access — register persistent apps before their initial foothold is revoked. The app stays. Their access stays. The compromised account can be fully remediated, and it changes nothing.
Token Theft and Reuse
Access tokens are short-lived, usually lasting an hour. But refresh tokens can be valid for 90 days or more — and in some configurations, indefinitely.
Attackers who steal refresh tokens from browser cache, memory, or token stores can re-authenticate continuously without triggering any credential-based alerts.
A stolen refresh token plus a cloud API equals persistent access from anywhere on the planet — with no malware, no lateral movement, and no endpoint telemetry.
Persistence Without Credentials
Once an attacker has a valid OAuth token or a registered app with active credentials, they no longer need the victim's password. They don't need their MFA codes. They don't need their device.
They are, as far as the cloud platform is concerned, a legitimate authorized application.
STEP-BY-STEP: WHAT A REAL ATTACK LOOKS LIKE
Step 1 — The lure lands. Victim receives an email: "Your organization requires you to authorize the IT Security Compliance app." The link generates a legitimate OAuth consent prompt in the victim's browser.
Step 2 — Permissions granted. Victim sees a real Azure AD consent screen requesting Mail.ReadWrite, Files.ReadWrite.All, and offline_access. They click Accept. It looks routine.
Step 3 — Token issued, persistence established. The attacker's app receives an access token and a long-lived refresh token. They can now call Microsoft Graph APIs on the victim's behalf — from anywhere on earth.
Step 4 — Quiet exfiltration begins. Emails are read. Files are copied. Calendar events are monitored. All via legitimate API calls that blend perfectly into normal cloud traffic.
Step 5 — Password reset. Nothing changes. Security team forces a password reset after detecting suspicious activity. The attacker's refresh token is unaffected. Access continues uninterrupted.
This is the moment that breaks most security teams psychologically. You did everything right — and it didn't matter.
WHY THIS IS DANGEROUS: THE SOC PERSPECTIVE
Traditional detection stacks are built around malware artifacts, lateral movement, and credential abuse. OAuth persistence sidesteps all of it.
No malware artifacts — because there is no malware.
No lateral movement — because the attacker doesn't need it. The cloud APIs provide access to everything.
MFA is bypassed — because the token was already issued with MFA satisfied. The attacker doesn't reauthenticate. They just refresh.
Access looks trusted — because it originates from an application already registered inside your own tenant, calling the same APIs your legitimate SaaS vendors use.
In many environments, the only log entry is a single OAuth consent event — one line that looks identical to a legitimate SaaS app installation.
By the time you find it, you're not hunting an intrusion. You're doing data breach scope analysis.
DETECTION AND THREAT HUNTING
Suspicious OAuth Consent Events
- New app consent grants outside business hours - Consent for high-permission scopes: Mail.ReadWrite, Files.ReadWrite.All, offline_access, Calendars.ReadWrite - Users who have never consented to third-party apps suddenly doing so - Consent events immediately followed by high-volume API activity
Anomalous Token Usage Patterns
- Token usage from IPs inconsistent with the user's baseline geography - Unusual or generic user-agent strings in Microsoft Graph or Google API calls - High-frequency calls to /me/messages, /drive/root, or /users/mailFolders - API calls at hours inconsistent with the user's timezone or work pattern
New and Suspicious App Registrations
- Apps registered by non-admin users - Apps with redirect URIs pointing to external, non-organizational domains - Apps with client secrets created recently but no corresponding approval ticket - Apps with no active users but live, non-expired credentials
Anomalous API Call Patterns
- Bulk email read operations via Graph API - Mass file download or copy via SharePoint or OneDrive API - Service principal activity with no corresponding human login session - Apps calling APIs outside their stated business purpose
Hunting Query Logic (Microsoft Sentinel): Join AuditLogs (OAuth consent events) with AADServicePrincipalSignInLogs on appId. Alert when an app was consented to within the last 30 days and is generating API activity not observed in your baseline.
MITIGATION AND HARDENING
Restrict User Consent — Priority 1
In Microsoft Entra ID: Enterprise Applications → Consent and permissions → User consent settings → Set to "Do not allow user consent" or restrict to verified publishers only.
This single control eliminates the most common consent phishing attack vector.
Require Admin Approval for All App Registrations
Disable self-service app registrations for non-admin users. Every new OAuth app that needs access to organizational data should go through a review process — no exceptions.
Conditional Access Policies
Build policies that restrict which apps can be consented to, from which network locations, and by which user roles. High-privilege scopes should require explicit admin approval with a documented business justification.
Build a Token Revocation Runbook — Before You Need It
When compromise is detected: 1. Revoke all active sessions for the affected user via revokeSignInSessions in Graph API 2. Delete the malicious app registration and its service principal 3. Audit all apps that user had previously consented to 4. Review whether the app was granted admin consent (tenant-wide access)
Practice this before an incident. Fumbling through it during active compromise costs hours.
Continuous App Catalog Monitoring
Deploy a CASB or SSPM tool that continuously monitors your app ecosystem for drift — new apps, new permission grants, apps going dormant, credentials approaching expiry.
What you don't inventory, you can't protect.
WHAT THIS MEANS FOR YOUR PROGRAM
The threat landscape has shifted.
Attackers are no longer optimizing for stealth inside your network. They're optimizing for legitimate-looking access to your cloud. The tools they use are the same tools your employees use every day. The APIs they call are the same APIs your approved SaaS vendors call.
The only thing that separates an attacker's OAuth token from a legitimate one is the consent event that created it. Miss that moment, and you're doing incident response for months.
Your identity perimeter is your new network perimeter. And right now, most organizations are leaving the gate wide open.
Attackers don't always break in anymore — sometimes, they just log in and get permission.