ITInnovationStation

For years, most user-facing security training has focused on a simple warning: do not type your password into a fake login page. That advice still matters, but it no longer covers the full shape of modern identity attacks. ConsentFix is a perfect example of why. In a ConsentFix attack, the Microsoft login page may be completely real. The user may authenticate successfully. MFA may even be satisfied. Nothing about the login screen has to be fake for the attacker to win.

ConsentFix, also called AuthCodeFix, is a newer style of OAuth phishing that targets the authorization process behind cloud sign-ins. Instead of stealing a password, the attacker tricks the victim into handing over an OAuth authorization code. That code can then be exchanged for access tokens, allowing the attacker to act as the user against Microsoft cloud resources, depending on what the token allows.

This is what makes the attack so uncomfortable for defenders. It abuses trust in legitimate Microsoft identity flows. It does not need malware on the endpoint. It does not always need a malicious third-party app consent screen. It can happen entirely in the browser. And to the user, it can feel like they simply completed a normal Microsoft sign-in and followed a troubleshooting instruction.

The old phishing model is too narrow

Traditional phishing usually follows a familiar pattern. A user receives an email, clicks a link, lands on a fake Microsoft 365 page, enters a username and password, and the attacker captures the credentials. More advanced adversary-in-the-middle kits then proxy the real Microsoft login page so they can capture session cookies after MFA.

ConsentFix is different. It borrows the social engineering style of ClickFix attacks, where users are told to copy, paste, or run something to “fix” a browser issue, verification problem, document access problem, or login failure. But instead of telling the user to paste PowerShell into a Run box, ConsentFix tells the user to copy and paste a browser URL.

That sounds harmless. Most users do not think of a URL as a secret. They may recognize that passwords, MFA codes, and one-time passcodes are sensitive, but a long browser address full of random text looks like technical garbage. ConsentFix weaponizes that assumption.

The secret is not the whole URL. The secret is buried inside it.

What the attack actually steals

OAuth is the authorization system used behind many modern cloud sign-ins. In a normal authorization code flow, a user authenticates, the identity provider redirects the browser back to an application, and that redirect includes a short-lived authorization code. The application then exchanges that code for tokens.

In normal use, this is expected behavior. If you sign into a command-line tool, developer tool, or desktop application, the app may launch a browser, ask you to authenticate, and wait for the redirect to come back. Native apps often use localhost redirect URLs because the app running on the machine can listen locally for the response.

ConsentFix turns that design against the user.

The attacker creates a real Microsoft OAuth authorization request. The request may target a trusted Microsoft first-party app such as Azure CLI, Azure PowerShell, Visual Studio, VS Code, or another application commonly used in Microsoft ecosystems. The victim is sent to Microsoft’s real sign-in page and completes authentication. When Microsoft redirects the browser, the URL contains an authorization code.

In a normal Azure CLI login, the local command-line process would catch that code. In the attack scenario, there may be nothing legitimate listening for it, so the user sees a browser error or an unexpected localhost page. The phishing site then tells the user something like, “If the page fails to load, copy the full address from the browser and paste it here.”

The user thinks they are helping the login continue.

What they actually do is give the attacker the code needed to obtain tokens.

Why the Microsoft page being real makes this so dangerous

A lot of security controls and user instincts are built around detecting fake pages. Is the domain wrong? Is the certificate bad? Is the branding off? Is the login form suspicious? With ConsentFix, those checks may not help because the user can be sent to a real Microsoft authentication endpoint.

That creates a dangerous trust gap. Users have been taught that if the login page is Microsoft-owned and the browser looks normal, the process is probably safe. In this attack, the risky part comes after the login. The user is tricked into exposing the redirect result.

This also creates confusion during incident response. A victim may say, truthfully, “I only signed into Microsoft.” Logs may show a real Microsoft sign-in. MFA may show as satisfied. A password may never have been entered into an attacker-controlled form. From a traditional credential-theft perspective, that can look less suspicious than it really is.

But the attacker does not need the password if they can obtain tokens.

Why MFA does not automatically solve it

MFA is still important. It stops many password-based attacks and reduces account takeover risk. But MFA is not magic. It protects the authentication event. It does not protect every downstream action a user can be tricked into performing after authentication.

In ConsentFix, the user may authenticate directly with Microsoft. If MFA is required, the user may complete it. The attacker is not necessarily bypassing MFA by guessing a code or defeating the prompt. The attacker is abusing the fact that, after successful authentication, Microsoft produces an authorization result. The user is then socially engineered into sharing part of that result.

Think of it like this: MFA proves that the person at the keyboard could successfully sign in. It does not prove that the person understood where the resulting authorization code was going.

That is why ConsentFix is better understood as token theft through social engineering, not simple password theft. The attacker is not asking for the password. The attacker is asking for the thing created after the password and MFA process succeeds.

Why first-party Microsoft apps matter

One of the most important parts of the ConsentFix discussion is the use of trusted first-party Microsoft applications. Many organizations focus heavily on blocking user consent to unknown third-party apps. That is a good control, but ConsentFix highlights another problem: some trusted Microsoft apps are broadly usable by default.

Azure CLI is a good example. In many tenants, regular users may be able to initiate an Azure CLI OAuth flow even if they have no legitimate business reason to use Azure CLI. That does not mean Azure CLI is malicious. It means attackers can abuse the trust and availability of that application in tenants where access is not restricted.

This is a major difference between classic illicit consent attacks and ConsentFix-style abuse. In classic consent phishing, the attacker often registers their own app and tricks the user into granting it permissions. That creates a suspicious application object or consent grant defenders can hunt. ConsentFix can instead ride through legitimate application identities, making the activity blend into normal cloud authentication noise.

The question becomes: should every user in the tenant be allowed to obtain tokens through developer and administrative tools? For many businesses, the answer is no.

The user experience of the attack

A ConsentFix lure does not have to look highly technical. It may start with a page that looks like a file access portal, document verification page, CAPTCHA-style check, cloud security prompt, or browser validation page. The victim is guided through steps that appear routine.

The page may ask for an email address first. Then it may redirect the user to Microsoft. The user sees the real Microsoft login experience. If they are already signed in, they may only select their existing account. If MFA is required, they complete it. The browser then lands on a localhost URL or error page. The phishing page provides the “fix”: copy the address and paste it back.

That final copy-paste action is the entire trick.

This is why security awareness training has to evolve. “Do not enter your password on fake pages” is no longer enough. Users also need to understand that copying and pasting browser URLs, error messages, authorization codes, device codes, or command output into an unknown website can be dangerous.

What defenders should look for

ConsentFix detection is not as simple as looking for failed passwords. Failed password spray attempts and ConsentFix are different attack paths. A password spray produces many failed sign-ins from suspicious IPs. ConsentFix may produce a successful sign-in to a trusted app from a legitimate browser session, followed by suspicious token use.

Defenders should pay special attention to unexpected use of first-party Microsoft apps that are not normally used by the affected user population. Azure CLI, Azure PowerShell, Visual Studio, VS Code, Teams PowerShell, and similar tools may be normal for admins or developers. They are less normal for accounting, sales, warehouse, dispatch, HR, or general office staff.

Useful questions include:

Did this user ever use Azure CLI before?

Was the sign-in interactive?

Was there an OAuth authorization event involving Microsoft Graph or Azure resources?

Was the redirect behavior consistent with a localhost native-client flow?

Did token use appear from infrastructure, countries, browsers, or user agents that do not match the user?

Did the account access mail, files, Graph, Azure, or Entra resources shortly after the event?

Did the sign-in happen immediately after the user visited a suspicious website?

Detection has to combine identity logs, app activity, sign-in history, user role context, and normal business behavior. Seeing Azure CLI used by a cloud engineer is not the same as seeing Azure CLI used by a receptionist.

Why the “quick fix” works

The commonly discussed mitigation is to set selected service principals to require assignment. In Microsoft Entra, this means the application is not generally available to every user. A user or group must be explicitly assigned before they can sign in to or obtain tokens for that application.

That does not remove Azure CLI or break Microsoft as an identity provider. It narrows access. Instead of every user being able to start an OAuth flow against a powerful first-party app, only approved users can do so.

For many organizations, this is a sensible control. Most users do not need Azure CLI. Most users do not need Azure PowerShell. Most users do not need Visual Studio or VS Code OAuth access into tenant resources. Admins, engineers, and automation accounts may need exceptions, but exceptions should be deliberate.

The control changes the default from “allowed unless blocked” to “blocked unless assigned” for those specific app paths.

That is the right mental model. ConsentFix is not fixed only by telling users to be careful. It is fixed by reducing which users can complete the abused flow in the first place.

Be careful before flipping switches

There is one important warning: do not blindly apply this tenant-wide without understanding who uses these applications. Developer teams, cloud administrators, helpdesk engineers, automation workflows, and security tools may depend on these first-party apps.

A good rollout should start with investigation. Review recent sign-ins and token activity for the target apps. Identify legitimate users and service accounts. Build an assignment group for approved usage. Communicate the change. Then enforce assignment-required behavior.

This is not because the mitigation is bad. It is because Microsoft tenants often grow organically. People may be using tools nobody documented. A rushed change can break admin workflows, scripts, onboarding processes, or emergency access procedures.

The best version of the fix is controlled and reversible.

Incident response if ConsentFix is suspected

If you suspect a user was hit by ConsentFix, do not treat it like only a password issue. A password reset may be appropriate, but it is not enough by itself. The concern is token theft.

A practical response should include revoking user sessions and refresh tokens, reviewing recent OAuth activity, checking enterprise app sign-ins, reviewing mailbox and file access, looking for suspicious Graph activity, and confirming whether any new app grants or role assignments were created. If the user has admin privileges, expand the investigation quickly.

You should also check whether the account was used to access Azure, Entra, Exchange Online, SharePoint, Teams, or other SaaS resources after the suspicious authorization event. The attacker’s goal may not be immediate mailbox access. It may be persistence, reconnaissance, data theft, privilege discovery, or movement into cloud administration.

For high-risk users, assume the token may have been used until logs prove otherwise.

The larger lesson

ConsentFix is part of a broader trend: attackers are moving from credential theft to identity-flow abuse. They are not only asking, “Can I steal the password?” They are asking, “Can I trick the user into completing a legitimate workflow that gives me a token?”

That shift matters because modern cloud security depends on tokens, grants, sessions, service principals, consent, and app trust. Passwords are only one part of the identity system. Once an attacker understands the authorization layer, they can target the seams between user behavior and cloud design.

The uncomfortable truth is that users are often doing exactly what the page tells them to do. They are not always being careless. They are being manipulated inside systems that were designed to make authentication convenient.

That means the answer cannot be training alone. Training helps, but controls must reduce the blast radius of a successful trick.

Practical defense strategy

A strong defense against ConsentFix should include several layers.

First, restrict risky first-party app access. If normal users do not need Azure CLI, Azure PowerShell, Visual Studio, VS Code, or Teams PowerShell, require assignment and only assign approved groups.

Second, monitor OAuth authorization events involving first-party apps and sensitive resources. Alerts should be tuned around user role and expected behavior. A developer using VS Code may be normal. A billing user authorizing Azure CLI should raise questions.

Third, disable or restrict user consent where possible. Require admin approval for risky permissions and review consent grants regularly.

Fourth, treat token theft as its own incident category. Session revocation, token invalidation, app review, and cloud activity review should be part of the playbook.

Fifth, update user training. Teach users that copying a browser URL into a website can be dangerous, especially after a Microsoft sign-in failure or localhost error.

Finally, document exceptions. If a user needs Azure CLI, assign them through a named group with an owner, a reason, and periodic review. Do not let administrative tooling be available to the entire tenant simply because it always has been.

Final thoughts

ConsentFix is dangerous because it feels legitimate at the exact moment the user is being compromised. The Microsoft login page can be real. MFA can be completed. The application can be trusted. The browser can show a normal Microsoft domain. The user can believe they are fixing a login problem.

But the copied URL contains the key.

The right response is not panic. It is control. Know which first-party apps your users can access. Limit powerful OAuth paths to the people who actually need them. Hunt for unexpected authorization behavior. Revoke tokens quickly when something looks wrong. Train users that “copy this URL and paste it here” is not harmless when it appears during a sign-in flow.

ConsentFix is a reminder that identity security is no longer just about passwords. It is about understanding the entire path from login to token to resource access. Attackers already understand that path. Defenders need to understand it better.