In the last couple of months, there is a large increase visible in consent phishing emails (illicit consent attacks). Microsoft threat analysts are tracking a continued increase in consent phishing attempts/mails. This blog described some of the Microsoft prevention/detection capabilities against OAuth Consent phishing.

What is consent phishing?

Consent phishing attacks (Illicit consent attacks) abuse legitimate cloud service providers, including Microsoft, Meta, Google, and others that use OAuth 2.0 authorization. OAuth 2.0 is a widely used protocol that allows third-party apps to access account details and perform an action on their behalf.

The main goal of a consent phishing attack is to let users grant permissions (content) to apps that are owned by the malicious attacker. The attacker then tricks an end-user into granting that application consent to access their data

The difference in comparison with a credential attack is that the user uses a valid identity provider and no fake landing page for sign-in or any other method for credential harvesting. In a consent phishing attack, the user sign-in takes place on the identity provider itself. Targeted users who grant the permissions allow attackers to make API on their behalf through the given consent for the malicious app.

Why it is important?

Resetting passwords or requiring Multi-Factor Authentications (MFA), Password-less are not effective against consent phishing. This new method is emerging due to the increase in Passwordless authentication and more strong factors. The attacker uses OAuth 2.0 verification based on the granted app permissions.

Recommended community read: Cloud-Architekt/ Azure AD Attack Defense

Consent overview/ Attack Flow

Below is a simple overview of a phishing attack and all the steps:

  1. Attacker register malicious app with OAuth 2.0 provider with the name “Upgrade”
  2. Attacker sends Email-based phishing including OAuth 2.0 URL
  3. User open e-mail phish
  4. User click on OAuth 2.0 link
  5. Consent message visible
  6. User grants access to malicious app ( including permissions)
  7. Authorization code sent to attackers (App registration Identity Provider)
  8. Access to user data based on API/ OAuth2.0 grant

OAuth apps gain permission by displaying a “Permissions requested” dialog that shows the list of permissions the third-party app is requesting and then asks the user to accept the request. During the acceptance, the security token associated with the user will be sent to the app registration developer/ owner. Which allows them to access the data and services based on the given authorization.

Below consent ask the user for the following permissions:

  • Read and write your files
  • Read your calendar
  • Sign you in and read your profile
Contoso Test App prompt

If a user accepts the request, the attacker (malicious app) has permission to the target Office 365 account. Quite hard to discover right?

In this blog, the detection/prevention options are based on Microsoft products. When users install these apps, they often click accept without closely reviewing the details in the prompt and needed permissions.

Azure AD Admin Consent Workflow

The first step which is recommended is changing the consent experience. The admin consent workflow gives a secure way for managing new consents, where users can request admin approval. Reviewers part of the global administrator, cloud application administrator or application administrator role can review the request and accept the consent of the end-user.

For configuring the global consent settings: Go to Azure AD -> Enterprise Applications -> Consent and permissions

The following options are available for the user and group consent:

User:

  • Do not allow user consent (admin consent always required)
  • Allow user consent for apps from verified publishers, for selected permissions (users can consent low impact apps from verified publishers, classified as low impact or apps registered in the organization)
  • Allow user consent for all applications (user can consent to any app and including all permissions)

Group:

  • Do not allow group owner consent ( group owners cannot allow applications)
  • Allow group owner consent for selected group owners ( selected group owners can allow applications)
  • Allow group owner consent for all group owners (allow all applications)

For strict baselines go for the option “Do not allow user consent (1)”. This will route all end-user consents to an Administrator to review.

The option “Allow user consent for apps from verified publishers (2)” gives users the permission to allow low privileged apps, verified publishers, or organization registered apps. Notice: Malicious apps which are verified can be granted.

When you enable the option “Allow user consent for apps from verified publishers“, you get an extra configuration blade with the name “permission classifications“.

On the permission classifications page, you can define the acceptable permissions for your organization’s data. The first screen shows the most requested permissions with low-risk access (3). For configuring custom permissions click on (4)

 

For enabling Azure AD Admin Consent

  1. Go to Azure AD -> Enterprise Applications -> User Settings
  2. Enable the setting; “Users can request admin consent to apps they are unable to consent to​”

 

Reviewers

Reviewers need to be part of one of the following roles; global administrator, cloud application administrator, or application administrator. In the App Consent wizard – it is possible to select reviewers from a set of users that have one of the roles. (1). Currently in public preview is the option for selecting groups and roles. (2)

For the reviewers the following options are available:

  • Select users will receive email notifications for requests (3)
  • Select users will receive request expiration reminders (4)
  • Consent request expires after …days (5)

Result app consent

A user creates an account on the website Sessionize.com with the option sign-in with Microsoft account. During the creation, the user needs to fill in the consent request.

In the below situation the app consent is submitted with the reason: Need access for the meeting. The required permissions are visible;

  • Sign in and read user profile
  • Maintain access to data you have given it access to

Administrators can review now the consent request. For reviewing. Go to Azure AD -> Enterprise Applications -> Admin consent requests

Users with the reviewer role can now Block, Deny or Review permissions and consent. Requested by shows all the request details and requested users.

More information: Configure the admin consent workflow | Microsoft Docs

Defender for Cloud Apps

Defender for Cloud Apps brings multiple options for the management of Oauth2.0 apps and reviewing existing OAuth 2 apps and given permissions.

Below some of the available detections methods in Defender for Cloud Apps:

  • Activity policies
  • Anomaly detection
  • OAuth app policies
  • App governance add-on feature (later blog)
  • Revoke permissions of an app automatically (later blog)

Defender for Cloud Apps brings some default policies that can be used for OAuth detection.

Rules are:

  • Malicious OAuth app consent
  • Suspicious OAuth app file download activities
  • Unusual addition of credentials to an OAuth app
  • Unusual ISP for an OAuth App
  • Misleading OAuth app name
  • Misleading publisher name for OAuth app

For viewing the build-in rules:

Go to Microsoft Defender for Cloud Apps -> Open Control and click Policies. Search for OAuth app. By default, all policies are enabled.

Interesting is the Malicious OAuth app consent policy. This policy uses Microsoft Threat Intelligence to scan OAuth apps connected to your environment and triggers an alert when it detects a potentially malicious app that has been authorized. Malicious OAuth apps may be used as part of a phishing campaign in an attempt to compromise users.

Breach attempts can be detected with the following rules:

  • Suspicious OAuth app file download activities
  • Unusual addition of credentials to an OAuth app
  • Unusual ISP for an OAuth App

Optionally you can configure the policies with governance actions. Governance actions are different for each policy. The above 3 policies contain governance actions focussing on the user. ( Suspend user, confirm user compromised)

Defender for Cloud Apps – Discovery

Defender for Cloud offers a way to detect automatically possible malicious applications. The Manage OAuth apps view gives an overview of all the applications which are approved already in the environment. When applications are banned from Defender for Cloud, access to the app is automatically revoked from AzureAD.

For managing OAuth apps in MCAS:

Go to: Defender for Cloud Apps portal -> OAuth apps

Filters can be used for selecting the apps, user names, app state, community use, or granted permissions. Apps are detected in the category: Low, Medium, High.

Community use contains the filtering values: Rare, Uncommon, Common. Which contains the community usage level based on the worldwide Microsoft intelligence.

Action can be used for revoking apps directly in AzureAD – and notify the user automatically.

Amazon Alexa Connect is a good example:

11 permissions are part of the application Amazon Alexa Connect. The following permissions are granted:

  • Send mail as any user
  • Read users’ relevant people lists
  • Read user contacts
  • Read and write access to user mail
  • View your basic profile info
  • Access your data anytime
  • Sign you in and read your profile
  • Sign-in and read user profile
  • Read and write user and shared calendars
  • Read user and shared calendars
  • Read and write calendars in all mailboxes

App overview

More consent details are part of the OAuth app info & Usage tab.

  1. Shows all users with granted permissions
  2. Granted permissions part of the application
  3. Used Redirect URLs
  4. Open the activity log of all events part of Amazon Alexa Connect

The page shows more information (last authorized, publisher, and the community usage of the app)

More Microsoft Defender for Apps details will be posted in upcoming blogs for specific features.

Azure Active Directory Identity Protection

Recently Microsoft updated the detection methods in Azure Active Directory Identity Protection, with the use of the new detections the threat detection surface is extended in cloud applications. Interesting is the new oAuth App and Workload Identities Leaked Credentials.

The following new detections are available related to Consent Phishing.

  • Workload Identities Leaked Credentials
  • Unusual Addition of Credentials to an OAuth App

Azure AD Identity Protection has historically protected users in detecting, investigating, and remediating identity-based risks. The capabilities are now extended to workload identities to protect applications and service principals.

Unusual addition of credentials to an OAuth app can indicate that an attacker has compromised the app and is using it for malicious activity. (Phishing, target phishing).

Image source: Microsoft

The following Workload identity risk detections are available based on the Offline detection type.

  • Azure AD threat intelligence: This risk detection indicates some activity that is consistent with known attack patterns based on Microsoft’s internal and external threat intelligence sources.
  • Suspicious Sign-ins: This risk detection indicates sign-in properties or patterns that are unusual for this service principal.
  • Unusual addition of credentials to an OAuth app: This detection is discovered by Microsoft Defender for Cloud Apps. This detection identifies the suspicious addition of privileged credentials to an OAuth app. This can indicate that an attacker has compromised the app, and is using it for malicious activity.
  • Leaked Credentials: This risk detection indicates that the account’s valid credentials have been leaked. This leak can occur when someone checks in the credentials in public code artifact on GitHub, or when the credentials are leaked through a data breach.

Leaked Credentials for Workload identities are useful when workload identities ( App Registration, Service Principals) are leaked directly to public sources. If an object (Application) ID, Secret is found, the alert will be visible in Identity Protection. Public sites are for example (Dark Web, Paste Bin sites, Public Github). Interesting blog focussing on Workload protection: Medium.com / Derk van der Woude.

Defender for Endpoint hunting

Defender for Endpoint can be used for hunting against OAuth URLs which is part of the mail context. For searching against the EmailEvents use the below query.

Shows all inbound email events including the URL https://login.windows.net/common/oauth2/………….. and https://login.microsoftonline.com/consumers/oauth2/………..

EmailUrlInfo
| where Url startswith "https://login.windows.net/common/oauth2" or Url startswith "https://login.microsoftonline.com/consumers/oauth2"
| join EmailEvents on $left.NetworkMessageId == $right.NetworkMessageId
| where EmailDirection == "Inbound"

Conclusion

Visibility and prevention against OAuth (illicit consent attack) are critical for each environment. I hope this article gives you some ideas on how to protect/ detect OAuth consents.

New blogs are scheduled including the following topics:

  • App governance add-on feature
  • Revoke permissions automatically
  • Investigate data in Microsoft Sentinel
  • Azure AD Audit Logs
  • Azure workbooks

Suggestions for new topics? Contact me on the socials or send a mail.

Sources

Microsoft: Detect and Remediate Illicit Consent Grants

Microsoft: Configure the admin consent workflow | Microsoft Docs

MITRE ATT&CK Tactics: Credential Access (T1110) & Steal Application Token (T158)