In the last years, illicit concent attacks have been seen in the Microsoft O365 & Azure AD. In this blog post, I show how to find and recognize illicit consent with Cloud App Security (with the twist of Sentinel).
What’s Illicit Consent Grant?
In a nutshell, the attacker creates a multi-tenant application where he/she adds non-admin requiring API permissions for the desired APIs. The attacker then delivers the link to the end-user, which after clicking the link only has to consent (approve) the API permissions for the attacker.
After the consent grant, the attacker has then access to user profiles such as email and documents.
My friend & colleague @santasalojoosua has written an excellent blog about illicit consent grant attack, recommendable reading indeed.
Microsoft description of illicit consent
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 that presumes the entity that is calling the information is automation and not a human.
Tools Available For Detection
Currently, there are many native tools available for monitoring illicit/suspicious consents as Microsoft summarises in the published blog and doc.
- O365 Security & Compliance Center
- Azure AD Application management
- MyApps portal
- PowerShell tools (Get-AzureADPSPermissions)
- Microsoft Cloud App security (we are focusing this one)
I personally have used the Get-AzureADPSPermissions tool to list and identify suspicious consent grants from the tenants. But for now, (as a fan of MCAS) I have found that if MCAS is in use organizations can leverage MCAS built-in functionalities to automatically identify suspicious consents from your tenant.
Information on how to read and what to look from CSV export is found here.
Demo Environment Configuration
I have a hybrid identity model in use where most of my users are located in the on-premises environment and synced to the cloud. Despite that, also cloud-only users exist.
Two single-tenant applications which will make a trick in Cloud App Security end are running at top of Azure WebApps, these are named:
App Registration Controls
There are two settings in Azure AD that affects app registrations and consent grants.
Definitions below (don’t pay attention to how these are configured in my environment, just that those exist is valuable information in here):
- User can register applications – controls whether the user can register applications to the tenant
- User can consent to apps accessing company data on their behalf – controls whether a user can grant consent for apps to their data/profile
Cloud App Security (MCAS)
In Microsoft Cloud App Security aka MCAS, I created two rules in the Threat Detection category. From both rules I will send emails and SMS messages to myself. Rules are:
- Misleading OAuth app name
- OAuth App has permission to modify calendar
Worth to mention is that I needed to add all categories from permission level to get this working as expected – “low, medium, high” and remove all existing OAuth permissions from service principal to get alerts working as expected.
Generating The Alerts
User Experience
The user bob.jones@monae.info navigates to the application which in my case is named MyWebApp18164, gets consent prompt which describes permissions the application would like to have. The user accepts the request and permissions are granted for the application.
Cloud App Security Alerts
After users have granted the permissions following MCAS alerts were delivered to my admin account mailbox.
I also received an SMS message from both alerts as configured on the alert setting.
Alerts and related data from MCAS
The following data (+raw data) is found from MCAS. From the data I can easily evaluate application permissions. In this particular case the permissions are too high and remediation actions are needed.
Click the picture below to open it in a separate window
I Found Illicit Consent – What to do?
If you find an illicit consent you can consider (or just execute) following actions:
- Remove the app from your tenant which removes the app permissions immediately
- Revoke OAuth consent grant from the app
- Disable sign-in possibilities from the app (or from the affected user)
- Ban application via MCAS (which disables sign-in possibility)
Also, consider configuring app registration settings to follow Microsoft’s security best practices. Take into account that If you disable app registration possibility from the end-users it can affect productivity in your tenant.
From another point of view, many organizations want to have control in their own hands, only approved applications are registered in the tenant and consents are only approved by admin. There are also multiple roles available nowadays for this purpose.
Last, but not least, recommendation nowadays from the Secure Score
- Do not allow users to grant consent to unmanaged pplications
Remediation – Ban The Application
If you decide to ban the application from the MCAS portal it will actually disable the usage of the application from Azure AD as seen from pictures below.
Events In Azure AD and MCAS logs
Sentinel – The Twist
In my environment, I have made the integration between Sentinel and MCAS and I’m getting alerts through MCAS connector to Sentinel. I also have activated rules from the Analytics blade which creates an incident in Sentinel every time it gets alert signal from MCAS.
Alerts in Sentinel
Remediation
Remediation inside Sentinel is not covered in this blog post, only showing how to get MCAS alerts to Sentinel. Investigation & threat hunting is worth to another blog post.
Summary
These features and tools have been there for a while, there isn’t nothing new from that perspective. I personally have been investigating Microsoft Cloud App Security for the last two months (kudos to my customers) and have been trying to find ways to automate logging & monitoring as much as I can instead of doing it manually. So, most probably this is not going to be the last post related to Microsoft Cloud App Security.
References
Docs.microsoft.com – Detect and remediate illicit consent grants
Sam's Corner 