NVISO | Image: An access token
A cunning new phishing technique is turning the trust of Microsoft’s own tools against its users. Dubbed “ConsentFix” (or AuthCodeFix), this attack tricks victims into handing over the keys to their Microsoft accounts by exploiting the OAuth 2.0 authorization flow used by legitimate applications like Azure CLI.
Analyzed by Stamatis Chatzimangou of NVISO’s Threat Detection Engineering team, the technique represents a dangerous evolution in “fix-type” phishing attacks. Instead of stealing a password, the attacker steals a pre-approved authorization code, allowing them to bypass Multi-Factor Authentication (MFA) and Conditional Access policies.
The attack begins with a classic setup: a phishing page prompting the user to log in. But the twist comes after authentication. The victim is redirected to a legitimate Microsoft login page to authorize an app—often a trusted first-party tool like Azure CLI.
Because Azure CLI is a Microsoft application, it is “implicitly trusted by Entra ID,” meaning users often don’t see a consent prompt at all.
The trap springs when the user is redirected to a localhost URL. Since no application is actually running on the victim’s machine to catch this request, the browser displays a “This site can’t be reached” error. This error is not a bug; it’s the feature the attackers rely on.
“The adversary exploits this by instructing the victim to copy and paste the URL containing the authorization code back into the phishing site if that error appears”.
Believing they are “fixing” a login glitch, the victim manually pastes the URL—which contains the golden authorization code—into the attacker’s fake site.
Once the attacker has the code, they can trade it for an access token using Microsoft’s APIs. This token grants them access to the victim’s account with the same permissions as the application they spoofed.
Crucially, this exchange happens on the attacker’s machine, effectively sidestepping security controls. “While the user’s initial sign-in… is governed by Conditional Access policies, once the adversary obtains the authorization code, they can exchange it for an access token without triggering a new Conditional Access evaluation”.
This allows attackers to “obtain tokens from non-compliant devices or untrusted locations” that would normally be blocked.
The report highlights that Azure CLI is just one of many vulnerable first-party applications. Others include:
- Microsoft Azure PowerShell
- Visual Studio Code
- Microsoft Teams
- Microsoft SharePoint Online Management Shell
Attackers can choose different “return URIs” to make the ruse even more convincing. For instance, using https://aadrm.com/adminpowershell redirects the victim to a legitimate-looking page that still exposes the code in the address bar.
Since the attack abuses legitimate flows, blocking it is difficult without breaking essential developer tools. However, Chatzimangou points out that the attack leaves a trail in the logs.
Security teams can hunt for this activity by correlating the victim’s initial sign-in with the attacker’s subsequent token exchange. The key is to look for discrepancies in the IP Address and Location fields within the AADNonInteractiveUserSignInLogs table, where the same Session ID will show activity from two geographically distant locations—the victim’s and the attacker’s.
As users become savvier to traditional credential phishing, ConsentFix serves as a reminder that attackers are shifting their focus to the underlying protocols of identity itself.