Managing OAuth applications with MCAS

In one of my previous blogs, I already talked about the dangers of OAuth and why you should be managing these. Monitoring and managing OAuth applications is also possible with MCAS and actually provides some pretty good insights into the current applications you have and how you should handle new ones.

Connect AAD apps to MCAS

The first step in monitoring Azure Active Directory Enterprise Applications (referred to as OAuth apps in MCAS) is to connect Office 365 with MCAS so that they are synced from AAD to MCAS..

To do this, click on the cogwheel on the top right in the MCAS portal and select ‘app connectors’.

Now, if you haven’t already connected Office 365 click the ‘plus’ sign and select Office 365. If you have already connected it (like me), click the three ellipses on the right and select ‘Edit settings’.

In the settings tab of Office 365, make sure you that the ‘Azure AD Apps’ component is selected. After selecting this component, Azure AD will begin syncing it’s enterprise applications to MCAS. Note that this can take a while, the sync process isn’t instant.

Monitor current applications

After the synchronization is complete, you will find your Azure AD Enterprise applications in ‘OAuth apps’ under the ‘Investigate’ section.

In this section, you will find an overview of all your OAuth applications.

(1) At the top of the screen, you will find a few filters where you can filter on things like users, permissions, permission levels etc. Some of the filter I use a lot are the user filters, where you can filter all the apps for a certain user, but ‘community use’ is a really cool one too. This filter enables you to filter on applications that are in high use within the Microsoft community (which translates to known SaaS applications).

(2) In the application overview, you will find all the applications that your users and administrators have added. Here it’s really easy to see who is using an application and when it was added to the tenant.

(3) For every app, you have two actions ‘Approve’ or ‘Ban’.

Approving an app doesn’t do anything in the background, it just marks it so that you (or another admin) knows that somebody has already looked into this app before.

Banning an application can come in extremely useful and I would like to show what it does exactly.

Banning an application

Image that you have the application ‘calendy’ in your list which has been approved by one of your end-users. In the MCAS overview, you will see some basic insights about the app (like the app website, which can be used to verify the authenticity of an app).

The same app is also visible in the ‘Enterprise application’ section in Azure Active Directory. Here we can see some more information about the app. AAD can be used to check more details about the application.

• 

• 

• 

• 

In the audit logs of the appliation, we can see that MCAS has altered these setting of our AAD Enterprise application.

Policies

With policies in MCAS, you can setup certain conditions when an alert should be created. MCAS policies have different types (like session, file and activity policies). For OAuth apps, we have two options:

• OAuth app anomaly detection policy
• OAuth app policy

There are three default anomaly policies available in MCAS. An administrator cannot create these kind of policies on your own. There are three default policies available though:

• Malicious OAuth app consent
• Misleading publisher name for an OAuth app
• Misleading OAuth app name

These policies can be used to monitor consent to applications that aren’t legitimate, like the ones that are used in phishing campaigns.

The ‘OAuth app policy’ type can be used to create your own, custom policies to monitor applications.

Notification when a new application is added

Some organizations might not be ready to disable user consent to applications, but want to monitor the consent. Or some might want to monitor what other members of the IT team are consenting too. For this we can create a ‘OAuth app policy’.

Navigate to Control > Policies > New and select ‘OAuth app policy’. Configure a correct severity and category for the policy and add description.

• 

• 

Using filters, you can configure when this policy should be triggered. The filters available are:

• App – name of the app
• App state – approved/banned/undetermined
• Community use – Is this app frequently seen within organizations
• Permission level
• Permissions – filter on certain permissions (like read mail)
• Publisher
• User 0n the user which is utilizing this application.

In this scenario, I have filtered on all applications with an app state of ‘undetermined’. This means that this policy will trigger when a new application has been added. You could combine this with a ‘community use’ filter, where you could only create an alert when it is an unknown application.

Inside ‘Governance actions’ you have the ability to automatically revoke this application. You could set this up if certain users (like high level functions) or certain permissions (like reading documents) aren’t allowed and these applications should be banned automatically..

When you enable an email notification for this, you will receive an email each time an application has been added. Do know that there is a delay of about 30-60 minutes between adding the application and the alert being created.

When you click the link from the email, you will be taken to the alert detail page of the application. Here you can find the basic information about your application and approve/ban the application.

Wrapping up

Managing Azure AD applications can be tricky, but is of the utmost importance as they introduce a dangerous exfiltration point of data in your Microsoft 365 environment. Utilizing MCAS can help simply this procedure by monitoring the applications after these are added.

Of course, everything you do with MCAS is done retroactively. I still recommend disabling user app consent (partially) utilizing the controls in Azure AD.