Module 15: Investigating Consent Phishing and Illicit OAuth Grants
Consent phishing is the attack that most M365 security teams miss entirely. The attacker does not steal a password. They do not capture a session token. They trick the user into granting a malicious application permission to access their data — and that permission persists indefinitely. Password resets do not help. Token revocation does not help. MFA does not help. The application has its own identity and its own credentials.
Module 14 revealed that OAuth application persistence was the likely explanation for token replay 20 days after containment. This module teaches you to investigate the full OAuth attack: how consent phishing works, how to identify malicious consents in your tenant, what data the application accessed, how to revoke it, and how to prevent it.
What you will build during this module
OAuth Investigation Playbook. Decision tree from consent alert through permission analysis, data access assessment, revocation, and tenant-wide consent audit.
5 Consent Detection Rules. KQL analytics rules covering: consent to high-risk permissions, consent from non-corporate IP, consent to newly registered application, bulk consent across multiple users, and consent followed by API data access.
Consent Review Checklist. Structured review procedure for evaluating OAuth consent requests: permission assessment matrix, publisher verification checks, and risk scoring.
Application Governance Deployment Guide. Configuring admin consent workflow, application permission policies, and Defender for Cloud Apps app governance — with blast radius, rollback, and GRC mapping.
Prerequisites
Complete Modules 1 (Defender XDR), 6 (KQL), 9 (detections), and 13 (token replay — covers OAuth persistence). This module assumes you understand how OAuth tokens work from Module 14.
MITRE ATT&CK techniques covered
T1550.001 (Use Alternate Authentication Material: Application Access Token), T1098.003 (Account Manipulation: Additional Cloud Credentials), T1528 (Steal Application Access Token), T1199 (Trusted Relationship).
Compliance mapping
NIST CSF: PR.AC-4 (Access permissions managed), DE.AE-2 (Anomalous activity detected), RS.MI-1 (Incidents contained). ISO 27001: A.8.9 (Configuration management), A.5.17 (Authentication information). SOC 2: CC6.1 (Logical access controls), CC6.3 (Segregation of duties).
How this module is structured
14.1 — How OAuth Consent Works in M365. The OAuth consent model, delegated vs application permissions, the consent prompt, and why users click “Accept.”
14.2 — Incident Briefing: INC-2026-0325-004. The scenario: Defender for Cloud Apps flags a new application with Mail.ReadWrite.All permissions consented by 12 users in a single day.
14.3 — Identifying Malicious Consent Grants. Audit log queries, permission analysis, application metadata assessment, and publisher verification.
14.4 — Assessing What the Application Accessed. Tracing API calls made by the malicious application — which mailboxes, which files, which directory data.
14.5 — Revocation and Cleanup. Revoking consent, removing the application, and verifying no residual access remains.
14.6 — Tenant-Wide Consent Audit. Auditing all existing consent grants to find other malicious or over-permissioned applications.
14.7 — Preventive Controls. Admin consent workflow, application permission policies, Defender for Cloud Apps app governance, and user education.
14.8 — Detection Engineering. 5 deployable KQL analytics rules for consent phishing detection.
14.9 — Module Assessment. 20 scenario-based questions testing OAuth investigation and governance decisions.