Entra app consent phishing → Global Admin equivalent
Phish a privileged user to consent to an OAuth app requesting Directory.ReadWrite.All + RoleManagement.ReadWrite.Directory — the app then grants itself Global Administrator.
§ Context
Assumed environment: tenant has user-consent for verified publishers enabled (default until recently). Target has a Global Admin or Privileged Role Administrator role.
§ Steps
- 01Register attacker OAuth appInitial AccessT1078— Valid Accounts
- 02Phish consent link to adminInitial AccessT1566— Phishing
- 03Tenant + user reconReconnaissanceC-AZ-TENANT-RECON— Azure Tenant Reconnaissance
- 04App calls Graph to add itself to roleAssignmentsPrivilege EscalationC-AZ-RBAC-OWNER— Azure RBAC Owner Assignment
- 05Admin clicks → grants delegated + app permissionsPrivilege EscalationC-AZ-APP-CONSENT— Entra App Consent Phishing
- 06Add a client secret to the app for long-term accessPersistenceC-AZ-APP-PERSIST— Entra Application Persistence
§ References
- T1078Valid Accounts
- T1566Phishing
§ Frequently asked
- What is the "Entra app consent phishing → Global Admin equivalent" attack path?
- Phish a privileged user to consent to an OAuth app requesting Directory.ReadWrite.All + RoleManagement.ReadWrite.Directory — the app then grants itself Global Administrator. It chains 6 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Register attacker OAuth app (T1078) — a initial access primitive. Assumed environment: tenant has user-consent for verified publishers enabled (default until recently).
- What is the final impact of this kill-chain?
- The final step lands on Add a client secret to the app for long-term access (C-AZ-APP-PERSIST), which falls under Persistence. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques2
Vish helpdesk → Okta MFA reset → admin → ransomware (MGM-class)
Identify an Okta admin via LinkedIn. Vish the helpdesk pretending to be that admin, get MFA reset. Sign in, plant attacker MFA factor, then push policy changes that disable MFA for chosen apps before mass-deploying ransomware.
- Shared techniques2
FIDO2 caBLE hybrid → phone authenticator hijack
Attacker phishing site shows the legitimate FIDO2 QR. Victim scans with their phone authenticator. The link completes the WebAuthn ceremony in the attacker's browser — they're now signed in as the victim.
- Shared techniques2
Deeplink abuse → in-app account takeover
Exported activity registers a custom URL scheme that triggers an OAuth-style 'confirm reset' action without validating the source — phishing URL clicks reset another user's password.
- Shared techniques2
AITM phishing (Evilginx) → M365 session theft → mailbox exfil
Reverse-proxy phishing kit intercepts the entire login flow including MFA. Stolen session cookie → access M365 mailbox / SharePoint without retriggering auth.
- Shared techniques2
Browser-in-the-Browser → credential theft on a trusted page
Render a fake SSO popup inside the attacker page that looks like a real OS browser window. Victim types their credentials into the attacker's DOM.
- Shared techniques2
OAuth redirect_uri misconfig → account takeover
Provider accepts loose redirect_uri matching (wildcard, partial, open-redirect chain). Steal the authorization code by redirecting it through an attacker host.