Defending Against Illicit Consent Grants

  • Article

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: https://blog.knowbe4.com/heads-up-new-ransomware-strain-encrypts-cloud-email-real-time-video.

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 the below powershell script which will dump all the oauth consent grants and app permissions for all users in your tenancy:

You will need to ensure you have the AzureAD powershell cmdlet library installed and that you have connected to your directory with the Connect-AzureAD commandlet. 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:

  • .\Get-AzureADPSPermissions.ps1 | Export-Csv -Path "permissions.csv" -NoTypeInformation

Once you have successfully executed the script, it will produce one local CSV file. To look for illicit applications, you should review the contents as follows:

  • Review the consents that are of ConsentType of 'AllPrincipals'. These permissions allow the client application to access everyone's content in the tenancy. Several are native O365 applications and are needed to work correctly, but non-Microsoft applications should be reviewed carefully.
  • Review the discrete permissions that each delegated permission or application has to content. Permissions that grant Read and Write permission or *.All should be reviewed carefully for appropriateness.
  • Review the specific users that have consents granted. If high profile or high impact users have inappropriate consents granted, you should investigate further.
  • Review ClientDisplayName for apps that seem suspicious. Apps with mispelled names, super bland names, or hacker-sounding names should be reviewed carefully.

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: https://portal.azure.com. 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 https://myapps.microsoft.com 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: /en-us/cloud-app-security/manage-app-permissions

Remediation

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: /en-us/powershell/module/azuread/Remove-AzureADOAuth2PermissionGrant?view=azureadps-2.0

You can revoke the Service App Role Assignment with powershell: /en-us/powershell/module/azuread/Remove-AzureADServiceAppRoleAssignment?view=azureadps-2.0

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: https://support.office.com/en-us/article/Turning-Integrated-Apps-on-or-off-7e453a40-66df-44ab-92a1-96786cb7fb34

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.

https://support.office.com/en-us/article/Search-the-audit-log-in-the-Office-365-Security-Compliance-Center-0d4d0f35-390b-4518-800e-0c7ec95e946c

Reference Documentation

This article walks admins through various actions they may want to take after realizing there are unexpected applications with access to data: /en-us/azure/active-directory/application-access-unexpected-application

Here is a high level overview doc on consent and permissions: /en-us/azure/active-directory/active-directory-apps-permissions-consent

There is another overview here, which is part of an article on our app model all up which includes various code samples and walkthroughs: /en-us/azure/active-directory/develop/active-directory-integrating-applications#overview-of-the-consent-framework

Here is a content map that links to various consent-related articles: /en-us/azure/active-directory/active-directory-application-dev-development-content-map

This article gives a good overview of the Application and Service principal objects that are core to our app model: /en-us/azure/active-directory/develop/active-directory-application-objects

Here is an overview of the capabilities admins have to manage user access to apps: /en-us/azure/active-directory/active-directory-managing-access-to-apps