SecWise has seen a growing number of attacks that rely on the “Users can consent to apps accessing company data on their behalf” default configuration in Azure AD, which allows threat actors to get access to users’ data, mails and more. It is therefore strongly advised to turn off this “users’ consent to applications” feature as soon as possible!

Microsoft has been informing companies recently that they should disable this setting, which is unfortunately enabled by default. We have been warning for this specific risk for a long time. During our presentation at InfoSecurity in Brussels in March 2019, we demonstrated how the attack works in this demo-attack simulator.

WARNING: use this demo website only with demo users, not with real users. The website will effectively grab your access token and store it, so it can be used to retrieve your recent emails! It works with Azure AD accounts as well as with live/hotmail accounts.

What is application consent and why is it useful?

Application consent allows users to authenticate third party web apps and mobile apps to use their corporate user accounts. This can be a very useful feature, since it supports single sign-on and prohibits that users have a user account on each website. Keep in mind that many users still reuse the same (or similar) password often, so if a third party web app gets compromised, so are the user accounts and credentials.

If this consent mechanism was purely used for authentication only, there wouldn’t be an issue. This consent mechanism, however, leverages the OAuth permissions-grant feature (part of the OAuth standard) that can also be used to allow one web app to access another web app on behalf of the user.

A nice example of this is https://draw.io. This web application allows you to create small Microsoft Visio-like diagrams and drawings, but does not provide storage capabilities itself. It leverages the OAuth mechanism so users can select their own cloud storage (in this case Google or OneDrive) and it tries to register itself with Azure AD as an “enterprise application” when a user consents to the application using his or her corporate Azure AD account. When users consent, they grant the Draw.io web application access to all of the files on their OneDrive as well as on SharePoint sites (all the files they have access to). Draw.io will even request this access in offline mode, which implies that it continues to have access, even if the user is no longer logged on!

So, while application consent is a nice and useful feature (and even helps to improve the security by providing a controlled single sign-on mechanism), it can also be very dangerous when used in the wrong way.

Why are threat actors using this mechanism now?

Threat actors have recently been using phishing attacks to get hold of corporate user accounts and their credentials. They then misuse those compromised accounts to attack customers and partners through new phishing mails or attack corporate (cloud) applications.

As a defence, many organizations have implemented multi-factor authentication (MFA). Consequently, many of the attacks have been blocked, since a password alone is no longer sufficient to compromise a user.

As a reaction, the threat actors have been leveraging legacy protocols (such as IMAP, POP3 and SMTP) that don’t support MFA and will still allow an attacker backdoor access to emails and other information in an Office 365 tenant. Again, many organizations have blocked these legacy protocols by now and closed this attack path in recent months.

As we predicted almost a year ago at the InfoSec symposium, the application consent mechanism was going to be the next thing that threat actors would focus on. And that’s exactly what is happening now…

Threat actors are using this access for further social engineering, phishing and data exfiltration purposes.

Why doesn’t multi-factor authentication protect me against this attack?

The problem is that application consent (OAuth) is a feature of modern apps and it only becomes a vulnerability if users consent to untrusted or malicious applications… which they unfortunately do, if they are convinced to do so in a well-written phishing mail.

Multi-factor authentication is a mechanism to protect against credentials theft. OAuth-authorizations (the basis for application consent) take place after authentication and MFA does no longer play a role at that point.

Why is this not disabled by default?

As explained above, the application consent feature can be used for good and bad. As risks evolve over time, some features that are intended to protect users (by avoiding that users have credentials in multiple places) can be used against users, if the attack scenario is well-planned (in this case through phishing mails that convince the user to accept the application consent). Unfortunately, the users are often the weak point in the process and if they are not aware of threats, they will make the wrong decision when presented with the choice whether or not to accept a risk.

How to use the new ‘admin consent request’ process

Microsoft has recently released a new process that allows users to forward the application consent request to an administrator, rather than accepting it themselves.

When configured, the user will be shown a dialog that highlights the risk as before (by enumerating all the access rights requested by the app), but instead of allowing the user to accept the consent, he or she can now only forward the request to an administrator, while stating the reason for needing this application. The administrator can then allow or reject the request on behalf of the user or even the whole organization.

How to identify and block invalid app consents using MCAS

Microsoft Cloud App Security (MCAS) provides you with an easy way to keep track of all the web apps your users already have consented to and lets you review and allow or block each one of them.

You can even create custom policies that automate this process and could for example automatically block any app that requests too many access rights, especially if the application is rarely used worldwide.

What should I do now?

Make sure you disable the “application consent by users” today, review all the existing permission grants to third party applications and enable the admin request process on your tenant.

The issues described in this blog clearly highlight the need for continuous security improvements and hardening of all existing and new services in cloud platforms.

In case you need assistance with setting this up correctly, reviewing and hardening your existing configuration or ensuring that you have secured your Microsoft 365 environment correctly, do not hesitate to contact us at info@secwise.be.