In the first step it’s very helpful to know the permission and consent framework in the Microsoft Identity platform. You need to understand the delegation process and potential attack surface. Microsoft has already documented this in details: Microsoft identity platform scopes, permissions, and consent | Microsoft Docs

By default, all users in Azure AD can register applications and set consent permission on their behalf. This represent a risk and and you need to ensure that your organization wants to allow end-users to acquire application as self-service without any compliance or risk check. So regardless of phishing attacks this default setting should be reviewed by IT compliance, risk and governance management of your company.

The user settings are splitted in ”User can register applications”…

…and ”Users can consent to apps accessing company data on their behalf”:

Follow Microsoft’s step-by-step guide to find out which setting is configured in your tenant: Configure how end-users consent to applications using Azure AD | Microsoft Docs

Tip: Use the PowerShell cmdlet for monitoring your desired state of the “UsersPermissionToUserConsentToAppEnabled” setting in your tenant.

This default settings makes it easy for users to enable access or onboard any SaaS applications. Nevertheless it is recommended by Microsoft to disable user consent operations. This is also part of the identity secure score:

In the last month we are seeing increased numbers of consent grant attacks by phishing mails but also Microsoft introduced new (public preview) features to detect/manage consent request. By now every organization should review their settings and methods to detect, remediate and mitigate these attacks.

Attack methods and scenarios

Many popular phishing attacks and campaigns tries to take over accounts by user consent requests from apps that looks like Office 365 services. Attackers sending mails with subjects like “storage upgrade” or “shared OneDrive files” to fools the victims that permission to Office 365 is required.

In my opinion it’s unrealistic to prevent this attacks or minimize the risk trough end-user education even by a clear statement during the app consent process:

Source: Azure AD app consent experiences

Once the user has been granted the consent, the attacker has account-level access without stealing credentials or infecting user’s device. Enforcement of MFA and Conditional Access is also not effective because of the interaction model of the application.

It is impressive to see how simple and efficient this attacks can be executed. Joosua Santasalo demonstrates an attack from user and attacker perspective with “Azure AD Consent Extractor” in the following video:

Details on this illicit consent grant attack is described in his blog post.

There are also other real world examples and toolkits for attack scenarios like this:

Microsoft takes care on this attack patterns and tries to detect and remediated the users on the Office 365 platform. In the past phishing campaigns were able to bypass the ATP protection as you can see on several tweets (December 2019, January 2020) from Joe Stocker.

Detection: Several ways for detecting and alerting of suspicious OAuth apps

Microsoft offering several solutions to detect or create alerts in case of consent permission to OAuth apps. This is a summary of different ways to implement a detection:

Investigation and Alerting of OAuth apps with MCAS

Microsoft Cloud App Security (MCAS) is detecting risky OAuth Apps and allows to get insights of app permissions in the portal.

The following information should support your investigation and decision if a consent to a risky app was granted:

  • “Community use” rating to understand how common is the use of this app in other organization (such as default Office 365 apps)
  • Authorized by single/multiple users or admin consented
  • Permission level from Low (Sign-in and read user profile) to High (Access your data anytime)

If you decided to use MCAS you should create a OAuth app policy to be notified in case of risky app consent or registration. Filters for the alert can be set on the above described values.

In addition it makes sense to create an anomaly detection to identify misleading app or publisher names.

Follow Microsoft’s tutorial for guided steps to investigate risky OAuth Apps.

Tip: Consider to report suspected apps to Microsoft’s Cloud App Security team as feedback to enhance OAuth App risk score and analysis.

More details on working with the OAuth apps page are described on Microsoft Docs and further information on managing risky 3rd party app permission with MCAS are available here.

MCAS is the most powerful tool for review of risky OAuth apps and in combination with alerting and global investigation by Azure Sentinel a recommended option.

Azure Monitor Workbooks is visualizing log data from a Log Analytics workspace. Several workbooks related to Azure AD analysis are part of the Azure AD Portal (built-in).

You’ll find an “App Consent Audit” workbook to get more insights on consent permissions and a visual overview of your configuration:

Hunting and Analytics (Alerting) with Azure Sentinel

Threat hunting is one of the essential features of Azure Sentinel and supports search for attackers. The following (built-in) hunting query looks at a period of time for any “Consent to application” operation occurs by a user or app:

The KQL query behind this hunting is also usable for any Log Analytics Workspace Query that contains the latest Azure AD Audit Logs. You’ll find the hunting query in the GitHub repo of Azure Sentinel: Azure-Sentinel/ConsentToApplicationDiscovery.yaml at Azure/Azure-Sentinel · GitHub

You should configure Azure Sentinel or Azure Monitor Alerts (via Azure AD Audit Logs in Log Analytics) if you want to received an alert when a “consent to application“ is triggered.

Microsoft has released a detection rule for this activity on the Azure Sentinel GitHub page: Azure-Sentinel/RareApplicationConsent.yaml at master · Azure/Azure-Sentinel · GitHub

It is available as built-in rule template in Azure Sentinel:

The KQL-based query can be also used in Azure Monitor as Alert rule (Analytics query using Custom Log search) in case you have not already implemented Azure Sentinel. This implies that Azure AD Audit Logs are forwarded to a Log Analytics Workspace.

List grant permissions with PowerShell

Required information of granted permissions are available from Microsoft Graph API. So you are able to build a custom integration for your existing analytics/alert tool or any other programmatically access. Some great PowerShell scripts are already available and “ready to use”.

Get-AzureADPSPermissionGrants.ps1

Philippe Signoret has written a PowerShell script to lists all delegated permission grants. Example:

Get-AzureADServicePrincipal -All $true | .\Get-AzureADPSPermissionGrants.ps1 -Preload

This script is regular updated and available from his GitHub page: Get all permissions granted to an app in Azure AD · GitHub

AzureADAssessment Module (MSCloudIdAssessment)

Microsoft published a PowerShell module to gather configuration information across the Azure AD tenant. It includes a cmdlet (“Get-MSCloudIdConsentGrantList”) to get a list of all consent grants in the directory. Example:

Get-MSCloudIdConsentGrantList | Export-Csv -Path “.\ConsentGrantList.csv”

This module is available from the AzureAD GitHub repo: AzureADAssessment/MSCloudIdAssesment.psm1 at master · AzureAD/AzureADAssessment · GitHub

Option 1: Guided review in Azure AD Portal (required)

Azure AD portal supports you to review the granted permission of an app. Click on the “Review permissions” button on the “Permissions” blade of the app:

Afterwards you have several options to proceed the review:

Choose “This application is malicious and I’m compromised” to get a preview of the required PowerShell scripts to remediate the issue.

All the steps should be executed to ensure that an illicit consent grant attack is remediated:

  • Removal of Service App Role Assigment
  • Revocation of all permission granted to the application (application and delegated permissions)
  • Revocation of refresh token for all users assigned to the application

Automation of threat response can be configured by an Playbook (Logic App) which is triggered by an incident in Azure Sentinel.

You can revoke the OAuth consent grant and Service App Role Assigment with the PowerShell cmdlets (Remove-AzureADOAuth2PermissionGrant and Remove-AzureADServiceAppRoleAssignment) which are already described in Option 1.

Revocation of user’s refresh token is already available as Playbook sample from the Azure Sentinel GitHub repo: Azure-Sentinel/Playbooks/Revoke-AADSignInSessions at master · Azure/Azure-Sentinel · GitHub

Option 3: Ban app from OAuth investigation in MCAS

Suspicioned apps can be marked as banned and will forced to disable permission. Future access of user consent will be automatically revoked by MCAS. Consider in this scenario the delay until the policy effects.

Follow these steps to ban the affected app and notify users who granted access. During my tests I was not able to verify that MCAS will revoke the user’s refresh token automatically. So keep that in mind if you like to include this step in your remediation process.

Users are also able to manage their app (user) consent in MyApps portal including revocation by click on “Remove”:

Not all required steps (that I have already described above) will be executed in this case. So I can’t recommend this option to remediate the issue.

Disable the permission for a user to set consent permission on their behalf is the most effective and easiest way to mitigate this kind of attacks.

Open the “User settings” blade in the Azure (AD) Portal to disable “User can register applications”:

Finally go to the “Enterprise applications” blade (“Manage how end users launch and view their applications”) on the same page to disable consent permissions:

Advice: The only alternative would be to keep the default setting AND using MCAS for reactive measures (including OAuth policies, monitoring and auto-revoke). But this will not mitigate the issue proactively in my opinion. So I’ve decided to exclude this scenario as option for mitigation.

Use case

Initially it is a pain if you are disabling the user consent without any alternate (user friendly) option or process to request consent permission by non-admins. End-users are facing generic error message and increased helpdesk calls will be one of the consequences. Microsoft implemented a new feature to request user consent as part of a workflow:

Benefit

Admin consent workflow gives end-users an option to request a consent permission which can be reviewed by an admin.

Advice: Consider to use least privilege access to approve admin consent requests (prevent usage of Global admin). To approve requests, a reviewer needs cloud application administrator or application administrator only.

Configuration

The configuration of admin consent request and workflow is very easy. You can find the required settings in the blade of the disabled user consent:

The following Microsoft docs article describes how to enable this preview feature in details: Configure the admin consent workflow - Azure Active Directory

Limitations

Currently there are two limitations in the (public preview) implementation:

  1. Only permanent privileged user accounts can be assigned to review consent permissions. You can’t choose an admin with (Azure AD PIM) eligible roles.

UPDATE 01/25/20: You should be able to choose a consent reviewer with an eligible role if the user has activated the role during the time of configuration. Admins with eligible roles will received notifications even if the role isn’t activated. To approval the admin consent as reviewer it is needed to activate the role. Thanks to Stephan Waelde for pointing that out.

  1. Notification are limited to e-mail, no support of Microsoft Graph API to automate the process.

Step 3: Monitoring approved user consents and OAuth apps

Consider to implement an inventory and monitoring of OAuth apps and permissions even if you configure the consent approval flow in your organization. In my opinion MCAS for risk detection and inventory management of your (OAuth) apps is required and has great features. Make sure that every alert will be forwarded to Azure Sentinel or your existing SIEM. This gives you the option for a comprehensive investigation (from phishing mail to consent grant request), hunting and incident management.

Original cover image by Tumisu / Pixabay

You May Also Enjoy

Microsoft Entra Workload ID - Lifecycle Management and Operational Monitoring

22 minute read

Workload identities should be covered by lifecycle management and processes to avoid identity risks such as over-privileged permissions but also inactive (stale) accounts. Regular review of the provisioned non-human identities and permissions should be part of identity operations. In th...

Microsoft Entra Workload ID - Introduction and Delegated Permissions

15 minute read

Workload identities will be used by applications, services or cloud resources for authentication and accessing other services and resources. Especially, organizations which follows a DevOps approach and high automation principals needs to manage those identities at scale and implement p...