ConsentFix v3: Analyzing a new criminal toolkit

In December 2025, we uncovered a state-sponsored campaign linked to Russian state-affiliated APT29 that used a new technique we called ConsentFix. This technique merged ClickFix-style social engineering with OAuth consent phishing to hijack Microsoft accounts. Effectively, ConsentFix is a browser-native attack that results in account takeover, without the downside of needing to touch the endpoint like typical ClickFix (really, the point that it's most likely to be detected and blocked).

The quick 101 is that victims are tricked into copy-and-pasting a legitimate Microsoft URL into the phishing page. This URL contains an OAuth authorization code that the attacker uses to sign in to a first-party Microsoft application like Azure CLI — specifically targeting apps with known Conditional Access exclusions.

At the end of the attack chain, the attacker is effectively granted API access to the victim's Entra account, while sidestepping MFA (even passkeys), device compliance checks, and in some cases conditional access controls (depending on the application ID targeted by the attacker).

It didn’t take long for security researchers to jump on this new technique. Lots of contributors rallied round the security recommendations (which we covered in a follow-up blog post) but the most notable contribution came from John Hammond, who took the attacker’s implementation and said “I can do better”. His v2 replaced a somewhat clunky implementation with a slick drag-and-drop function. But now, attackers have taken it one step further.

Introducing: ConsentFix v3

The latest development is that a member of the XSS criminal forum, a site strongly suspected to have Russian state involvement, has released a new tool “ConsentFix v3”, building on the v1 we saw in the wild, and John’s v2. 

It looks like broader cybercriminals are starting to take note of ConsentFix, and with the release of public tools like this one, it could be about to go mainstream — like device code phishing has this year. 

Let’s take a closer look at some of the more interesting details of the ConsentFix v3 implementation before considering the bigger picture.  

ConsentFix v3 under the hood

The first thing that jumps out is just how detailed this forum post is. It reads like a security vendor blog post. It walks through the key technical concepts that the reader needs to know, breaking down OAuth grants, consent phishing, refresh tokens, and FOCI (or 'Family of Client IDs' — basically, the feature that allows attackers to use a refresh token obtained for one Microsoft app to be exchanged for access tokens to other FOCI apps without re-authentication). It then walks through the history of ClickFix and ConsentFix before providing step-by-step guidance for users. 

ConsentFix v3 allows users to instrument the entire attack chain, enabling users to spin up ConsentFix infrastructure, create believable personas with which to interact with victims, craft and manage email campaigns, and automate the process of exchanging the captured OAuth token for session and refresh tokens to establish access to the compromised account. 

A combination of SaaS and open-source tools are used to perform the attack, including Cloudflare Workers for hosting, ZoomInfo for target identification, Dropbox for PDF hosting, and Pipedream as an exfiltration channel (effectively creating a webhook to automatically exchange the OAuth material in the URL for a refresh token). They also use hacker tools like SpecterPortal for post exploitation activity.

Why attackers are turning to OAuth-based attacks

Attackers are increasingly turning to OAuth based techniques in 2026. Not only are “legit” OAuth connections being abused in supply chain attacks, but attacks targeting OAuth mechanisms have significantly increased with the rise of device code phishing. This is because:

• OAuth attacks defeat standard access controls (including passkeys)

• It’s very low friction, and less likely that users will identify it as phishing (see examples below)

From the user’s perspective, these aren’t situations that users are trained to treat as suspicious. In one case, the victim copies a URL (or simply drag-and-drops a box on the page). In another, they enter a short passcode that’s visible on the page. 

Both are using pop-up windows that look very convincing — and point to legitimate Microsoft pages/URLs. Even users scrutinizing the domain won’t see anything out of place. And as you can see, if the user is already signed into their Microsoft account in the browser, there’s no credential entry or MFA checks to pass through. Simply select your account from the drop down menu and … that’s it.

This unfamiliarity is the same reason that attacks like ClickFix have been so successful. In general, convincing social engineering — well crafted comms, legit-looking pages hosted on trusted sites — combined with unfamiliar payloads makes for a clever attack. And when these attacks play out entirely in the browser (circumventing endpoint controls) and sidestep identity controls, the impact is dialled up even further.

How ConsentFix and device code phishing overlap

It was only ever going to be a matter of time before ConsentFix was adopted by the mass market. But these things don’t always happen particularly fast. Device code phishing is probably the best example of this — it’s been a known technique since 2021, but it took until this year to enter mainstream adoption. A big part of that has been the availability of criminal toolkits, and also the rise in AI-assisted capabilities for tool creation (clearly at play here too). The similarity with device code phishing doesn’t end there. 

Both ConsentFix and device code phishing are OAuth attacks. They both find ways of bypassing the standard login procedure (and controls) by targeting different authorization flows, but with a similar outcome and the same advantages to an attacker. Device code phishing exploits the device authorization grant (RFC 8628). ConsentFix exploits the authorization code grant (RFC 6749) as implemented for native/desktop apps with localhost redirects. 

The post-compromise paths are essentially identical because the tokens you get are determined by which app you target, what scopes it has, and the victim user’s permissions, not by which OAuth flow you used to obtain them. The authorization code flow and the device code flow are just different front doors into the same token issuance system.

The verdict: An interesting sign of what’s coming, but maybe not the final form

It’s clear that ConsentFix v3 isn’t exactly an industrialized PhaaS-scale offering. It’s probably closer to a red team-esque proof of concept. But it is a good example of how attackers could operationalize ConsentFix campaigns using largely off-the-shelf tooling and legit SaaS tools. And an indicator of what might be coming soon. 

Security recommendations

To be able to tackle modern attacks like ConsentFix that occur entirely within the browser context, it is vital that organizations look to monitor the browser as a detection surface, hunt for signs of malicious activity, and block attacks in real-time — in the same way that you would expect EDR to work for endpoint attacks. We’ll talk about how we do this below, but first here’s some general recommendations. 

Microsoft ecosystem

Despite the similarity with device code phishing, the primary recommendation from Microsoft for device code attacks — disable the device code flow via conditional access — doesn’t apply to ConsentFix (because, as mentioned, it uses a different login flow).

For both ConsentFix and device code phishing, the strongest recommendation is to create Service Principals for each of the vulnerable apps and restrict the users that are authorized to access them to reduce the attack surface of users that can be phished with this method.

You should also hunt in logs for relevant application IDs and resource IDs, and look for mismatches in terms of the initial access IP and subsequent activity, because while the initial login is performed by the user, subsequent actions will be performed by the attacker.  

Beyond Microsoft — Google, GitHub, Salesforce, AWS

It’s worth calling out that these recommendations are Microsoft specific. While in-the-wild exploitation has focused on Microsoft, GitHub, Salesforce, AWS and others are also impacted by device code phishing, supporting device code flow either as a primary or fallback mechanism (Google less so due to inherent restrictions on scopes authorized in the context of device code logins). 

Similarly, ConsentFix principles can be applied beyond Microsoft too. The core requirement is that an OAuth code ends up in a location the victim can manually see and share, e.g. a localhost redirect where no listener is present to complete the handshake. Google Cloud CLI, GitHub CLI, and others support the auth code grant and allow localhost as a redirect URI. 

How Push can help

We’re already detecting and blocking both ConsentFix and device code phishing attacks as they target users in their web browser. When a page matches our detections for a device code or ConsentFix phishing kit (not limited to things like known-bad IPs and domains, but DOM-level analysis of the web page) Push detects and blocks it. Unlike an SWG or RBI type solution, Push analyzes every web page in every browser session and tab, in real time, with no latency. 

Using Push you can also configure in-browser warnings whenever a user accesses a URL used for device code logins, across any app that supports them. This provides universal, last-mile protection against even ‘zero-day’ device code phishing attacks using previously unidentified toolkits.  

When a user visits those URLs, Push will also emit a webhook event that the banner was shown and acknowledged. If a user opts to proceed, you can treat this as a high-fidelity alert for your security team to investigate, providing app-agnostic telemetry that may not already be provided in your logs from that particular vendor. You can also simply use Push to block users from accessing these pages if you’re confident that disruption won’t be caused. 

Learn more about Push

Push Security's browser-based security platform detects and blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, device code phishing, ClickFix, and session hijacking. You don't need to wait until it all goes wrong either — you can use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, risky OAuth integrations, and more to harden your attack surface.

To learn more about Push, check out our latest product overview, view our demo library, or book some time with one of our team for a live demo.