A newer version of the ConsentFix attack technique is drawing attention because it shows how OAuth phishing against Microsoft Azure environments can become faster, smoother, and easier to scale.
Dubbed ConsentFix v3, the technique builds on earlier ClickFix-style social engineering by targeting the OAuth authorization code flow rather than trying to steal a password directly. The core idea is not to defeat Microsoft authentication head-on. Instead, the victim is pushed through a legitimate Microsoft sign-in flow and then tricked into handing over the resulting authorization code.
That matters because the attack can work around a common buyer assumption: that multi-factor authentication, by itself, is enough to stop account takeover. MFA still matters, but OAuth-based phishing shifts the fight toward token handling, app trust, device context, and post-login behavior.
How ConsentFix Changed From Manual Phishing To Automation
The first ConsentFix technique was presented by Push Security as a variation of ClickFix for OAuth phishing. In that earlier flow, attackers used social engineering to convince a victim to complete a legitimate Microsoft login process through the Azure CLI. The victim was then induced to paste a localhost URL containing an OAuth authorization code.
That authorization code could be exchanged for tokens, allowing an attacker to hijack access without needing the user’s password. Because the victim had already completed the real Microsoft sign-in process, the attack could still succeed even where MFA was present.
A second version, associated with researcher John Hammond, reportedly refined the user interaction by replacing manual copy and paste with a drag-and-drop step involving the localhost URL. That detail has not been independently verified here, but the reported direction is important: each iteration appears aimed at making the phishing flow feel more natural to the victim.
ConsentFix v3 keeps the same basic premise. It still abuses the OAuth2 authorization code flow and focuses on Microsoft first-party applications that are already trusted or pre-consented in many environments. The notable change is that the newer version reportedly adds more automation around collection, token exchange, and operator access.
The Reported ConsentFix v3 Attack Flow
In the described v3 flow, attackers begin by preparing the target environment. That may include gathering employee details such as names, roles, and email addresses so phishing messages can be tailored to the organization. This reconnaissance step has not been independently verified here, but it is consistent with how targeted identity phishing campaigns are often made more convincing.
The operators are also described as setting up accounts across several services used for email, hosting, document delivery, lead research, automation, and data collection. The named services in the original reporting include Outlook, Tutanota, Cloudflare, DocSend, Hunter.io, and Pipedream.
The use of Pipedream is the most important operational detail. Push Security describes it as serving three roles in the attack chain: receiving the victim’s authorization code through a webhook, exchanging that code for a refresh token through Microsoft’s API, and collecting captured tokens for real-time access. That specific implementation detail has not been independently verified here, so defenders should treat it as a reported example rather than a fixed indicator that will appear in every campaign.
The phishing page is reportedly hosted on Cloudflare Pages and designed to resemble a Microsoft or Azure interface. From there, the page starts a real OAuth flow through Microsoft’s login endpoint. That claim has not been independently verified here, but it fits the broader technique: the attacker wants the victim to trust the flow because the authentication step itself is legitimate.
When the victim interacts with the page, they are redirected to a localhost URL containing the OAuth authorization code. The phishing page then prompts them to paste or drag that URL back into the attacker-controlled page. Once the URL is supplied, the backend automation can send the captured code to the webhook and exchange it for tokens.
This is where v3 becomes more concerning for defenders. The attack is not just a trick for capturing a one-time artifact. The reported automation can move quickly from user interaction to token exchange, reducing the time available for detection and response.
Yubico YubiKey 5 NFC Security Key
Hardware security keys can reduce exposure to common credential phishing paths by requiring possession of a trusted physical authenticator. They are most useful when deployed with strong conditional access and device trust policies.
Why This Is Harder Than Password Phishing To Contain
ConsentFix-style attacks are difficult because they sit inside a gray area of cloud identity. The victim may authenticate through Microsoft. The attacker may target trusted first-party applications. The resulting tokens may allow access without an obvious password compromise event.
That creates problems for teams that still think primarily in terms of suspicious logins, failed MFA prompts, or stolen credentials. In this scenario, the important signals may appear after authentication: unusual OAuth flows, strange redirect behavior, token use from unexpected infrastructure, or access patterns that do not match the user’s normal device and location.
Push Security has also noted that its own testing relied on personal Microsoft accounts, meaning the full impact can vary by tenant configuration, permissions, services, and policy enforcement. That limitation has not been independently verified here, but the broader point is sound: the practical blast radius depends heavily on what the compromised token can access.
In a business environment, that could include email, files, internal services, and other Microsoft-connected resources available to the user or application context. The original reporting also says captured tokens may be imported into Specter Portal for interaction with compromised Microsoft environments. That specific post-exploitation workflow has not been independently verified here, so it should be treated as a reported operator path rather than a universal feature of ConsentFix v3.
Mitigation Depends On Token And App Controls
Blocking ConsentFix-style attacks is not as simple as telling users to avoid suspicious links, although security awareness still helps. The technique takes advantage of the way trusted applications and OAuth flows are meant to work.
Push Security argues that mitigation is complicated because trust in Microsoft first-party apps is architectural, and because Family of Client IDs behavior can allow related Microsoft applications to share permissions and refresh token access. That specific framing has not been independently verified here, but it points to a real defensive issue: identity teams need visibility into token issuance and token use, not just password events.
Administrators can reduce risk by tightening app authentication policies, limiting unnecessary app consent, watching for suspicious OAuth authorization flows, and requiring device trust where possible. Token binding to trusted devices, behavioral detection rules, and app authentication restrictions are also cited as possible controls, though the effectiveness of each depends on the tenant and the identity stack in place.
For related context, see Docker Hub Leak Exposes Secrets in 10,000+ Images.
For buyers evaluating identity security tools, the key question is whether the product can see and act on this class of activity. Useful capabilities include OAuth app visibility, token misuse detection, phishing-resistant authentication support, conditional access integration, and alerts that connect user behavior with cloud session activity.
Microsoft 365 Security Administration Guide
Teams reviewing OAuth exposure and Conditional Access policies may benefit from a Microsoft 365 security administration reference. It can support internal planning around identity protection, app access, and tenant security configuration.
What Security Teams Should Take From ConsentFix v3
ConsentFix v3 has not been confirmed here as a widely adopted criminal technique. The original reporting also leaves open whether this specific version has gained meaningful traction among threat actors. Still, the direction of travel is clear enough to matter.
OAuth phishing is becoming more polished. Attackers are trying to remove awkward manual steps. Automation platforms can shorten the time between victim interaction and token abuse. Trusted cloud application flows can make malicious activity look less obvious than classic credential theft.
For organizations using Microsoft cloud services, the practical takeaway is to review OAuth exposure now. Audit consent policies, monitor app activity, inspect sign-in and token behavior, and test whether current controls would flag a user who completed a legitimate Microsoft login but then exposed an authorization code to an attacker.
MFA remains necessary, but ConsentFix-style attacks show why it cannot be treated as the finish line. The next layer of defense is knowing when trusted identity flows are being used in ways that no legitimate user or device should need.