How to Secure Your Apps and Data with Azure Active Directory

There’s a new threat to your business and your users are likely to fall for it if they haven’t already. The threat is phishing apps, or “fake” OAuth apps that users will install and give permissions to. Once the app has been given permissions, the attackers have access and refresh tokens and can use them to penetrate further into your business infrastructure. Note that there isn’t an actual “hack” at play here, the app looks like a legitimate app and asks for permissions just like any other app, it’s just that the app was created by an attacker. A popular way to disguise the app is to give it a name similar to another common app, here in Australia several business users fell for an app that looked similar to Mailguard 365 – a popular email hygiene solution – it got so bad that our Prime Minister gave a speech about it.

This article will show you how this attack works, what options you have to defend your network against it as well as how Multi Factor Authentication (MFA) and Conditional Access (CA) can help protect your business.

We are discussing Azure security in detail on October 7 in our upcoming webinar: How to Fortify your Business with Azure Active Directory. If you haven’t already saved your seat for that one, there’s still time! Save your seat now

A perfect way to walk past your defences

Fake OAuth apps, what Microsoft calls Illicit Consent Grant attacks are hard to defend against, and once the app is installed, even having MFA for all your users (see below) won’t help as the application has been granted the permissions “legally”.

The best way (from Microsoft) to manage this risk is with Microsoft Cloud App Security (MCAS), an excellent Cloud App Security Broker (CASB – think a cloud-based firewall for a modern SaaS world), but one that has a major drawback – it’s only available with Microsoft 365 E5 licensing (or standalone licensing that’s also very expensive). So, if your business doesn’t have M365 E5 licensing for everyone – let’s see what options you have.

Protection without MCAS

Go to aad.portal.azure.com and login with your Global Administrator credentials, go to Enterprise Apps, Consent and Permissions and you should see this:

Azure AD portal Consent and Permissions

Note that all the options we look at here are currently in Preview – a sign of how quickly this has arisen as a security risk – make sure you check with your company policy around using preview features (although, in this case, I think the risk of not doing anything vastly outweighs the risk of a bit of buggy code).

The first three options control what users can do – Do not allow user consent is the hammer – no one except administrators can install apps. In high-security environments, this might be an option, but it will interfere with user productivity. The middle option – Allow user consent for apps from verified publishers, for selected permissions lets users install apps as long as they ask for limited, “less risky” permissions. You can define what permissions you’ll allow, here are the ones Microsoft suggests:

Suggested low impact permissions

If that doesn’t suit your security policies, you can explore a range of APIs and pick exactly the permissions you’re OK with:

Pick an API to define your own low risk permissions

Alternatively, you can pick from the APIs that are used in your organization and build your custom list of allowed permissions.

Pick from APIs that are in use in your organization

Note that this applies to verified publishers – a fairly new concept that Microsoft is still working on where they will verify that Company X that have published an app is actually that company. Be aware that this does NOT confer trustworthiness for the application itself, Microsoft is not analyzing the code for hidden maliciousness, simply verifying who you’re getting the app from.

The third option – Allow user consent for apps lets users consent to any app that doesn’t require admin consent. This just means that they can give permissions to an app to read their email, send email on their behalf of whatever other permissions the app asks for, but not for the entire tenant, only administrators can do the latter. Allowing users to consent to any app permissions for their own data is very risky (as Microsoft points out). As an example, an attacker can learn a lot from reading your emails and do even more damage by sending emails as you.

The other three options on the permissions screen let you manage permissions for group owners, let’s say a Team owner needs an app to manage all messages in a particular Team – settings here let you block all apps, only allow apps to be installed by specific group owners or for all group owners.

What you’d really want though, is for the user to be able to ask an administrator – “Hey, I need to install this amazing app that’s going to make my life so much better – can you allow me to do this?”. That’s called admin consent workflow (additional information), go back to Enterprise applications and click on User settings under Manage, the top three options are exactly the same ones that we looked at above. I’m sure Microsoft is working through these as this is in preview to ensure that they end up with a single UI to control these settings. The bottom half of the blade contains the options for enabling a workflow for apps that are asking for permissions the user doesn’t have rights to grant.

User settings for Admin consent requests

If this is disabled, users will simply be told they need to contact an administrator, but they don’t necessarily know who or what to ask them. When you enable the workflow, you’ll need to define who should receive the requests (and reminders) via email and how long the requests last for.

With this enabled the consent prompt for the user will include the option to request approval and add a justification:

Request approval with justification (Courtesy of Microsoft)

The requests will show up in both email and in Enterprise applications – Admin consent requests under Activity. Once you have reviewed who requested the apps, and what permissions the app is asking for you can either Approve the request (if more than one user has asked for the app, they’ll all be granted access), Deny the request and provide a justification as to why, which doesn’t stop a user from asking for the app again in the future or Block the request. This last one also requires justification from you and will block future requests as well as deny the app.

Looking at this from a real-world / IT consultant perspective I see a few problems with this solution. Firstly, it’ll increase the workload of administrators, depending on the size of the organization and how keen users are on integrating modern, productivity-enhancing apps in Office 365/ Azure. Not only could it lead to a flurry of requests but a responsible security admin also needs to investigate what the app actually does, what will the requested permissions lead to it having access to and what’s the likelihood of it being malicious. It’s still the best option you have.

Secondly, this really only deals with new app requests – you still have to trawl through existing apps that have been approved. Go back to Enterprise applications and pick an app, then select Permissions under Security to manage any admin or user consent. Click Review permissions to pick from a few options that let you control access to the app, revoke all or select users, including invalidating the refresh tokens if you’ve realized that the app is malicious.

Review permissions for an existing app

We’ve all been trained on our personal devices in the dance – install an app, it asks for permissions, say yes or the app doesn’t work. User training is imperative here, not only to make users aware of apps, permissions and the associated risks but also how the admin consent workflow works if you chose to implement it.

Protection with MCAS

If you have implemented MCAS for your business, you have a very powerful tool to manage OAuth apps in your enterprise. It lets you set up alerts based on the level of permissions requested / granted (across Office 365, G Suite and Salesforce apps) and the number of requestors. It also has built-in detection policies for misleading OAuth app / publisher names, and malicious apps identified by Microsoft’s Threat Intelligence. Another nice feature is letting you know how common the app is in other tenants, uncommon apps are far more likely to be malicious.

MCAS OAuth App Policy

You can also hunt through all apps already granted access using various queries, including picking exactly the risky permissions you’re interested in (compare that to the non-MCAS, one app at a time investigation above). If you find a malicious app you can ban it, optionally notifying users.

Conditional Access

Building Conditional Access (CA) policies around conditions such as how sensitive the application that is being accessed is, whether the device is a managed device (either by SCCM on-premises or an MDM) or a personal device, which IP location or country the connection is coming from, which groups the user is a member of, and real-time Azure Identity Protection (IdP) analysis of the sign-in risk improves your security.

Based on these conditions you can block access, allow access, allow access after an MFA prompt, allow access after an MFA prompt and a password reset or provide limited, read-only access in certain applications.

CA Policy for MFA for Administrators

Another very useful task you can use CA for is to block legacy authentication. Many administrators are dismayed to learn that even if you enforce MFA for all your users and administrators you can still be easily compromised if you haven’t disabled legacy protocols. Most attackers will use this avenue for attacks as these older protocols don’t support modern authentication and thus won’t be protected by MFA. All CA policies can be run in report-only mode so that you can see what the impact will be before you move to enforce mode but especially when blocking legacy authentication this is incredibly important. Inevitably there will be some script or legacy application that powers some important business function that’s been sitting there for many years and doesn’t know how to do modern authentication and if you just block legacy authentication outright, it’ll break. Take it from Microsoft (before CA had report-only mode), their team took down the most important tool for the sales team for nearly a full day when they were blocking legacy authentication

Multi Factor Authentication

The single best thing you can do to improve the security of your business, especially in this situation where so many people are working from home, is to enable MFA. Instead of just a username and password, a user now needs to prove who they are with a device. This vastly changes the attacker’s profile from someone who just bought a list of usernames and passwords to someone who now needs to either steal or compromise that device or bypass MFA. Microsoft claims that MFA stops more than 99.9% of identity-based attacks. Everyone who is licensed for Office 365 can turn MFA on at no extra charge, using the free Authenticator App. The best way to enable MFA is through CA policies, alternatively, you can go in and enable it on a per user basis. If you’re having trouble convincing management of the importance of MFA for everyone, please start with all the administrative users – the latest figure I’ve heard from Microsoft is that only 8% of tenants use MFA for their admins – make sure that at least your privileged access is protected.

The challenges with MFA is making sure users are trained and understand what’s happening – the worst thing that could happen is that they get so used to approve the prompt on their device that they’ll do it even when they’re not accessing something. One way to lessen the burden on the users is to allow list IP addresses of your corporate offices so that users aren’t prompted when they’re accessing applications from there but that’s probably less useful today with so many people working from home.

Conclusion

There are real risks posed by OAuth apps, I trust that this article has given you some insight into how you can manage that risk for your business, as well as an overview of CA and MFA as the cornerstones of good identity security hygiene.

If you want to learn more about securing your business with Azure Active Directory, join our free webinar on October 7 How to Fortify your Business with Azure Active Directory.