Use Case: Identity & SaaS
Malicious OAuth app consent
A phishing email linked to an app requesting Mail.ReadWrite and Files.ReadWrite.All on Microsoft 365. 23 employees consented before ManySignal identified the campaign and revoked all grants.
The OAuth grant that bypasses MFA entirely
OAuth consent phishing is one of the most elegant bypass techniques in the attacker's toolkit. Unlike credential theft, it doesn't require the user to hand over their password. Instead, the user is convinced to click "Allow" on an OAuth consent screen for a malicious app. The app receives a persistent access token with the requested permissions — and since OAuth tokens don't require MFA to use, the attacker now has ongoing access even if the user enables MFA afterwards.
This technique was used in the 2017 Google Docs phishing campaign that hit millions of users, and continues to be used against Microsoft 365 environments. Detection requires monitoring the OAuth grant events in real time, evaluating the app's permission scope, and correlating with the email that drove users to the consent page.
rule: malicious_oauth_consent
type: event + reputation + campaign
sources:
- microsoft_365_audit (Consent)
- google_workspace_admin_reports
- email_gateway_logs
trigger:
- event: OAuthConsent OR application.grant
- condition: |
app.publisher_verified == false
OR app.requested_scopes.intersect(high_risk_scopes).count > 2
OR consent_velocity(app_id, 1h) > 5 users
enrichments:
- app_reputation: microsoft_appsource_db, manysignal_malicious_app_list
- email_correlation: phishing_email_sent_to_consenters
- post_grant_activity: mailbox_access, file_access, calendar_read
mitre: T1550.001 (Use Alternate Auth Material: Application Access Token)Legacy SOC comparison
M365's Defender portal surfaces risky app detections — but typically after the app has been active long enough to appear in signals-based analysis. ManySignal detects at consent time, before the app accesses any data, by evaluating the permission scope and publisher reputation the moment the grant event lands in the audit log.
MITRE ATT&CK mapping
OAuth app abuse FAQ
How does ManySignal identify malicious OAuth apps?
ManySignal maintains a reputation database of known-malicious OAuth app IDs and publisher names. For unknown apps, it evaluates the permissions requested (Mail.Read, Files.ReadWrite.All, Contacts.Read), the publisher's age and verification status, and the consent grant pattern — apps consented to by many users in a short window after an external phishing email suggest a coordinated campaign.
Can ManySignal revoke OAuth app consent automatically?
For Microsoft 365 apps consented by users (not admins), ManySignal can revoke the OAuth grant via the Microsoft Graph API as an autonomous action. Admin-consented apps require approve-gated revocation due to broader organizational impact.
What permissions should trigger immediate investigation?
Mail.ReadWrite (full mailbox read/write), Files.ReadWrite.All, Directory.Read.All, and Mail.Send are the highest-risk Microsoft Graph permissions. Any app requesting three or more high-privilege permissions from a first-time user should be reviewed before the consent is processed.
Does this work for Google Workspace OAuth abuse?
Yes. Google Workspace OAuth app grants are monitored via the Admin SDK Reports API. The same permission severity model applies: apps requesting Gmail read access, Drive access, or Admin API scope trigger the detection workflow.
Stop malicious OAuth grants before the app accesses data
Real-time consent monitoring with app reputation scoring for M365 and Google Workspace.