The Illicit Consent Grant Part 1: Understanding Modern OAuth Consent Phishing

1. Introduction

An illicit consent grant (MITRE ATT&CK T1528, Steal Application Access Token) abuses OAuth 2.0’s delegated authorization model. In that model, an application asks the identity provider — Entra ID, Google, or Okta — for permission to act on a user’s behalf. The user sees a consent screen (“This app wants to read your mail and send messages as you”), clicks Accept, and the IdP issues the application a token scoped to those permissions. So, instead of stealing who you are, it steals what you can do.

The attack is simply this flow operated by an adversary: register an app, request high-value scopes, get the victim to consent, and walk away with a token that grants standing access to their data.

Why it works

The consent model is working exactly as designed. The attacker is not exploiting a software bug, so there is no patch that fixes the problem. Instead, the system asks the user to decide whether an app should be trusted. The login page, consent screen, and token flow all happen through real Microsoft infrastructure, such as login.microsoftonline.com. The attacker’s goal is simply to make the user believe that the app is legitimate and that granting it access is safe.

Why it evades detection

1. No malware, no credential theft. Nothing is dropped on the endpoint, no password to capture, and there is no lateral movement at the point of compromise. There is only a “Consent to application” event that is often logged but rarely reviewed.
2. The traffic is all legitimate. The victim’s browser only ever talks to the real IdP. Token issuance and subsequent API calls originate from the application’s infrastructure, not from suspicious geographies the victim has never logged in from.
3. Token activity can easily look normal. After the attacker receives a valid token, their Microsoft Graph or API requests appear as regular app activity. Since the user already approved the app, there may be no suspicious interactive login for security teams to detect.

Why it bypasses MFA

The attack does not bypass the login process. It abuses what happens after login. In other words, the phish does not intercept authentication, it intercepts authorization.

The victim signs in to the real identity provider and completes password, MFA, or even passkey authentication. The attacker does not steal those factors. Instead, they receive the authorization code or token issued after the user approves the app.

MFA worked, but access was delegated to the wrong application. That is why resetting the password or re-enrolling MFA is not enough. The malicious app consent, refresh tokens, or active sessions must be revoked directly.

The victim authenticates with a phishing-resistant passkey and still hands over consent — proof that strong authentication does not stop an attack that targets authorization.

2. Anatomy of the Attack: How an Illicit Consent Grant Works

The classic consent-phishing chain has three moves.

2.1 The Lure

After registering the app and requesting high-value permissions, the attacker sends the victim a link through email, Teams, or another trusted-looking channel. The link is a crafted call to the IdP’s /authorize endpoint, and because it resolves to the real login domain, it survives URL inspection and looks trustworthy:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
    ?client_id={attacker_app_id}
    &response_type=code
    &redirect_uri={attacker_controlled_url}
    &scope=Mail.ReadWrite%20Mail.Send%20offline_access
    &state={opaque}

Three fields do the work: client_id identifies the attacker’s pre-registered application, scope declares the permissions being requested, and redirect_uri is where the IdP will return the authorization code — a destination the attacker controls.

2.2 The Consent Prompt

The victim reaches the real Microsoft consent screen and signs in normally, including MFA. The attacker has already:

1. Registered a plausible-looking app,
2. Requested sensitive delegated permissions such as mail, chat, calendar, files, and offline_access,
3. Configured the redirect URL to receive the authorization code.

2.3 The Grant

The victim clicks Accept. The IdP redirects the browser to the attacker’s redirect_uri with an authorization code appended. The consent is now recorded as a legitimate user action, and the attacker holds the key material needed to mint tokens.

From code to tokens

The authorization code is not the final target. It is a short-lived, one-time value that must be exchanged for tokens. In Microsoft’s implementation it is valid for roughly 10 minutes and can be redeemed only once. The attacker must move quickly to exchange it.

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

grant_type=authorization_code
&code={stolen_code}
&client_id={attacker_app_id}
&client_secret={attacker_secret}      # confidential clients only
&redirect_uri={attacker_controlled_url}

For a confidential client (a web app that can keep a secret), the code is combined with the client secret to obtain tokens. For a public client (CLI tools, mobile/desktop apps that cannot safely hold a secret), the code alone is sufficient — a distinction that becomes central to the ConsentFix case.

The endpoint returns two tokens that do very different jobs:

The video below shows the full chain in a controlled lab: an attacker bypasses MFA and steals cloud data, from the OAuth consent phish through to Microsoft Graph API exfiltration.

3. Case Study: CoPhish — Abusing Microsoft Copilot Studio

Two things make CoPhish very potent: the lure is delivered from a genuine Microsoft domain, and the exfiltration is automated server-side. Everything below maps onto the same three moves described above — lure, consent prompt, grant.

Building the malicious agent

Copilot Studio allows users to create chatbot agents using low-code workflows called topics. These topics define how the agent responds and what actions it performs. Some are custom-built by the developer, while others are built-in system topics provided by Microsoft.

The key issue is that the agent owner can modify these workflows. In a CoPhish-style attack, the attackers register the OAuth application that victims will actually consent to: a multi-tenant app registration with a client secret and a reply URL of https://token.botframework.com/.auth/web/redirect.

Backdooring the sign-in topic

Every agent has a system sign-in topic that fires when the agent needs the user authenticated. Its default behavior is to present a “Login” button, send the user to the configured identity provider, and store whatever token comes back in the User.AccessToken variable. Because system topics are editable, the attacker inserts a new HTTP Request action immediately after the built-in Authenticate step — one that POSTs User.AccessToken to a URL they control.

This design creates two important effects. First, the “Login” button is only a redirect, so it can send the user to an attacker-controlled OAuth consent flow. Second, the backend request is made by Copilot Studio, not directly by the victim’s browser. As a result, the traffic appears to come from Microsoft infrastructure, and the victim’s network may never show a direct connection to the attacker. This makes detection much harder.

The chain in motion

The lure. The victim receives the copilotstudio.microsoft.com link. It resolves to a real Microsoft domain, and survives URL reputation checks — exactly the trust described in chapter 2, now with Microsoft’s own branding doing the work.

The consent prompt. Opening the agent, the victim clicks Login and is redirected to the genuine Entra consent screen for the malicious application. They authenticate as normal, passing MFA or a passkey, and are shown the requested scopes. Clicking Accept records a legitimate, user-initiated consent.

The grant. Consent triggers the Bot Connection Validation service (token.botframework.com), which hands the user a short numeric code. The user pastes that code back into the agent to finish signing in; the agent retrieves the issued token and stores it in User.AccessToken. The backdoored HTTP Request then fires, forwarding the token to the attacker. The victim sees a working chatbot and no error — nothing signals that their session was just handed off.

4. Detection and Mitigation with SlashID

Illicit consent happens after authentication, so MFA alone is not enough. Defense has to cover three stages: before consent, during consent, and after the grant is issued. SlashID helps across these stages through its Identity Graph, cloud and SaaS integrations, behavioral detections, automated remediation, and the browser extension.

Before the attack, SlashID helps reduce the attack surface by inventorying OAuth apps, service principals, non-human identities, and shadow SaaS or GenAI applications. It can identify dormant, risky, or over-permissioned grants, as well as tenant settings that make abuse easier, such as allowing regular users to register applications. Tighten via IGA access reviews and least-privilege attestation.

During the attack, SlashID’s browser extension adds visibility at the point where the user is asked to approve dangerous OAuth grants. This is where the OAuth flow is visible, including the app, requested scopes, and possible token exfiltration behavior.

After the attack, SlashID can detect suspicious grants and abnormal token usage across the identity layer. Automated remediation can then revoke the grant, disable the risky service principal, rotate exposed credentials, and terminate active sessions. This reduces dwell time and limits the blast radius before the attacker can fully abuse the delegated access.

For a deeper look at how attackers turn a single consent into durable persistence inside Entra ID, see Illicit Consent-Granting & App Backdooring. In Part 2 of this series, we dig into the ConsentFix case and the public-client distinction that makes it so dangerous.