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.
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.
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.
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.
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:
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.
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:
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.
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.