Controlling OAuth app consent in Microsoft 365

A user receives a link that opens a genuine Microsoft sign-in and consent page. The app has a plausible name ('Document Viewer', 'Secure Mail Sync') and asks for permissions such as reading mail, accessing files 'even when you're not there' (offline access), and maintaining access. If the user accepts, Microsoft issues the app tokens. The attacker now reads data through Microsoft Graph from their own infrastructure.

Because access is granted to the app, not the user's session, a password reset or MFA change doesn't stop it. Microsoft's app consent incident response playbook lists the delegated permissions it most often sees misused in consent phishing: Mail.*, Contacts.*, MailboxSettings.*, People.*, Files.*, Notes.*, Directory.AccessAsUser.All and Azure Resource Manager user_impersonation. It notes most people don't think of delegated Mail.Read or Files.Read as high risk, but those are exactly what attackers want.

1. 01

   Start in Enterprise applications

   In the Microsoft Entra admin centre, Enterprise apps lists every app with a service principal in your tenant. Filter for apps that aren't from Microsoft and sort by creation date.

2. 02

   Look at each app's permissions

   For each app, the Permissions page shows admin-consented and user-consented permissions. Admin consent for all users (consent type AllPrincipals) is the highest exposure: the app can reach every user's data within that permission.

3. 03

   Export everything for a full review

   Microsoft's playbook uses the Get-AzureADPSPermissions.ps1 script to export all OAuth consent grants for all users to a CSV for analysis.

4. 04

   Flag the risky ones

   Unfamiliar publisher, unverified publisher, recently created, a single consenting user, broad mail or file permissions, or a name that imitates Microsoft. Ask the consenting user whether they recognize it.

5. 05

   Check the audit log

   Search for 'Consent to application' activity in the audit log around the time a suspicious app appeared. Microsoft notes it can take 30 minutes to 24 hours for entries to appear, and that without auditing enabled before the attack, you won't be able to investigate.

Microsoft's user consent settings live under Enterprise apps > Consent and permissions > User consent settings. The options are:

Restricting consent creates requests, so give people a path. The admin consent workflow (Enterprise apps > Consent and permissions > Admin consent settings) lets users request approval for an app they can't consent to themselves. Set 'Users can request admin consent to apps they are unable to consent to' to Yes, choose reviewers, turn on email notifications and expiry reminders, and set how many days a request stays valid.

Reviewers can view, block or deny requests. Microsoft notes only Global Administrators can approve requests for Microsoft Graph application permissions, and reviewers need the right role to approve others. Agree simple approval criteria: business owner, what data it touches, whether the publisher is verified, and whether a less-privileged alternative exists.

• Review new enterprise applications and new consent grants monthly.
• Alert on 'Consent to application' and 'Add service principal' events if you have Microsoft Sentinel, Defender for Cloud Apps or another SIEM.
• Remove apps nobody uses. Old marketing tools and abandoned integrations keep their permissions until someone revokes them.
• Include app consent in offboarding: when someone leaves, review apps only they consented to.

If client or employee personal information may have been read, talk to your counsel about breach notification obligations. Sources: Microsoft Learn: 'App consent grant investigation' (incident response playbook), 'Configure how users consent to applications', 'Configure the admin consent workflow' and 'Review permissions granted to enterprise applications'.

1. 01

   Record first

   Capture the app's name, application (client) ID, publisher, permissions, consent type, consenting users and creation date, and export the related audit entries.

2. 02

   Cut access

   Disable sign-in for the enterprise app (Properties > Enabled for users to sign-in? = No) so it can't get new tokens, then revoke its permissions and refresh tokens. Microsoft documents revoking permissions and user refresh tokens from the app's Permissions page or with PowerShell.

3. 03

   Scope the access

   Search the audit log for what the app did with the consenting users' mailboxes and files during the window. That determines whether personal or client information was exposed.

4. 04

   Remove it

   Once evidence is preserved, delete the service principal.

5. 05

   Close the door

   Change user consent settings so it can't happen again, and tell staff what the prompt looked like.