Protecting against OAuth attacks: Setting-up Admin Consent Workflow

During recent weeks, an increase in OAuth phishing attacks has been spotted. OAuth Phishing attacks are an evolution of the old phishing attacks we all know and hate.

During a regular phishing attack a user is sent a suspicious mail where he/she is asked to enter their current Office 365 credentials because there is some sort of error with their account (mail is full, password needs to be reset, mail couldn’t be delivered…). If the user fills in his credentials, the attacker is able to log in and will:

• Use the account to send more phishing mails
• Setup forwarding rules to forward mails to himself
• Monitor the email traffic
• …

These phishing attacks are pretty easy to stop by a few simple steps:

• Setup multifactor authentication
• Monitoring your accounts for suspicious behavior with MCAS

What is OAuth?

OAuth is open source standard that is used by web platforms to grant other platforms access to your environment. AzureAD uses OAuth to allow third party applications to integrate with your Microsoft 365 environment. This makes it possible for users to be able to log into G-Suite, LastPass,… with their AAD credentials. But it is also used by products like CoreView & Veeam to read and process data in your environment.

Before an application can be integrated into a tenant, it needs to be added. This is done through the ‘consent framework’. An app will prompt what permissions are needed for the app to integrate into the tenant and the user will have to accept or deny those permissions.

OAuth Phishing Attacks

OAuth is extremely powerful and really fun to work with. But it does come with it’s dangers. My colleague, Michael Van Horenbeeck, has blogged about it in the past. In this blog he explained how OAuth could be used as ransomware to encrypt a users mailbox. But this also holds true for all Onedrive & Sharepoint libraries the user has access to.

There have been a lot of reports about OAuth phishing attacks where an attacker is given access to a users account and is secretly extracting all the data without the users knowledge.

Blocking Consent

The easiest way to avoid those kind of phishing attacks it to block the ability for a user to consent to applications.

To do this, go to Azure Active Directory, navigate to ‘User Settings’ and select ‘No’ below to option ‘Users can register applications’.

This will block the creation of Applications, but we also need to block the creation of Enterprise Applications (Service Principals).
To do this, go to Azure Active Directory, Enterprise Applications, User Settings and make sure you have disabled to option for users to consent apps to their data. This makes sure that users cannot give access to their own data to external applications.

Edit: There are some new consent capabilities that were introduced in May 2020. More information can be found on the Microsoft docs.

If a user wants access to an app, he will receive the following error message:

Now he should contact an administrator and ask that admin to consent that app manually. This procedure is really cumbersome and not user-friendly at all.

Update July 2020

Microsoft has implemented some more controls for user consent to applications. In the ‘User settings’ pane, there is the option to allow users to consent to apps that access company data for groups they are an owner off. I would still advise this to be turned off, as this can have a huge impact.

The second settings are more interesting, as they enable granular control for consent settings. They are located within the ‘Consent and permissions’ tab.

Here you have three different options for user consent:

1. Do not allow user consent
2. Allow user consent for apps from verified publishers, from selected permissions
3. Allow user consent for apps

For option 2, you can configure which permissions a user can consent too in the ‘permission classifications’ tab. This is a great option if you want to allow users to use their AAD credentials to sign into third party applications, but require admin consent when that applications tries to read any data.

• 

• 

Admin Consent Requests

During Ignite, a new preview was announced that solves the issue I mentioned above. When a user cannot access an app, he is able to request that app to be unblocked.

To enable this workflow, go to Azure Active Directory – Enterprise Applications – User Settings and locate the Ádmin Consent Requests section.

In this section configure the following option:

• Turn on the Workflow
• Select the users that will handle these requests (only global, application or cloud administrators are eligible)
• Choose if the users will receive email notifications
• Choose if the users receive expiration reminders
  • This will send the administrators an extra email when the request is about to expiry
• Configure the consent request expiry date
  • Sets the time an administrator has for approving an application before the request expires.

I recommend to enable email notifications, because this will prevent the need for administrators to check this manually.

Flow

When a user comes across an application that he wants to use, he will receive the following banner:

The user can fill in a business justification for this application. After this, the request is sent to the administrators.

The administrator can view this request in two different ways:

• Going through the email the administrator has received:

• Navigating to the requests portal manually (Azure Active Directory – Enterprise Applications – Admin Consent Requests)

In this portal, the administrator can select an application and view details of the application:

Check which user has requested this application and what justification he was provided:

The administrator has three options:

Reviewing permissions

If the admin chooses to review the permissions he will start the consent workflow and be able to accept the permissions:

When the app is approved, the user who requested this app will receive an email notification that the app is approved for use.

Blocking access

If you choose to block access, the application will be blocked for all users to sign into. The administrator is able to provide a reason:

The user will receive an email with the reason why the administrator has blocked this application.

If you check the app after this process, you will see it is disabled for user sign-in:

Denying access

If you deny access to the application, the application will remain enabled in your tenant (if it was added before), but the extra permissions will not be granted.

This can be useful if you have an app that suddenly wants more permissions.

Thoughts

This admin consent request preview is a really useful feature and will help a lot of companies.

The only thing I am currently missing is Graph support for the requests. Currently only email notifications are supported, but with Graph support a lot of custom actions could be taken so companies can integrate this in their standardized approval flow.