ConsentFix v3 Bypasses Azure MFA via Automated OAuth Abuse

ConsentFix v3 is an automated attack toolkit circulating on criminal forums that hijacks Microsoft Entra ID accounts through OAuth authorization code theft, bypassing multi-factor authentication, device compliance enforcement, and conditional access policies entirely. The toolkit exploits the implicit trust Microsoft extends to its own first-party applications — including Azure CLI, Azure PowerShell, Visual Studio, and Visual Studio Code — which are pre-consented in every tenant and cannot be deleted or blocked by tenant administrators. There is no patch; the vulnerability is architectural. Every Microsoft 365 and Azure organization is exposed until administrators apply explicit Service Principal restrictions and token-binding policies.

ConsentFix v3 Azure OAuth Abuse: Technical Details

The attack exploits the OAuth 2.0 authorization code grant flow as implemented in Microsoft native desktop applications. Unlike browser-based OAuth flows — which redirect to a registered HTTPS domain — native apps like Azure CLI use a localhost redirect URI. When a user completes authentication, the authorization code appears in the browser address bar as a localhost:// URL containing the bearer code.

ConsentFix v3 weaponizes this by social-engineering victims into copying that localhost URL and pasting it into an attacker-controlled page — a spoofed Microsoft or Azure interface hosted on Cloudflare Pages. The victim sees a standard account-selection dropdown; they are already authenticated on Microsoft’s infrastructure, so no password is re-entered and no MFA prompt fires. The victim pastes the URL as instructed; the phishing page silently extracts the authorization code from the URL string.

The extracted code is forwarded to a Pipedream webhook, a free serverless integration platform that handles the automated token exchange. Pipedream calls Microsoft’s token endpoint and exchanges the authorization code for a full access/refresh token pair — the entire exchange completing within seconds, well inside the 10-minute validity window.

The critical amplifier: because Azure CLI is a first-party Microsoft application, it carries pre-consented permissions that tenant administrators cannot revoke. Per Push Security’s analysis of the v3 toolkit, “first-party apps like Azure CLI are trusted by default in all tenants, allowed to request permissions without admin approval, and cannot be deleted or blocked.”

Exploitation and Threat Landscape

ConsentFix v3 is the most operationalized iteration yet. The toolkit integrates the full attack chain with minimal manual intervention:

• Reconnaissance — tenant ID validation, employee intelligence gathering via ZoomInfo
• Infrastructure setup — account creation across Outlook, Tutanota, Cloudflare, DocSend, Hunter.io, and Pipedream
• Phishing deployment — Cloudflare Pages hosts the spoofed Microsoft interface; the toolkit manages email campaign delivery
• Code capture — Pipedream webhook receives the localhost URL forwarded by the victim’s browser
• Automated token exchange — Pipedream exchanges the authorization code for refresh tokens via Microsoft’s OAuth endpoint
• Post-exploitation — stolen tokens are imported into SpecterPortal for persistent access to email, files, SharePoint, and Azure management resources

The most dangerous post-exploitation capability is Family of Client IDs (FOCI) abuse. FOCI is a Microsoft mechanism that allows related first-party applications to share refresh tokens. A refresh token obtained for Azure CLI can be silently exchanged for access tokens covering Outlook, Teams, OneDrive, and SharePoint — with no additional user interaction. Advanced attackers can escalate further by targeting the Microsoft Authentication Broker application to capture a Primary Refresh Token (PRT), achieving seamless SSO across all Entra ID-connected applications and services.

MITRE ATT&CK techniques in play:

• T1566 — Phishing (initial delivery via spoofed Microsoft UI)
• T1528 — Steal Application Access Token (OAuth authorization code capture)
• T1550.001 — Use Alternate Authentication Material: Application Access Tokens (FOCI refresh token reuse)

No specific threat actor has been attributed to active ConsentFix v3 campaigns as of publication. The toolkit’s availability on criminal forums indicates broad potential uptake across multiple threat actor groups.

Who Is Affected

Every organization using Microsoft Entra ID (formerly Azure Active Directory) is affected if any of the following first-party applications are accessible to users:

• Azure CLI — the primary target observed in attacks
• Azure PowerShell
• Visual Studio and Visual Studio Code
• Teams PowerShell Cmdlets

This captures virtually every enterprise Microsoft 365 and Azure tenant globally. Cloud-only tenants and hybrid configurations are equally exposed. No specific industry verticals have been named in public reporting, but organizations with users who hold Azure Resource Manager or Exchange permissions represent the highest-value targets — a compromised refresh token for those scopes provides lateral movement into cloud infrastructure, not just email.

What You Should Do Right Now

• Create Service Principals for vulnerable first-party apps and restrict assigned users. In Entra ID, navigate to Enterprise Applications, find “Azure CLI” (App ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46), and assign only the users and groups who legitimately need it. Users not assigned cannot complete the OAuth flow through a ConsentFix phishing page.

• Require compliant devices via Conditional Access. Create a Conditional Access policy targeting the affected first-party app IDs and set the grant control to Require device to be marked as compliant. This binds issued tokens to a device context that attackers do not control.

• Audit FOCI application relationships. Review Push Security’s first-party Microsoft app reference to identify which apps in your tenant share refresh token scopes, then apply Conditional Access restrictions per app rather than globally.

• Block Pipedream at the network perimeter if unused: add .pipedream.net and .pipedream.com to your DNS/proxy blocklist. This disrupts the automated token-exchange step that makes v3 operationally scalable.

• Enable Entra ID token protection (preview) where available. This cryptographically binds access tokens to the device TLS session, preventing replay from a different machine.

• Conduct targeted user awareness training specifically on the ConsentFix pattern. Legitimate Microsoft workflows never instruct users to copy-paste a localhost:// URL into any website — this single behavioral signal is enough to detect the attack socially.

Detection and Verification

Microsoft Entra sign-in logs are the primary data source. In the Microsoft Entra admin center or via Azure Monitor Log Analytics, run:

SignInLogs
| where AppDisplayName in ("Azure CLI", "Azure PowerShell", "Visual Studio", "Visual Studio Code")
| where AuthenticationProtocol == "oAuth2"
| summarize count() by UserPrincipalName, IPAddress, AppDisplayName, bin(TimeGenerated, 1h)
| order by count_ desc

Any sign-in from an unusual IP or geography for Azure CLI specifically warrants investigation. The strongest behavioral signal is a geographic mismatch between the sign-in IP (where the OAuth code was captured on the phishing page) and subsequent API activity (where the attacker uses the token). These two IPs will differ in virtually every ConsentFix attack.

Monitor consent grants and delegated permission events in AuditLogs:

AuditLogs
| where OperationName in ("Consent to application", "Add delegated permission grant")
| extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName)
| where ActorUPN !endswith "@yourdomain.com" or isempty(ActorUPN)

If you run Microsoft Sentinel, check the content hub for OAuth App Abuse and Suspicious Azure CLI usage analytic rules and confirm they are enabled. Push Security also provides browser-native detection that flags ConsentFix phishing page patterns in real time before the user submits a URL.

Conclusion

ConsentFix v3 renders standard MFA bypass advice inadequate — users never enter credentials, they complete what appears to be a routine Microsoft account sign-in. Treating Service Principal user assignments and token-binding Conditional Access policies as optional hardening is no longer defensible; they are now the frontline controls against this class of attack.