An illicit consent grant is an attack in which a user or administrator is tricked into consenting to a malicious application that then holds durable, non-interactive access to tenant data (MITRE ATT&CK T1528). In Microsoft's description, the attacker registers an application in Microsoft Entra ID that requests access to data such as contacts, email, or documents, then tricks a user, by phishing or by injecting code into a trusted website, into granting that app consent. Once consent is granted, the application has account-level access to the data without needing an account in your organization. Consent phishing is the delivery; the grant is what stays behind after the email is deleted.
Why it matters to a lean team
Three things make this attack awkward for a one to five person security team. It does not look like a compromise: the consent screen lists every permission the app receives, but because the Microsoft identity platform hosts the prompt, users accept it. The usual playbook does not work: Microsoft states that resetting passwords or requiring MFA is not effective because the malicious app is external to the organization. And it does not need an admin. Under the built-in microsoft-user-default-legacy consent policy any user can consent to any permission that does not require admin consent, and the delegated Mail.ReadWrite permission is one of them, so an ordinary user can hand an app read and write access to their own mailbox. What remains is a non-human identity with standing access and no user sign-in to catch.
How it shows up in Microsoft Entra ID
The indicator Microsoft points to is a questionable "Consent to application" activity in the Microsoft Purview audit log, searched from the Microsoft Defender portal; entries can take from 30 minutes up to 24 hours to appear. If IsAdminConsent is True, someone with Global Administrator access may have granted broad access.
The grant itself is a Microsoft Graph object attached to the app's service principal: an OAuth2 permission grant for delegated permissions, an app role assignment for application permissions. A ConsentType of AllPrincipals means the app can access everyone's content in the tenant; native Microsoft 365 apps need it, and every non-Microsoft app with it deserves a careful review. If Microsoft has already disabled the app for violating its terms of service, the application and service principal show DisabledDueToViolationOfServicesAgreement in disabledByMicrosoftStatus; new token requests are denied, but existing access tokens remain valid until they expire.
What to do about it
- Investigate the permissions the app requested, then review Entra audit logs for the app's activity and for sign-ins by users authorized to use it.
- Revoke the grant, not the password: remove the app assignment in the Entra admin center (Users, then the user, then Applications, then the app, then Remove), revoke the OAuth consent grant with
Remove-MgOauth2PermissionGrant, or revoke the app role assignment withRemove-MgServicePrincipalAppRoleAssignment. - Disable sign-in for the affected account as a short-term measure if you also suspect the user's credentials; revoke sessions versus disable user covers what each step ends.
- Do not turn off integrated applications tenant-wide; Microsoft does not recommend it because it blocks all users from consenting to any app.
- Read the grant objects back to confirm they are gone (containment verification), then restrict user consent to verified publishers and the low-risk permissions you select, and review consent grants weekly if you have many registered apps.
The full response for a lean team is in OAuth consent response; the write-capable version of the same problem is Directory.ReadWrite.All.
Where Orbitra fits
Orbitra maps human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, so a consented app appears beside the users whose data it can reach, and roughly 40 percent of its deterministic detection rules target applications, service principals, consent grants, and app credentials. When a grant has to go, the response comes from an allowlisted catalog of more than two dozen governed response actions, and Orbitra independently re-reads Microsoft after supported response actions to verify the final state. In Recommend mode, your team executes the response; in Approve mode, a named person signs off before Orbitra executes. Connect Microsoft in minutes and start read-only.
Related terms
Sources
- Detect and remediate illicit consent grants (Microsoft Learn, checked September 2026)
- Protect against consent phishing (Microsoft Learn, checked September 2026)
- Configure how users consent to applications (Microsoft Learn, checked September 2026)
- Microsoft Graph permissions reference (Microsoft Learn, checked September 2026)