Protect yourself from consent phishing

 

Application consent (sometimes called OAuth consent) is the process of a user granting authorization to an application to access protected resources on their behalf. It allows users to authenticate third-party apps to use their existing accounts. Think of when you want to play a game on Facebook or maybe download some kind of add-in for Outlook. Often, you’ll be prompted with something that looks like this -

This may not be a big deal when you’re playing Farmville with your personal account but when a corporate user checks that check box to “Consent on behalf of your organization”, that user could literally be giving that application permissions to your entire organization. In fact, this particular method was used during the SolarWinds/Solorigate campaign so we’ve known about it for some time. Yet many people still haven’t put protections in place to prevent it.

One of the biggest issues with this type of attack is that normal remediation steps, like resetting passwords or requiring MFA, are not effective since these are third-party applications and are external to the organization. These attacks leverage an interaction model that presumes the entity that is calling the information is automation and not a human. We’ve also seen an increase in “consent phishing” where attackers use social engineering techniques to fool a user into granting consent. 

But there are a few ways to restrict user consent to help reduce your surface area and mitigate this risk.

Turn off user application consent

You can quickly stop users from being able to give permissions to applications or just limit which apps they can consent to like applications that have been published by a verified publisher.

1. Sign in to the Azure portal as a Global Administrator.
2. Select Azure Active Directory > Enterprise applications > Consent and permissions > User consent settings.
3. Under User consent for applications, select “Do not allow user consent”.

Create an app consent workflow

As you can see above, once we stop allowing users to grant consent it could mean more work for the admins. And y’all are busy enough as it is. So let’s put a policy in place to enable users to request access to applications that require admin consent.

1. Sign-in to the Azure portal with one of the roles listed in the prerequisites.
2. Search for and select Azure Active Directory.
3. Select Enterprise applications.
4. Under Manage, select User settings. Under Admin consent requests, select Yes for Users can request admin consent to apps they are unable to consent to.

5.  Configure the following settings:

·        Select who will serve as reviewers for admin consent requests - Reviewers can view, block, or deny admin consent requests, but only global administrators can approve admin consent requests. People designated as reviewers can view incoming requests in the My Pending tab after they have been set as reviewers. Any new reviewers won't be able to act on existing or expired admin consent requests.

·        Selected who will receive email notifications for requests - Enable or disable email notifications to the reviewers when a request is made.

·        Selected who will receive request expiration reminders - Enable or disable reminder email notifications to the reviewers when a request is about to expire.

·        Consent request expires after (days) - Specify how long requests stay valid.

After a request is made, you can allow all users to access by granting consent on behalf of all users. Or you can grant consent to a single user using PowerShell.  You can also use application assignment and Conditional Access to restrict user access to specific apps.

 

Now, this doesn’t help when it comes to applications that might already have been given access to your environment but I’ll talk about that in another post.