Defending Against Illicit Consent Grants

Problem Overview

Office 365 Security has been tracking an emergent threat to customer data in the Office 365 cloud over the last year. This blog post is intended to help IT Administrators of Office 365 organizations detect, monitor, and remediate this threat. In its simplest form, the attack consists of an adversary creating an Azure registered application which requests access to customer data (contact information, email, documents, etc.), and then tricking an end user into granting that application consent to access their data through a phishing attack, or by injecting illicit code into a trusted website. Once the illicit application has been granted consent, it functionally has account-level access to data but without needing an actual account in the organization. Normal remediation steps like resetting passwords for breached accounts or requiring MFA on accounts is not effective since these third party applications are external to the organization and leverage an interaction model which presumes the caller is automation, and not a human.

We’ve been tracking the pattern over the last year:

We have also became aware of public proof of concept exploits created by security researchers which also leverage the model:

The good news is that this attack pattern is detectable and can be remediated in the Office 365 ecosystem.

Monitoring and Detection

Since the attack pattern used in the wild is non-deterministic, most detection activities will require some kind of human intervention for now. Organizational Administrators should first understand what their current exposure is by enumerating all of the applications that have access to their data. To accomplish this, there are two patterns that can be employed: using powershell, and using the Azure Active Directory Portal.

Enumerating applications with access in your organization with powershell

The simplest way is to run one of these two powershell scripts which will dump all the oauth consent grants and app permissions for all users in your tenancy:

You will need to be a global administrator to run this script. The script will also need to be run as local administrator to ensure you have the latest version of the Active Directory Authentication Library (ADAL) installed or the AzureAD powershell cmdlets installed. Once installed, you can skip the package installation and run the remainder of the script as a normal local user. We highly recommend you require multi-factor authentication on your administrative account and this script will support MFA auth. You can execute the scripts as follows:

  • .\AzureAppEnumerationViaGraph.ps1 -TenantName "YOURDOMAINNAMEHERE"
  • .\AzureAppEnumeration.ps1

Once you have successfully executed the script, it will produce four local, date-stamped, CSV files: A list of all users examined, all of the consent grants in your organization, all application permissions, and all the details about those applications from Azure AD. To look for illicit applications, you should review the contents as follows:

  • Allconsentgrants_DATE.csv. This file will allow you to review all of the scopes requested by the consent grants, visible in the 'scope' column. Look for applications that have requested significant access to content. For example, an application that needs "Mail.Read Mail.Send Contacts.ReadWrite Contacts.ReadWrite.All" permissions is likely very dangerous as it is asking for the ability to read and write contacts for every user in the organization. Asking for permissions to read all contacts is a common harvesting tactic, so scan for that scope as well. Also look for consentType being AllPrincipals as these consent grants apply to all users in the organization.
  • Appassignments_DATE.csv. This file will allow you to review the User with exposure (principalDisplayName), the application with access (resourceDisplayName), and the date the access was granted (creationTimeStamp). Look for recent consent grants (once you have completed your baseline review), any applications that are targeting high profile users or users with admin privileges, and applications with suspicious names.
  • Allappdetails_DATE.csv. This file will allow you to review the name of the application, the publisher name, and the homepage of the application. Look for suspicious names, suspicious publishers, and URL's that are either suspicious, or don't resolve.

Depending on the size of your organization, we recommend at least a weekly review of the most recent consent grants. Another approach to finding consent grant events is to search in the Security and Compliance Center's Audit Log Search. Look for activity called 'Consent to application' and 'Add OAuth2PermissionGrant'. In particular, be on the lookout for IsAdminConsent: True in the Extended Properties as this indicates one of your Global Admins may have granted broad access to data.

Enumerating applications with access in your organization with the Azure Active Directory Portal

The other pattern you can leverage to find illicit applications is to use the Azure Active Directory Portal: If you navigate to the Azure Active Directory blade, select all users, select the user you wish to review the applications that have access to that user's data, then select Applications, you'll be able to see what has privileges. Unfortunately, the only view currently available via the portal is on a per-user basis.

Look for Name, Publisher, Date Assigned and Permissions granted for suspicious indicators.

The final method you can leverage is to have your users individually go to and review their own application access there. They should be able to see all the apps with access, view details about them, including the scope of access, and be able to revoke privileges to suspicious or illicit apps.

Managing applications with access in your organization with Microsoft Cloud App Security (MCAS)

The most complete solution to managing this risk can be achieved if you are a Microsoft 365 Enterprise E5 subscriber, or you have purchased Microsoft Cloud App Security (MCAS) as a standalone product. MCAS has detection, investigation, and remediation workflows built directly into the product. You can find more details about how this works here:


Once you have identified an application with illicit permissions, you have several ways to remove that access.

You can revoke the Oauth consent grant with powershell:

You can revoke the Service App Role Assignment with powershell:

You can revoke the application's permission in the Azure Active Directory Portal by navigating to the affected user in the Azure Active Directory User blade, selecting Applications, selecting the illicit application, then clicking 'Remove' in the drill down:

You can also disable logon to the affected account altogether, which will in turn disable app access to data in that account. This isn't ideal for the end user's productivity, of course, but if you are working to limit impact quickly, it can be a viable short term remediation.

Finally, there is one very coarse grained capability in Office 365 that will allow you to prevent your users from inadvertently granting access to a malicious application. You can turn integrated applications off in your tenancy. This isn't strongly recommended as it severely impairs your users' ability to be productive with third party applications, but you can disable the ability for end users to grant consent on a tenant-wide basis:

The final set of activities you will have to undertake is to perform an investigation against activity data to determine the full scope of the breach. You can use the Security & Compliance Center’s audit log search to accomplish this task. Focus your search on the affected users, the time frames that the illicit application had access, and the permissions that the app had access to. Please make sure you have both mailbox auditing as well as global activity auditing enabled.

Reference Documentation

This article walks admins through various actions they may want to take after realizing there are unexpected applications with access to data:

Here is a high level overview doc on consent and permissions:

There is another overview here, which is part of an article on our app model all up which includes various code samples and walkthroughs:

Here is a content map that links to various consent-related articles:

This article gives a good overview of the Application and Service principal objects that are core to our app model:

Here is an overview of the capabilities admins have to manage user access to apps:

Comments (0)

Skip to main content