Edit

Detect and Remediate Illicit Consent Grants

Tip

Did you know you can try the features in Microsoft 365 Defender for Office 365 Plan 2 for free? Use the 90-day Defender for Office 365 trial at the Microsoft 365 Defender portal trials hub. Learn about who can sign up and trial terms here.

Summary Learn how to recognize and remediate the illicit consent grants attack in Microsoft 365.

In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. After the illicit application has been granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps, like resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack, since these are third-party applications and are external to the organization.

These attacks leverage an interaction model which presumes the entity that is calling the information is automation and not a human.

Important

Do you suspect you're experiencing problems with illicit consent-grants from an app, right now? Microsoft Defender for Cloud Apps has tools to detect, investigate, and remediate your OAuth apps. This Defender for Cloud Apps article has a tutorial that outlines how to go about investigating risky OAuth apps. You can also set OAuth app policies to investigate app-requested permissions, which users are authorizing these apps, and widely approve or ban these permissions requests.

You need to search the audit log to find signs, also called Indicators of Compromise (IOC) of this attack. For organizations with many Azure-registered applications and a large user base, the best practice is to review your organizations consent grants on a weekly basis.

Steps for finding signs of this attack

  1. Open the Microsoft 365 Defender portal at https://security.microsoft.com and then select Audit. Or, to go directly to the Audit page, use https://security.microsoft.com/auditlogsearch.

  2. On the Audit page, verify that the Search tab is selected, and then configure the following settings:

    • Date and time range
    • Activities: Verify that Show results for all activities is selected.

    When you're finished, click Search.

  3. Click the Activity column to sort the results and look for Consent to application.

  4. Select an entry from the list to see the details of the activity. Check to see if IsAdminConsent is set to True.

Note

It can take from 30 minutes up to 24 hours for the corresponding audit log entry to be displayed in the search results after an event occurs.

The length of time that an audit record is retained and searchable in the audit log depends on your Microsoft 365 subscription, and specifically the type of the license that is assigned to a specific user. For more information, see Audit log.

If this value is true, it indicates that someone with Global Administrator access may have granted broad access to data. If this is unexpected, take steps to confirm an attack.

How to confirm an attack

If you have one or more instances of the IOCs listed above, you need to do further investigation to positively confirm that the attack occurred. You can use any of these three methods to confirm the attack:

  • Inventory applications and their permissions using the Azure Active Directory portal. This method is thorough, but you can only check one user at a time which can be very time consuming if you have many users to check.
  • Inventory applications and their permissions using PowerShell. This is the fastest and most thorough method, with the least amount of overhead.
  • Have your users individually check their apps and permissions and report the results back to the administrators for remediation.

Inventory apps with access in your organization

You can do this for your users with either the Azure Active Directory Portal, or PowerShell or have your users individually enumerate their application access.

Steps for using the Azure Active Directory Portal

You can look up the applications to which any individual user has granted permissions by using the Azure Active Directory Portal at https://portal.azure.com.

  1. Sign in to the Azure portal with administrative rights.
  2. Select the Azure Active Directory blade.
  3. Select Users.
  4. Select the user that you want to review.
  5. Select Applications.

This will show you the apps that are assigned to the user and what permissions the applications have.

Steps for having your users enumerate their application access

Have your users 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.

Steps for doing this with PowerShell

The simplest way to verify the Illicit Consent Grant attack is to run Get-AzureADPSPermissions.ps1, which will dump all the OAuth consent grants and OAuth apps for all users in your tenancy into one .csv file.

Pre-requisites

  • The Azure AD PowerShell library installed.
  • Global administrator rights on the tenant that the script will be run against.
  • Local Administrator on the computer from which will run the scripts.

Important

We highly recommend that you require multi-factor authentication on your administrative account. This script supports MFA authentication.

  1. Sign in to the computer that you will run the script from with local administrator rights.

  2. Download or copy the Get-AzureADPSPermissions.ps1 script from GitHub to a folder from which you will run the script. This will be the same folder to which the output "permissions.csv" file will be written.

  3. Open a PowerShell session as an administrator and open to the folder where you saved the script to.

  4. Connect to your directory using the Connect-AzureAD cmdlet.

  5. Run this PowerShell command:

    .\Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

The script produces one file named Permissions.csv. Follow these steps to look for illicit application permission grants:

  1. In the ConsentType column (column G) search for the value "AllPrinciples". The AllPrincipals permission allows the client application to access everyone's content in the tenancy. Native Microsoft 365 applications need this permission to work correctly. Every non-Microsoft application with this permission should be reviewed carefully.

  2. In the Permission column (column F) review the permissions that each delegated application has to content. Look for "Read" and "Write" permission or "All" permission, and review these carefully because they may not be appropriate.

  3. Review the specific users that have consents granted. If high profile or high impact users have inappropriate consents granted, you should investigate further.

  4. In the ClientDisplayName column (column C) look for apps that seem suspicious. Apps with misspelled names, super bland names, or hacker-sounding names should be reviewed carefully.

Determine the scope of the attack

After you have finished inventorying application access, review the audit log to determine the full scope of the breach. Search on the affected users, the time frames that the illicit application had access to your organization, and the permissions the app had. You can search the audit log in the Microsoft 365 Defender portal.

Important

Mailbox auditing and Activity auditing for admins and users must have been enabled prior to the attack for you to get this information.

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

  • You can revoke the application's permission in the Azure Active Directory Portal by:

    1. Navigate to the affected user in the Azure Active Directory User blade.
    2. Select Applications.
    3. Select the illicit application.
    4. Click Remove in the drill down.

  • You can revoke the OAuth consent grant with PowerShell by following the steps in Remove-AzureADOAuth2PermissionGrant.

  • You can revoke the Service App Role Assignment with PowerShell by following the steps in Remove-AzureADServiceAppRoleAssignment.

  • You can also disable sign-in for 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.

  • You can turn integrated applications off for your tenancy. This is a drastic step that disables the ability for end users to grant consent on a tenant-wide basis. This prevents your users from inadvertently granting access to a malicious application. This isn't strongly recommended as it severely impairs your users' ability to be productive with third party applications. You can do this by following the steps in Turning Integrated Apps on or off.

See also