- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
There are many cyber risks that you need to be on the alert for in your organization: phishing, unpatched vulnerabilities, stolen credentials, and so forth. Now you can add another one to that list: fake OAuth applications. Microsoft calls these illicit consent grants. They're quite simple: attackers create a multitenant application (probably hosted in Azure) and trick one of your users, via a phishing email, text message, or other means, into granting permissions to the application. The app can now use those permissions to penetrate further into your business.
The OAuth model ^
Personally, I blame smart phones. We've all been trained to grant the permissions that an app asks for when we install it from the app store. After all, we know that if we don't, the app won't work.
As with many cybersecurity threats, the app has to look believable, so it might use an email hygiene solution (like the fake Mailguard 365 that Chinese-sponsored hackers have used against Australian businesses with good success), a backup solution, or some other productivity improving app.
The app ecosystem around Microsoft 365, Dynamics 365, etc., relies on the OAuth 2.0 standard for permission delegation. It is connected to OpenID Connect (OIDC) as the authentication layer on top of OAuth and is not to be confused with OATH, which is the initiative for Open Authentication.
Even if your users use MFA for authentication (and they are—aren't they?) or reset their password, the attacker still has the access granted. This might be fairly low-level, but even "read all emails" can be pretty informative and a great starting point for further attacks and lateral movement.
Microsoft has taken a few steps to remedy this situation. One is to verify the publishers of apps, which just confirms that the name of the publisher on the consent screen is indeed the company that made the app (no checking of the app code itself is performed). The latest figure I've seen is that over 700 publishers, covering 1300+ apps, have been verified. There are also two more levels beyond this verification, Publisher Attestation and Microsoft 365 Certification.
There are two models for granting permissions. In the first one, an administrator grants permissions to all the requested data in a tenant (make sure you train your administrators to understand the risks). In the second, a user grants permissions to their own data.
This is what a sample admin consent grant screen looks like:
If you click the chevrons, an explanation of the requested permission is shown.
Another step Microsoft has recently taken (November 8th, 2020) is barring end users from granting permissions to apps from non-verified publishers; this should stop some of these attacks.
If you think it must be hard to create fake apps and publish them, here's an open-source toolkit to help you get started.
Apart from training your users (if you allow them to consent to apps, see below) and training your administrators, an important step is investigating what applications are already in your directory. Finally, you'll need to define corporate policy around these apps and then define guardrails using AAD, and if you have access to it, MCAS.
The Azure AD approach ^
To see what's already in your business, go to the AAD Portal and click Enterprise applications. Pick an application, and in the Security section, click Permissions. This will show you both admin and user consent, the specific permissions, and which API(s) the app is accessing.
If you click Review permissions, you're offered options to control access to the application, plus three levels of scripts and actions to take if you think the app is suspicious or malicious.
Note that this investigation is per app; depending on the number of apps, this could take quite some time.
For new apps, you also have some options in AAD. In the Enterprise application blade, click Consent and permissions. Here, you can block end users from installing any OAuth applications (be aware that they'll probably find a workaround such as using the service directly from a website, giving you even less insight and data protection). Alternatively, you can define a list of low-level permissions that you are OK with users granting to apps from verified publishers, or you can allow them to grant any permissions up to the level of data access they have. You can also control whether group owners can grant permissions to apps for their group; for instance, think apps in Teams.
If you opt for the limited set of permissions, you're taken to a screen where you can take Microsoft's recommendation for what "limited" means, or define your own, based on the APIs available.
The second major improvement that Microsoft has made recently (it's still in preview at the time of writing) is the ability to have an administrator workflow where an end user can ask an admin to review the request and grant any permissions that are above the level that the user can grant. Head to User settings under Enterprise Applications to define which admins get the fun job of deciding whether an app is risky—they can approve a request, deny the request (which won't stop this user or any other user from requesting it in the future), or block it, which will stop future requests.
The Cloud App security approach ^
In the MCAS portal, you start by clicking on Investigate – OAuth apps. This is the same list of applications that are in AAD, but here you can filter by three levels of permissions impact: individual permissions, users, and the level of community use. This last one is interesting because a widely used app is highly unlikely to be malicious, compared to an uncommon or rare one. These options make your job of sifting through a long list of apps easier.
A useful feature in MCAS for any SaaS application is the ability to sanction or unsanction apps, which comes in handy here as well. If you find an app that you don't want used, you can simply un-sanction it, and if you have Microsoft Defender for Endpoint, it'll automatically be blocked on all endpoints. If you use a different EDR, you can use scripts to create rules for your firewalls/reverse proxies to block apps. Furthermore, you can build policies in MCAS around granting OAuth permissions.
Subscribe to 4sysops newsletter!
This is a real risk, and while Microsoft's recent steps will minimize some risk "out of the box," at a minimum, take some time to investigate what apps are already in your directory and what permissions they have. Then build policies around future app installations and make OAuth app permissions part of your security awareness training.
Good luck with your fake OAuth app hunting.