ConsentFix: How Microsoft 365 Accounts are Hijacked in 30 Seconds

ConsentFix and ClickFix: How Microsoft 365 Accounts are Hijacked in Under 30 Seconds

The ConsentFix Microsoft 365 account hijacking method exploits a legitimate Microsoft OAuth flow, specifically targeting Microsoft 365 sign-in prompts. This attack represents a clever evolution of earlier ClickFix methods, which surged in 2025 by tricking users into pressing keyboard shortcuts to paste and execute attacker-supplied commands. ConsentFix advances this social engineering, making users believe they are completing a routine authentication, but targeting the OAuth consent flow itself. First surfaced by Push Security in late 2025 and tracked through multiple iterations, the latest variant, ConsentFix v3, was detailed with working code and infrastructure screenshots on a public Russian cybercrime forum by early March 2026, significantly lowering the barrier to entry for attackers.

The ConsentFix v3 Microsoft 365 attack chain, which can complete in under 30 seconds, unfolds as follows:

1. The Lure: It begins with a convincing phishing email or message, often delivered via trusted platforms. These lures are frequently password-protected, allowing them to bypass some security tools. Attackers profile targets using OSINT tools like Hunter.io and LinkedIn to personalize these messages. (MITRE ATT&CK T1566.002: Phishing: Spearphishing Link)

2. The Fake Verification: Clicking the link leads to a phishing page. This page often mimics a Cloudflare verification step, requesting a corporate email. It appears legitimate, sometimes even incorporating a genuine Cloudflare Turnstile element.

3. The Real Microsoft Window: The phishing page then invokes a *real* Microsoft sign-in URL in a separate browser window. Crucially, the attack leverages Azure CLI as the client_id. Azure CLI is a first-party Microsoft application, which grants it elevated trust and often bypasses Conditional Access policies. (MITRE ATT&CK T1078.004: Valid Accounts: Cloud Accounts)

4. Silent Authentication: If the user has an active Microsoft 365 session, Microsoft authenticates them silently. No password entry, no MFA prompt. The session is already established.

5. The Callback Hijack: After successful authentication, Microsoft redirects to Azure CLI's localhost callback URL, appending a one-time authorization code. This is standard OAuth 2.0 authorization code flow behavior. For a deeper dive into the technical specifications, refer to Microsoft's official documentation on the OAuth 2.0 authorization code flow.

6. Automated Capture: ConsentFix automates the capture of this localhost URL. Earlier versions required manual interaction, like dragging the link. This automation streamlines the attack, making it more efficient.

7. Token Exchange: The phishing page POSTs the captured URL to a Pipedream webhook. Pipedream, acting as a serverless function, extracts the authorization code. It then exchanges this code for an access token and, critically, a *refresh token* via Microsoft's token endpoint. (MITRE ATT&CK T1550.001: Use Alternate Authentication Material: Application Access Token)

8. Attacker Access: These tokens are then delivered to the attacker's command-and-control infrastructure, often to a client application.

Users never type a password into a fake form or fail an MFA challenge. They simply interact with what appears to be a normal Microsoft flow, and their session is compromised.

Understanding the Real Impact

The tokens an attacker steals are not fleeting. They provide persistent access to a user's Microsoft 365 environment, a core aspect of the ConsentFix Microsoft 365 threat:

• MFA Bypass: Since the initial authentication occurs legitimately, the stolen refresh token bypasses multi-factor authentication. The attacker does not need the user's second factor.

• Password Reset Persistence: Even if a user resets their password post-compromise, the stolen refresh token can remain valid, as password resets do not automatically revoke all active refresh tokens. This provides attackers with continued access.

• Conditional Access Bypass: Azure CLI, as a first-party Microsoft application, may be exempted from certain Conditional Access policies. This means controls like "block legacy authentication" or "require compliant device" often do not apply, providing attackers an unhindered path.

• Long-Term Access: Refresh tokens can have a configurable default lifetime of up to 90 days. This grants attackers months of potential access to email, OneDrive files, Teams chats, and potentially administrative scopes within Azure subscriptions if the user holds them, demonstrating the severe impact of ConsentFix Microsoft 365 compromises.

The compromise extends beyond basic email access, granting attackers deep and persistent control over a user's Microsoft 365 environment. An attacker with this level of access can send emails from the compromised account, move laterally within the organization, and escalate privileges. It constitutes a full account takeover, circumventing the very controls organizations rely on.

Responding to ConsentFix: Key Defenses

The rapid evolution of ConsentFix, particularly its v3 iteration, has prompted significant focus from the security community, including its initial discovery and tracking by Push Security. ConsentFix Microsoft 365 presents a significant challenge because it exploits user habits and the inherent trust in first-party Microsoft applications. Traditional security awareness training, focused on suspicious links, is less effective here. Users *do* interact with a genuine Microsoft authentication process.

Improving User Awareness Against ConsentFix Microsoft 365 Attacks

Users must be trained to question *any* request to drag unusual links into a browser or press hotkeys, even if the surrounding context appears legitimate. The attack leverages common user habits and trained reflexiveness, such as clicking CAPTCHAs or accepting cookie prompts, making traditional security awareness training less effective on its own. Training should highlight the specific indicators of a ConsentFix Microsoft 365 attempt, such as unexpected localhost redirects or prompts for Azure CLI authentication outside of developer workflows.

Strengthening Monitoring for Endpoints and Identities

Active monitoring for anomalous activity is crucial, such as:

• Azure CLI sign-in events originating from new geographies or autonomous systems (e.g., Pipedream IPs, Tor exit nodes).
• Refresh token issuance to Azure CLI for users who do not typically use it, a common indicator of ConsentFix Microsoft 365 activity.
• Microsoft Graph API calls against unusual or legacy endpoints, particularly those typically accessed only by first-party applications.
• OAuth grants accumulating without corresponding interactive sign-in events, detectable via SIEM or XDR solutions.

Implementing Technical Safeguards

Specific technical safeguards are essential:

• Scope Down Public Client Flows: Use Conditional Access policies to block or restrict public client flows. For sensitive scopes, require token binding to a managed device. This limits the utility of stolen tokens.
• Reduce Refresh Token Lifetime: Consider reducing the default 90-day refresh token lifetime. For sensitive accounts, this should be reduced to hours, not months, forcing more frequent re-authentication.
• Continuous Access Evaluation (CAE): Enable CAE on all supported workloads. CAE forces token re-evaluation based on real-time risk signals, allowing for faster revocation of compromised tokens.
• Phishing-Resistant Authentication: Phishing-resistant authentication offers a robust long-term solution against ConsentFix Microsoft 365. Hardware security keys (FIDO2/WebAuthn) and platform passkeys for all users secure the *upstream interactive sign-ins* that ConsentFix relies on. If the initial authentication is phishing-resistant, the entire attack chain breaks.

ConsentFix Microsoft 365 highlights that MFA alone is often no longer sufficient for account protection. Attackers are finding ways around our defenses by exploiting the trust placed in legitimate systems. Defenses must adapt to protect the session itself, beyond just the password. The focus needs to be on post-authentication security and continuous verification, rather than solely on the initial credential exchange.