ConsentFix v3: The OAuth Consent Phishing Toolkit That Bypasses MFA for Financial Institutions

A new criminal toolkit posted to an underground hacker forum in April 2026 has industrialized a Microsoft 365 phishing technique that bypasses multi-factor authentication entirely. The victim never enters a password. The victim never solves an MFA challenge. The attacker walks away with a refresh token that grants up to 90 days of cloud access to the victim's account, with every action looking like normal user activity in the audit log.

The toolkit is called ConsentFix v3. It was documented by Push Security threat researchers on April 23, 2026, and corroborated by BleepingComputer, Cloud Security Alliance Labs, and a research note network across the security industry through May. Earlier ConsentFix variants have been observed in the wild since December 2025. The v3 release does not add a new technique; it adds operational tempo, automating an attack class that until now required hands-on operator effort for every victim.

For banks, credit unions, and mortgage companies, this is not a routine patch-and-move-on story. The technique abuses architectural Microsoft features that examiners expect financial institutions to use. The defenses that work require advance configuration of Conditional Access policies, service principals, and audit log retention. The defenses that look like they should work, including most standard MFA enforcement, simply do not apply to this attack.

The Attack That Skips MFA

Multi-factor authentication is the foundational control financial institutions deploy to protect Microsoft 365 accounts. The Federal Financial Institutions Examination Council's 2021 Authentication and Access guidance reinforced MFA as a baseline expectation for digital banking access. Every modern board-level cybersecurity discussion at a community bank or credit union starts with confirming that MFA is on, that it is on for everyone, and that it is on for every application.

ConsentFix v3 is engineered specifically to make MFA invisible. Not bypassed in the sense of brute-forcing it. Invisible in the sense that the attack never triggers an MFA challenge in the first place.

The mechanism is session reuse. When an employee is already signed in to Microsoft 365 in their browser, which is nearly universal on a managed corporate device during business hours, Microsoft Entra ID honors the existing session for OAuth authorization requests from first-party applications. The attacker initiates an OAuth flow on the victim's behalf, the browser's existing session satisfies the authentication step silently, and an authorization code lands in the attacker's backend with no visible security event for the user, the security team, or the Conditional Access engine.

Push Security's documentation puts it directly: when the victim already has an authenticated Microsoft session, the OAuth authorization code flow can complete without a fresh password prompt and without a new MFA challenge. The Cloud Security Alliance Labs research note from May 21, 2026, corroborated the mechanism: session reuse is the single feature that elevates ConsentFix from a research curiosity into an operational MFA-bypass attack.

How ConsentFix v3 Actually Works

The attack chain in v3 has been streamlined to the point where a single criminal operator can run it at scale without scripting expertise. The toolkit packages OAuth abuse, target enumeration, lure delivery, and token exchange into one operational workflow.

The eight technical steps that occur during a v3 attack are documented across Push Security's original research, BleepingComputer's coverage, and the gblock.app technical walkthrough. Each step uses a legitimate Microsoft OAuth feature working as designed.

First, the lure page presents a Cloudflare Turnstile prompt requiring a corporate email. Second, the page invokes Microsoft's real sign-in URL with Azure CLI as the requesting client identifier. Because Azure CLI is a public client that cannot store a secret, no client-side secret is required. Third, Microsoft authenticates the victim normally through the victim's existing browser session if one is active. Fourth, Microsoft redirects to Azure CLI's localhost callback URL with a one-time authorization code appended. Fifth, the lure page captures the URL automatically without user interaction in v3. Sixth, the page posts the URL to a Pipedream webhook. Seventh, Pipedream calls Microsoft's token endpoint and exchanges the code for an access token and a refresh token. Eighth, the tokens are imported into the attacker's command interface.

The refresh token is where ConsentFix becomes durable. Microsoft refresh tokens issued to first-party applications are valid up to 90 days. Every 60 minutes, the attacker uses the refresh token to generate a new access token without requiring the victim to authenticate. The victim continues working normally. The attacker continues operating in parallel. The audit log shows tokens being refreshed from an unfamiliar IP address, which is a detection signal only if the security team is monitoring for it.

The attack becomes worse with Microsoft's Family of Client IDs feature. FOCI is an intentional Microsoft design pattern documented through an MSRC submission in 2021. It allows refresh tokens issued to one first-party application to be exchanged for access tokens to any other application in the family. A refresh token captured for Azure CLI can be redeemed for tokens to Microsoft Graph, Microsoft Teams, Visual Studio, or SharePoint Online Management Shell. The attacker chose Azure CLI because it has Conditional Access exclusions. The attacker uses Microsoft Graph because that is where customer data lives.

Why Financial Institutions Are the Target

The combination of three factors makes ConsentFix particularly dangerous for banks, credit unions, and mortgage companies relative to other industries.

The first factor is the regulatory expectation. FFIEC examiners read the 2021 Authentication and Access guidance to mean that MFA is enforced everywhere, that user behavior is monitored for unauthorized access, and that the institution has a defensible incident response process for compromised credentials. A successful ConsentFix attack produces no compromised credential. The password was never entered. The MFA factor was never presented. The audit trail shows a legitimate OAuth grant from a first-party application that the tenant cannot block. Explaining this to an examiner after the fact requires explaining why MFA was on but the attacker held tokens for 90 days anyway.

The second factor is the data surface. Microsoft Graph exposes mailbox content, OneDrive files, Teams messages, SharePoint documents, and meeting metadata to applications holding valid access tokens. The same surface that lets Microsoft 365 Copilot summarize a borrower's communication history also lets a captured refresh token enumerate it. For a community bank, that means loan files, member identification documents, internal compliance notes, executive correspondence, and vendor risk reviews are all reachable through a single captured refresh token. For a credit union, member account documents and BSA filings are in the same scope. For a mortgage company, borrower documentation including Social Security numbers and pay stubs lives in the Graph surface.

The third factor is the workforce model. Community banks and credit unions increasingly run hybrid workforces with a mix of corporate-managed devices, personal devices used for limited tasks, and contractor access. Each unmanaged endpoint is a candidate for ConsentFix because the browser session does not need to be on a compliant device for the OAuth flow to succeed. A loan officer on a personal laptop checking email between meetings is the operational reality at most community institutions, and that user fits the ConsentFix victim profile exactly.

The ConsentFix v3 attack chain. Every step uses a legitimate Microsoft OAuth feature working as designed.

What Stops This (and What Does Not)

Most board-level Microsoft 365 security discussions focus on user-level controls: enforce MFA, train users on phishing, deploy email filtering, label external messages. Each of these is necessary. None of them stop ConsentFix v3.

The reason is that ConsentFix targets the boundary between Microsoft Entra ID and the Microsoft first-party application catalog, not the user identity layer. The user is the delivery vector. The exploit is in the OAuth authorization grant for an application the tenant cannot block.

Microsoft has a parallel response in flight. The Conditional Access enforcement change announced February 2026 and rolling out in phases starting March 2026 with full enforcement on June 15, 2026, removes the low-privilege scope exclusions that ConsentFix has exploited. Organizations with policies targeting "All resources" with resource exclusions need to audit those exclusions before June 15. ABT customers under Microsoft 365 Guardian receive a managed audit and policy update against this enforcement deadline as a standard part of the service.

The Five-Step Defender Playbook

The controls that work against ConsentFix v3 require advance configuration. None of them are emergency response controls applied after an attack. The playbook below is the sequence every financial institution with a Microsoft 365 tenant should run through, in order, in the next two weeks.

Connect to Microsoft Graph PowerShell and create service principal records for each of the eleven first-party applications documented by Push Security. The application identifiers are publicly available. Once each service principal exists in the tenant, enable the User Assignment Required flag using the Update-MgServicePrincipal cmdlet against each principal. Assign a dedicated security group containing only the IT staff and authorized developers who legitimately need Azure CLI, Visual Studio, and the other affected applications.

Run the Microsoft Graph PowerShell query for Conditional Access policies that target All resources with one or more resource exclusions. Each excluded resource is a configuration debt that the June 15 enforcement change will remove. Review each excluded application against business justification. Where the exclusion is no longer needed, remove it. Where it is still required, document the residual risk in your authentication risk register for the examiner.

Create a Conditional Access policy in report-only mode that requires Token Protection for Microsoft 365 desktop and mobile applications on Windows devices. Token Protection binds the access token to the device, preventing a captured refresh token from being used on an attacker's machine. Roll out the policy in report-only mode for one to two weeks, review the sign-in logs for unexpected blocks, then promote to On.

The Push Security debrief specifically calls out that the deprecated AADGraphActivityLogs source contains the most actionable detection signal for ConsentFix attacks because the attack exploits legacy scope routes. Enable the source in Microsoft Defender. Configure 12-month retention for the activity logs. This is a one-time configuration that pays dividends every time an examiner asks how you would detect this attack class.

The Elastic Security detection library maintains an open-source rule for OAuth phishing via first-party Microsoft applications. The rule signature looks for OAuth2:Authorize requests with Redirect status against the deprecated Windows Azure Active Directory resource identifier 00000002-0000-0000-c000-000000000000, plus FOCI applications accessing Microsoft Graph from unfamiliar source IPs. Microsoft Sentinel and Microsoft Defender XDR support equivalent detection logic through Kusto Query Language. ABT customers on Microsoft 365 Guardian MxDR receive these detections as managed analytics.

The five-layer defense stack that actually stops ConsentFix v3 in a Microsoft 365 environment.

How ABT Detects and Responds

Access Business Technologies is a Tier-1 Microsoft Cloud Solution Provider for more than 750 banks, credit unions, and mortgage companies. ABT manages Microsoft 365 tenants for financial institutions through M365 Guardian, the managed-service operating model that bundles tenant administration, security telemetry, regulatory artifact production, and incident response into one engagement.

Guardian MxDR is the detection and response layer of M365 Guardian. For the ConsentFix attack class, MxDR delivers four operational outcomes that customers receive without configuring anything themselves. First, the service maintains the service principal inventory and user-assignment-required configuration on the 11 vulnerable first-party applications across every managed tenant. Second, Guardian MxDR audits Conditional Access policies against the June 15, 2026, enforcement deadline and applies the policy updates required to maintain coverage. Third, MxDR enables AADGraphActivityLogs in Microsoft Defender and provisions the audit-log retention that examiners want to see. Fourth, MxDR runs the Elastic-equivalent KQL detection rules against the customer tenant continuously, with alerts routed to ABT's 24x7 security operations team rather than to the customer's internal IT staff.

For banks and credit unions running Microsoft 365 without a dedicated security team, the difference between an alert that reaches an empty mailbox at 11 PM and an alert that reaches a Guardian analyst at 11 PM is the difference between a 90-day refresh-token compromise and a 90-minute response.

If you want to understand how your current Microsoft 365 tenant would respond to a ConsentFix attempt, the fastest path is a Guardian readiness conversation. The session pulls your tenant's Conditional Access policy export, service principal inventory, and audit-log retention configuration, then maps each against the controls that stop OAuth consent phishing. The output is a written assessment of where you are exposed and what changes would close the gap. The conversation takes twenty minutes. We do not need access to your tenant to start it.

For a broader view of how Microsoft 365 Guardian, Guardian MxDR, and the related ABT services align with FFIEC, NCUA, and FDIC examiner expectations, see our companion articles on Storm-2949 identity compromise, the Code-of-Conduct AiTM phishing campaign, and our phishing-resistant MFA buyer's guide.

Frequently Asked Questions