Protecting against Malicious Azure AD Applications (Part 1: Admin Consent)

Integrating applications with Azure AD / Office 365 is a great way to extend the capability of the Microsoft Platform with a wide range of apps. This can open possibilities for productivity apps to help users get their work done quicker and more effectively. An example of this is the iOS mail app which relies on the Apple Internet Accounts application. This application allows the native apple mail client to read and process mail on behalf of the user so that they can operate in their chosen app (although I heavily recommend adopting the Outlook mobile app for this use case). By default, when the user launches one of these apps for the first time, they will be prompted to grant consent to various aspects of their profile such as reading mail, contacts, calendars, files (Figure 1) etc. The user grants consent and then the application can work on their behalf, with all access in place to provide some cool functionality.

Figure 1: A typical application consent request

There are of course, risks associated with users granting access to applications, for instance, the application does not need to comply with conditional access or other security implementations that are based on interactive logins. This becomes a problem when we consider that anyone can build these applications and use typical intrusion methods such as Phishing and Social Engineering to convince users to grant consent.

Once a malicious application is granted permissions by a user, the possibilities of what that application can do are only limited by the permission scopes assigned. For instance in the permission scope in Figure 1, the application can access and download or encrypt all of this users files, while simultaneously sending an email as that user to spread the malicious application to other users both internally and externally.

Sounds Bad! What can I do?

I will post another article focusing on remediating suspicious application grants in the future but the most important step to take is to prevent users from consenting to application permissions. This can be done really easily (and I’m baffled it’s not done by default) by navigating to the Azure AD Admin Portal, opening ‘Enterprise Applications’ and then ‘User Settings’. In this page we have some cool options to choose from. Here are the ones I recommend configuring (shown in Figure 2) and a short explanation of each:

  • Users can consent to apps accessing company data on their behalf – Setting this to ‘No’ will prevent users from granting consent to any applications accessing their data
  • Users can consent to apps accessing company data for the groups they own – Setting this to ‘No’ will prevent users from granting consent to any applications accessing data from Groups they own
  • Admin Consent Requests – Setting this to ‘Yes’ will allow users to request approval for an app. This allows Admins to review the app reputation and publisher before approving or denying the request
  • Who can review admin consent requests – Here you can list the approvers for consent requests so they can be managed by the right people
Figure 2: Enforcing Admin Consent Requests in Azure AD

What’s the user experience like?

So now that consent requests are given some much needed control, what does this look like to end users trying to get their job done? Well, taking the example of the legitimate “Apple Internet Accounts” app, a user logs in for the first time to the iOS mail app on their mobile device and they receive the prompt for justification shown in Figure 3.

Figure 3: Azure AD requests justification for the app consent

This request, along with the justification is sent to the approvers specified in Azure AD. They are presented with the information and can approve or deny the request as shown in Figure 4.

Figure 4: Consent request is sent to approvers

When the app is approved it is then available to anyone in the organization who whishes to use it. When in place, app consent can be reviewed from the ‘Enterprise Applications’ page in Azure AD (Figure 5) and consent can be revoked from here.

Figure 5: Reviewing Application Permissions in Azure AD

Summary

This was a short post to highlight an important security setting that can go a long way to protecting your environment. As mentioned, I will do a follow up post looking at how we can detect and remediate malicious apps using Cloud App Security but as a starting point, enabling admin consent is a quick win!

One thought on “Protecting against Malicious Azure AD Applications (Part 1: Admin Consent)

  1. Pingback: Protecting against Malicious Azure AD Applications (Part 2: Investigating using MCAS) – Sean McAvinue

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s