ConsentFix: How Attackers Abuse Pre-Consented Microsoft Apps to Harvest OAuth Tokens Without Consent Dialogs
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Standard OAuth phishing (the illicit consent grant attack) relies on a victim clicking 'Allow' on a consent dialog that grants permissions to a third-party malicious application. Microsoft introduced admin consent requirements and user consent restrictions specifically to defend against this. ConsentFix sidesteps these defenses entirely by using Microsoft's own pre-consented first-party apps, which require no new consent from anyone. The attacker crafts a login URL for Azure CLI or Azure PowerShell (both pre-consented in most enterprise tenants), sends it to the victim as a phishing link, and collects the authorization code from the redirect URL. The victim authenticates normally on Microsoft's login page and sees nothing unusual.
How the Attack Works
The attacker constructs an OAuth authorization URL for a pre-consented Microsoft app. Example URL structure: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46 (Azure CLI client ID) &response_type=code &redirect_uri=http://localhost (or another attacker-controlled URI) &scope=https://management.azure.com/.default &state=[tracking-value]. The victim clicks the phishing link (disguised as a legitimate corporate login or an Azure portal link). They are directed to Microsoft's genuine login page. They authenticate (entering their credentials, completing MFA). After authentication, Microsoft issues an authorization code and redirects to the redirect_uri -- if the attacker has set up a redirect capture mechanism, they receive the code. The attacker exchanges the code for tokens at the token endpoint. Because Azure CLI is pre-consented with Azure Management API permissions, the tokens grant access to the victim's Azure subscriptions. The attack works even with MFA because the victim completes MFA normally -- the MFA protects the login, not the token issuance. The resulting token is valid until it expires or is revoked.
Which Apps Enable ConsentFix
The most dangerous pre-consented apps for ConsentFix purposes are those with broad Microsoft Graph, Azure Management, or Exchange permissions that are pre-consented in default tenant configurations. Azure CLI (client ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46): access to Azure Management API, Microsoft Graph user read. Azure PowerShell (client ID 1950a258-227b-4e31-a9cf-717495945fc2): Azure Management API access. Microsoft Teams PowerShell (client ID 12128f48-ec9e-42f0-b203-ea49fb6af367): Teams and Groups management permissions. Visual Studio Code (client ID aebc6443-996d-45c2-90f0-388ff96faa56): Microsoft Graph access. The common factor: these apps were consented during tenant setup or are auto-consented as part of Microsoft's first-party app catalog. Standard users in the tenant have no visibility into which apps are pre-consented or what permissions they hold. Enumerate pre-consented apps in your tenant: Get-MgServicePrincipal -All | Where-Object { $_.Tags -contains 'WindowsAzureActiveDirectoryIntegratedApp' } | Select-Object DisplayName, AppId.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect ConsentFix Attempts in Logs
ConsentFix-based access is detectable in Entra ID sign-in logs because the application (Azure CLI, Azure PowerShell) appearing in the sign-in event is highly unusual for standard users. Build an alert: Azure CLI, Azure PowerShell, Teams PowerShell, or Visual Studio Code sign-in events from user accounts that are not members of the IT or cloud infrastructure admin team. In Sentinel: AADSignInEventsBeta | where ApplicationId in ('04b07795-8ddb-461a-bbee-02f9e1bf7b46', '1950a258-227b-4e31-a9cf-717495945fc2', '12128f48-ec9e-42f0-b203-ea49fb6af367') | where UserType != 'Member' or AccountType == 'standard' | project TimeGenerated, UserPrincipalName, IPAddress, ApplicationId, ApplicationDisplayName, ConditionalAccessStatus. Alert on: standard user accounts signing in to Azure CLI (these users should not be running CLI commands), successful authentication from residential or VPN IP addresses for these apps, and sign-ins for these apps immediately following a phishing simulation or phishing alert for the same user.
Restrict Pre-Consented Apps via Conditional Access
The most direct defense is blocking non-admin users from authenticating to developer and administrative tooling apps via Conditional Access. Create a Conditional Access policy: Target applications: Azure CLI (04b07795), Azure PowerShell (1950a258), Teams PowerShell (12128f48), and other pre-consented admin tool apps. Conditions: Exclude your IT admin and cloud infrastructure groups. Grant: Block access (for all other users). This prevents standard users from completing authentication to these apps at all -- even via a ConsentFix phishing URL, the login will be blocked by CA before the authorization code is issued. Test before deploying by running in Report-Only mode for one week to identify any legitimate users who need access to these apps. Alternatively: use Conditional Access to require Privileged Access Workstation (compliant device + admin sign-in) for these apps, which makes ConsentFix less dangerous (an attacker would still get a token, but it would be restricted by device compliance).
Reduce Pre-Consented App Permissions via Admin Consent Review
Review and restrict the permissions granted to pre-consented apps where possible. For third-party enterprise applications (not first-party Microsoft apps): use the Entra ID Enterprise Applications > Admin consent > Permissions blade to review and revoke unnecessary permissions. For first-party Microsoft apps: permissions are managed by Microsoft and cannot be reduced via the tenant admin -- the defense is Conditional Access restrictions rather than permission reduction. Implement a regular consent review process: Entra ID Governance > Access Reviews includes an app permission review capability (in preview as of mid-2026) that surfaces apps with high-privilege consent grants. Combined with alerts on new user consent grants and admin consent requests, this provides visibility into the pre-consented application surface. Enable the user consent setting restriction: Entra ID > Enterprise Applications > User settings > Users can consent to apps accessing company data on their behalf = No (or set to allow only apps from verified publishers). This prevents new OAuth phishing via third-party app consent but does not affect the pre-consented first-party app ConsentFix vector.
The bottom line
ConsentFix bypasses the primary defense against OAuth phishing (the consent dialog) by using apps that are already consented. The defense is Conditional Access restriction: block standard users from authenticating to Azure CLI, Azure PowerShell, and Teams PowerShell entirely unless they are members of the IT admin team. Alert on any sign-in event for these apps from non-admin accounts -- it is either a ConsentFix attempt or an employee running unauthorized cloud tooling, both worth investigating.
Frequently asked questions
How is ConsentFix different from the standard illicit consent grant attack?
The illicit consent grant attack registers a new malicious third-party app and tricks a user into clicking Allow on a consent dialog. Microsoft's admin consent requirement (block user consent for new apps) prevents this by requiring admin approval for new apps. ConsentFix uses apps that are already admin-consented (first-party Microsoft apps), so no new consent dialog ever appears and the admin consent requirement provides no protection. ConsentFix is more dangerous specifically because the most effective defense against illicit consent grant -- blocking user consent for third-party apps -- does nothing to prevent it.
Does requiring phishing-resistant MFA (FIDO2 / WHfB) prevent ConsentFix?
Phishing-resistant MFA significantly reduces the attack surface but does not eliminate ConsentFix. If the victim authenticates with FIDO2 or WHfB on a legitimate Microsoft login page, the MFA itself is phishing-resistant (credentials and MFA are bound to the specific origin URL). However, the ConsentFix technique directs the victim to Microsoft's real login.microsoftonline.com, which is the legitimate origin for FIDO2 and WHfB. After authentication, the authorization code is issued and redirected to the attacker's endpoint. Phishing-resistant MFA prevents password theft but does not prevent the authorization code from being issued by Microsoft's legitimate authorization server to the crafted redirect URL. Conditional Access restrictions on the target apps remain the primary defense.
Can Microsoft revoke the pre-consent for its own first-party apps?
Tenant administrators cannot control which first-party Microsoft apps are pre-consented -- these are provisioned by Microsoft as part of the tenant infrastructure. However, administrators can control whether non-admin users can use those apps by blocking them via Conditional Access. The permission grants exist for legitimate operational reasons (Azure CLI needs Azure Management API access to function). The tenant-side control is access restriction, not permission revocation.
What data can an attacker access with a ConsentFix token from Azure CLI?
A token issued via Azure CLI contains the Azure Management API scope (https://management.azure.com/.default), which allows: listing all Azure subscriptions the victim has access to, listing all resources across those subscriptions, reading and modifying Azure resources (depending on the victim's RBAC role), reading secrets from Key Vaults (if the victim's identity has Key Vault permissions), and accessing the Azure ARM API for all resources. The damage scope is bounded by the victim user's Azure RBAC assignments -- if the victim is a developer with Contributor on a single subscription, the attacker's token has the same scope. If the victim is a subscription Owner, the attacker can create new resources, assign new roles, or exfiltrate all Key Vault secrets.
How do I restrict which redirect URIs are allowed for first-party Microsoft apps to limit ConsentFix exposure?
Tenant administrators cannot modify the allowed redirect URIs for first-party Microsoft applications -- those are set by Microsoft. However, you can use Conditional Access to restrict which users can authenticate to specific first-party apps (Azure CLI, Azure PowerShell) by creating a policy that blocks those apps for non-admin users. This does not close the redirect URI technically, but it prevents a stolen authorization code from being usable by a non-admin attacker who obtained it. Additionally, monitoring for authorization code redemptions from unusual IPs (via the Entra sign-in logs) provides detection coverage -- a ConsentFix attack shows an interactive sign-in to login.microsoftonline.com followed immediately by a token endpoint call from a different IP address.
What other OAuth consent attacks exist beyond ConsentFix and how do they differ in the attacker's required access level?
OAuth consent attacks span a range of required attacker access levels. Illicit consent grant (requires no prior tenant access): an attacker registers a malicious multi-tenant app in their own tenant, sends a crafted consent URL to a victim, and tricks them into granting the app delegated permissions. If the victim clicks 'Accept,' the attacker's app receives a token with the victim's permissions. Mitigated by disabling user consent for apps from unverified publishers. App impersonation via stolen App Registration credentials (requires App Registration owner access): the attacker obtains credentials for a legitimate trusted app and uses them to acquire tokens that appear to come from the trusted app. Mitigated by rotating app secrets, using certificate credentials instead of client secrets, and monitoring service principal sign-in anomalies. Cloud administrator OAuth token abuse (requires Cloud Application Administrator or Application Administrator role): the attacker grants application permissions to a service principal directly without a user consent prompt. Mitigated by PIM for Application Administrator roles. ConsentFix and FOCI attacks are unusual because they require only a stolen user OAuth token as input, not initial tenant access or a separate malicious app registration -- making them post-exploitation paths rather than initial access.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.