OAuth consent phishing has been on the rise for a while now. Unsurprisingly, Microsoft has gradually introduced measures to protect from this type of attack.
Risk-Based Step-Up Consent
Initially AzureAD users without premium licenses only had the option to either allow or deny app consent. Later admin consent option was introduced allowing administrators to specify which users within an organization can review app consent. This came together with a new feature where Microsoft tries to detect risky apps (Risk based step-up consent). As a result of this feature, when certain permissions are requested by an app a user will not be allowed to consent and needs to get an admin to consent on their behalf.
This feature has some cool benefits. As an admin you can search for app consent requests that were deemed risky. Or even detect when an admin consents to a risky app. (down below)
Verified Publishers
Recently, Microsoft added more features to control app consent. Consent policies which helps to let users consent to apps from verified publishers requesting a specific list of pre-approved apps. Which helps to reduce the load on admin consent and at the same time making working with apps more user friendly.
We looked at the most common permissions across our clients and found the following top 5:
- User.Read
- offline_access
- openid
- profile
Sounds like we are in luck, Microsoft suggests the same set of permissions as well 😀
Configuring the policies
We can create a policy using the user interface via: AzureAD -> Enterprise Applications -> Consent Policies. We prefer to use the new consent option where users can consent to verified publishers and add the above list as allowed permissions.
We didn’t want to do this manually as we need to be able to check these settings across different client tenants. So we chose to implement to fix this in a PowerShell script. Which does the following:
- Enables User consent for verified publishers
- Disables group consent
- Disables user-consent to risky apps
- Sets the allowed permissions
We also provide a check to see if everything is set like that.
Detection ideas
Fun thing: the “BlockUserConsentForRiskyApps” is also represented in the Azure audit logs. We can use this to detect admins consenting to apps that were labeled as risky:
We can also hunt for users that tried to consent to apps and were stopped because of this feature.
Conclusion
Malicious Azure apps have grown in popularity among scammers. Microsoft has upped their game in providing proper protection. It does require some attention to enable the features on your tenant.