Consent phishing – Why you need to act right now

Most organizations have already implemented technical and organizational measures to protect against common threats such as email phishing, credential compromise, spear phishing, malware, and spam.

Some of you have progressed even further and have mechanisms, methodology, and the training to identify and protect against more advanced attacks such as whaling, angler phishing, smishing, and vishing.

But very few have heard about, and therefore not even though about implementing measures to protect against consent phishing.

 

So, what is consent phishing?
In consent phishing attacks, the user sees a pop-up from an application requesting extensive permissions. This consent screen lists all the permissions the app will receive, and many users may go on to accept the terms uncritically because they assume the app is trustworthy. 

Here is an example: 

consent_phishing_blog_1

By accepting this, either on behalf of themselves or, if the user has the right privileges, for the whole organization, they will grant the attackers application extensive permissions to organizational data. There is a high and real threat that the attack will be granted access to sensitive data.

 

 

 

Microsoft's description of the steps in such an attack:

While each attack tends to vary, the core steps usually look something like this:

  1. An attacker registers an app with an OAuth 2.0 provider, such as Azure Active Directory.
  2. The app is configured to make it seem trustworthy, like using the name of a popular product used in the same ecosystem.
  3. The attacker gets a link in front of users, which may be done through conventional email-based phishing, compromising a non-malicious website, or other techniques.
  4. The user clicks the link and is shown an authentic consent prompt asking them to grant the malicious app permissions to data.
  5. If a user clicks accept, they will grant the app permissions to access sensitive data.
  6. The app gets an authorization code, which it redeems for an access token, and potentially a refresh token.
  7. The access token is used to make API calls on behalf of the user.
  8. The attacker can then access the user's mail, forwarding rules, files, contacts, notes, profiles, and other sensitive data.

 

 

How do you protect yourself against such an attack?

Aside from the normal procedures, such as awareness training, we highly recommend that you do not allow your end-users to consent to applications accessing your organization's data without admin consent.

 

The process to do so is straight forward, but very important:

  1. Train your admin staff on application consent and what they should look out for.
  2. Review your current applications and remove intrusive and untrustworthy applications
  3. Disallow end users to consent and enable admin consent workflow (preview)
    a. When an end-user tries to sign into a new application, they will need to request an admin's approval.

consent_phishing_blog2

 

We are here to help

If you are unsure about the process of enabling admin consent, need training on the functionality, or want us to audit your current environment, we are here to help.

 

We have extensive knowledge about Microsoft 365 and how to configure your environment and ensure its secured. We can lead you through the whole process of protecting your organization against consent phishing by helping your organization implementing the correct procedures and measures to protect it. We can assist your admin staff, notify your end-users, and audit your whole Microsoft 365 environment. We are also more than happy to help you in remediating any problems discovered through the audit.

 

To get started, we recommend that you check out our Security Report or do a separate check of enterprise applications and get started with admin consent right away.

 

 

Don't miss a single update

Subscribe to our newsletter