A new ConsentFix v3 technique automates OAuth authorization-code phishing against Azure-linked accounts.
A new consent-hijacking technique nicknamed ConsentFix v3 is spreading across hacker forums, with attackers pitching it as a more automated way to abuse Microsoft Azure OAuth sign-in flows.
The core idea remains the same: instead of stealing passwords. victims are manipulated into completing a legitimate-looking login journey and then providing an OAuth authorization code.. That code can be exchanged for tokens that let an attacker take over an account. even when multi-factor authentication is enabled. because the MFA is bypassed as part of the genuine sign-in flow rather than defeated directly.
ConsentFix v3 builds on earlier versions that refined how convincing the trick could be.. The original approach relied on tricking targets into pasting a localhost URL containing an authorization code into the phishing flow.. Later improvements made the interaction smoother, replacing copy-and-paste behavior with more natural drag-and-drop steps.. In v3. the pitch shifts toward scale: the method is designed to automate parts of the process so attackers can run more sessions with less manual work.
In this context, the most concerning part is not just phishing pages, but what happens after the victim interaction. Once the code is captured, the pipeline can immediately trade it for tokens and pass those tokens into downstream tooling to act as the victim.
The automation revolves around an integration workflow that acts as a hub for three jobs: receiving the authorization code from the phishing page. exchanging it for token material via Microsoft’s API. and making the resulting tokens available to the attacker in near real time.. Attackers then host a page that mirrors Microsoft or Azure interfaces. initiates a real OAuth flow at Microsoft’s login endpoint. and uses the resulting localhost callback as the moment to capture the code.
To bolster credibility. the campaign workflow includes targeting multiple web services for different roles such as content hosting. data collection. and staging.. Phishing emails can also be tailored using information gathered from prior reconnaissance. and links can be embedded inside documents to help them look more legitimate and reduce the chance of being flagged by basic filters.
From there. the stolen tokens can be used with additional attacker infrastructure to interact with what the tokens permit inside Microsoft ecosystems. such as accessing email and files tied to the account.. The real-world impact can vary widely depending on permissions. the specific services enabled. and tenant configuration. and early testing has been limited by the fact that it relied on personal Microsoft accounts rather than measuring broader enterprise scenarios.
For defenders. this matters because the weakness isn’t a single misconfigured setting so much as a trust relationship baked into how first-party OAuth apps operate.. Even when administrators reduce phishing risk. the attacker’s leverage comes from turning legitimate flows into an entry point for token theft.
Mitigation guidance highlighted around this issue includes hardening token usage and limiting where tokens can be redeemed.. Practical steps mentioned include applying token binding to trusted devices. setting up behavioral detection for suspicious OAuth-related activity. and tightening application authentication restrictions—especially in environments where first-party consent and refresh-token sharing could widen the blast radius.
While ConsentFix v3 is being promoted in underground spaces, it’s still unclear how widely it is currently being used.. Still. the shift toward automation is a warning sign: attackers are trying to make OAuth abuse easier to scale. which is exactly what makes timely detection and tighter controls so important.