ConsentFix: Abusing Azure OAuth Consent to Take Over Microsoft Accounts

What is ConsentFix?

ConsentFix is a browser-native phishing technique that compromises Microsoft accounts by abusing legitimate Microsoft Entra ID (Azure AD) OAuth authorization flows, often without capturing passwords and sometimes without triggering an MFA prompt if the victim already has an active Microsoft session in the browser.

Unlike classic phishing, there's no fake login page. The victim authenticates on real Microsoft domains, then gets socially engineered into copy-pasting a URL that contains OAuth key material into the attacker's page.

Why this works: authentication vs. authorization

OAuth is designed so that after a user successfully signs in, the authorization server redirects the user agent back to a redirect URI (reply URL). The redirect carries an authorization code that can later be exchanged for tokens.

ConsentFix doesn't "break" OAuth, it abuses it:

• The user legitimately signs in (and may even complete MFA) on Microsoft pages.
• The attacker steals the authorization code and exchanges it for tokens.
• The attacker now has access without ever learning the password.

The ConsentFix twist: localhost + Azure CLI trust

The key innovation is pairing:

• a localhost loopback redirect (typical for native/public clients),
• a high-trust first-party client: the Microsoft Azure CLI OAuth application.

Because native/public clients commonly use loopback redirects (e.g., http://localhost:<port>), the authorization code ends up in the browser address bar pointing to localhost, where nothing is listening. The "gap" is closed by social engineering: the user is told to copy/paste that localhost URL back into the phishing page. Attack reports specifically note abuse of Azure CLI trust as a core enabler in these takeovers.

Attack flow (step-by-step)

1) Initial lure: ClickFix-style "verification"

Victims are routed to a malicious flow (often via SEO poisoning / compromised sites) and shown a fake "verify you're human / fix your session" prompt.

2) Victim is sent to a real Microsoft authorization URL

A new tab opens to Microsoft's authorization endpoint with parameters pointing to a trusted client (Azure CLI) and a loopback redirect:

https://login.microsoftonline.com/.../oauth2/v2.0/authorize?...
redirect_uri=http://localhost:<port>
response_type=code
# plus scopes/resources appropriate for the attacker's goals

3) User signs in normally (no credential theft)

If the user is already signed into Microsoft in that browser session, this can be nearly frictionless and may not trigger an MFA prompt. If not, the user signs in and completes MFA on Microsoft pages (still not stolen by the attacker).

4) Microsoft redirects to localhost with an authorization code

After successful auth, the browser is redirected to something like:

http://localhost:<port>/?code=<AUTH_CODE>&...

The page fails to load, but the URL in the address bar contains the code.

5) The "consent fix": victim copy-pastes the localhost URL

The phishing page instructs the victim to copy the entire localhost URL and paste it into the page "to complete verification." That transfers the authorization code to the attacker.

6) Attacker exchanges the code for tokens

Because Azure CLI behaves as a public/native client, the attacker can exchange the stolen authorization code for tokens and begin operating as the victim in cloud services, without ever needing the victim's password.

Why traditional controls often fail

MFA doesn't stop it (by design). MFA protects authentication. ConsentFix steals OAuth code/token material after (or as a result of) legitimate authentication. In the "already signed-in" case, the victim may not get challenged at all.

URL scanning and email security miss it. The authorization URL is on a legitimate Microsoft domain, and the attacker's "exfil" is a user-driven paste action. Many controls are tuned to detect clicks to bad domains, not copy/paste of trusted URLs.

Conditional Access can be sidestepped depending on configuration. If the authorization happens in a normal corporate browser session on a compliant device/location, policies may be satisfied. The "suspicious" part is not a login, it's the stolen authorization code and subsequent token use.

Post-compromise: what attackers do next

Once tokens are obtained, attackers typically go after high-value identity and productivity surfaces:

• Enumerate tenant / users / groups and identify privileged targets.
• Access Microsoft 365 data depending on token scopes and victim permissions.
• Maintain access via refresh tokens until sessions/consents are revoked.

Detection: the signals that actually matter

ConsentFix doesn't look like "bad password" or "MFA fatigue." You need detection that focuses on OAuth and token behavior:

• Azure CLI sign-ins for users who don't normally use it (especially non-IT personas).
• Sudden OAuth/token activity followed by unusual API access patterns (directory enumeration, new service access, etc.).

Operational reality: if your SOC isn't continuously correlating sign-in, token issuance, and API usage, ConsentFix can look like "a normal Microsoft login."

Mitigation: what to change today

• Restrict the Azure management surface for non-admin users. If most users don't need Azure CLI / Azure management access, enforce policy boundaries around that access.
• Harden consent and app access governance. Even though ConsentFix abuses a first-party trusted client, tightening app governance reduces adjacent consent-phishing and limits blast radius.
• Train on the specific trick: "Never copy/paste login URLs or 'verification links' from your browser into a webpage." This is the user action that completes the theft.

Why Cyngular AI SOC & IR is built for attacks like ConsentFix

ConsentFix is an identity authorization abuse problem, not a classic phishing credential problem. Cyngular AI SOC & IR focuses on the right layer:

• Continuous monitoring of Entra ID sign-ins + token-driven activity.
• Detection logic for trusted app abuse (like Azure CLI) and anomalous identity behavior.
• Automated investigation timelines that connect the phishing interaction to downstream API activity.

This is exactly the kind of attack where speed matters: by the time a human spots "something odd," tokens may already be used for discovery, lateral movement, and persistence. Cyngular's AI-driven triage + guided IR is designed to collapse that window.

ConsentFix highlights a structural shift in cloud attacks. Attackers don't need passwords. They need permissions and tokens.