Breaking: Security Researchers Warn of Rising OAuth Consent Abuse Targeting Microsoft Entra ID Tenants

OAuth (Open Authorization) is a widely adopted authorization framework that enables third-party applications to access user data without ever requiring passwords. In the context of Microsoft Entra ID, OAuth consent flows enable applications to act on behalf of a user — using tokens that represent granted permissions.

While convenient, this delegation model can be misused by threat actors. If a user (or compromised identity) consents to an adversary-controlled application, persistent access to sensitive data like email can be achieved — even if the user’s password is changed later.


The Threat: OAuth Consent Abuse in the Wild

Red Canary’s Threat Research team has been observing OAuth application attacks that leverage legitimate-looking apps to gain unauthorized access via Entra ID. One notable scenario involves a ChatGPT application being authorized with permissions such as Mail.Read.

In their case study:

  • A non-admin user added a third-party service principal representing a ChatGPT app.
  • The user granted the app permissions including Mail.Read, offline_access, profile, and openid.
  • Because of this consent, the application had legitimate access to read the user’s emails.
  • This investigation, while ultimately benign, mirrored characteristics of known malicious incidents.

This relative simplicity belies the real danger: OAuth tokens are independent of user credentials. If an adversary obtains an OAuth access grant, they can retain access regardless of password resets or MFA challenges.


How OAuth Consent Attacks Work

In a real-world malicious OAuth attack, the typical sequence unfolds like this:

  1. Delivery
    A user receives a phishing lure (often an email) offering a useful third-party tool or AI application. Clicking the link leads to a legitimate Microsoft consent screen.
  2. Consent
    The victim authorizes the application — often unaware of the implications — granting permission scopes like Mail.Read.
  3. Dormancy & Reconnaissance
    Some malicious apps lie dormant for weeks or months, quietly harvesting data to learn communication patterns.
  4. Internal Exploitation
    With access to internal email and user data, an adversary may launch internal phishing campaigns, facilitating lateral compromise.
  5. Persistence
    Because the OAuth grant lives independently of user credentials, standard responses like password resets have no effect on the adversary’s access.

Detecting Malicious OAuth Consents

Distinguishing malicious or unsanctioned applications from legitimate ones requires careful analysis and monitoring. Below are practical detection strategies derived from Red Canary’s approach:

1. Correlate Consent Events

  • Detect when a user (especially non-administrators) consents to a new, external, third-party application.
  • Pair this event with an Add Service Principal event using the same correlation ID.
  • This pattern typically indicates an application was newly added and immediately granted permissions.

2. Watch for Risky Permissions

Monitor for OAuth scopes that have known abuse risk — e.g.:

  • Mail.Read, Mail.ReadWrite
  • Files.Read.All, Files.ReadWrite.All
  • Chat.Read, Chat.ReadWrite
  • Calendar and mailbox settings permissions

Apps requesting these scopes without business justification should be scrutinized.

3. Focus on Non-Admin Grants

Applications that were consented to by ordinary users (not administrators) and requesting elevated permissions are high-risk indicators.

4. Evaluate App Origin & Publisher

Legitimate applications tend to have:

  • Known publishers with credible verification
  • Higher prevalence across many tenants
  • Scoped permissions aligned with their functionality

Conversely, suspicious apps may:

  • Be rare across tenants
  • Have uncommon or inconsistent permissions
  • Have spoofed or unverified publisher metadata

Remediation Steps

Once a malicious or unsanctioned OAuth consent is discovered:

1. Remove the OAuth Permission Grant

Using the specific oAuth2PermissionGrantId, you can remove the token grant via Microsoft Graph or PowerShell.

2. Remove the Service Principal

If the app was added by the attacker, removing its service principal effectively eliminates its ability to receive tokens.


Mitigation & Stronger Controls

To reduce the risk of malicious OAuth consent abuse:

Restrict User Consent Policies

  • Disable user consent for external applications entirely (admin consent only).
  • Or allow only verified publishers with specific, low-risk permissions.

Implement an Admin Consent Workflow

Set up a workflow where users request OAuth app access and an admin reviews and approves requests.

Proactive Audit and Hunting

  • Review applications already granted permissions within your tenant.
  • Revoke access for unused or over-permissioned apps.
  • Use tools like Defender for Cloud Apps or custom threat hunting queries to spot risky applications.

Conclusion

OAuth consent abuse in Entra ID represents a sophisticated and slippery threat vector. Attackers can maintain long-lived access through delegated permissions that bypass traditional credential controls. Efficient detection, policy enforcement, and proactive governance practices are essential to reduce exposure and harden defenses.