As reported by BleepingComputer, threat actors are actively combining two social engineering techniques — dubbed ConsentFix and ClickFix — to compromise Microsoft 365 accounts in seconds, completely bypassing multi-factor authentication. This is not a vulnerability in MFA itself; it is a fundamental exploitation of how modern authentication trusts users and the OAuth consent framework. The distinction matters enormously for defenders.

Key Takeaway: As reported by BleepingComputer, threat actors are actively combining two social engineering techniques — dubbed ConsentFix and ClickFix — to compromise Microsoft 365 accounts in seconds, completely bypassing multi-factor authentication.

Why This Attack Class Is Exceptionally Dangerous

The cybersecurity community has spent years evangelizing MFA as the single most effective control against account compromise. These attack chains are a direct response to that hardening. By targeting the post-authentication trust layer — specifically OAuth application consent and clipboard-injected commands — adversaries sidestep credential theft entirely. They don't need your password. They don't need your one-time code. They need only a moment of inattention from a legitimate user.

ConsentFix abuses the OAuth 2.0 consent flow by tricking users into granting a malicious third-party application permissions to their Microsoft 365 tenant. Once consented, the attacker's application holds a persistent access token that survives password resets and MFA re-enrollment. ClickFix, meanwhile, manipulates users into executing attacker-controlled commands by pasting clipboard content they believe to be legitimate — a deceptively simple but highly effective technique increasingly used across multiple threat actor groups.

Shield53 Analyst Note: Token-based persistence is one of the most underestimated threats in enterprise environments. A stolen or abused access token can maintain access for days or weeks with no further attacker interaction, and most SIEM deployments have minimal visibility into OAuth consent events.

Who Is Most at Risk

Who Is Most at Risk
Organizations that allow unrestricted OAuth app consent — this is the default configuration in many Microsoft 365 tenants
Remote and hybrid workforces where users frequently encounter unfamiliar login prompts and consent screens
Help desk and IT staff who are conditioned to run commands and may be targeted with ClickFix lures disguised as diagnostic tools
Finance, legal, and executive teams — high-value targets whose account access yields the most leverage for BEC and data exfiltration
SMBs and mid-market companies lacking dedicated identity security tooling or Entra ID P2 licensing for advanced controls

The Broader Threat Landscape Context

These techniques don't emerge in isolation. ClickFix has been observed in campaigns tied to multiple financially motivated threat groups and is increasingly being incorporated into phishing kits sold on cybercriminal forums. ConsentFix-style OAuth abuse has been documented in nation-state intrusion sets targeting cloud environments. The convergence of both into a single, streamlined attack chain signals maturation — adversaries are packaging sophisticated identity attacks for mass deployment.

Microsoft has controls available to restrict this attack surface, but they are not enabled by default, and many organizations are unaware of the exposure. The responsibility gap between what Microsoft provides and what organizations actually configure is where attackers live.

Shield53 Recommendations

Immediate Actions

  • Restrict OAuth app consent: In Microsoft Entra ID (Azure AD), navigate to Enterprise Applications > Consent and Permissions. Set user consent to "Do not allow user consent" or restrict to verified publishers only. Require admin approval for all third-party app consent requests.
  • Audit existing OAuth grants: Use the Entra ID portal or Microsoft Graph API to enumerate all applications with delegated or application permissions. Revoke any unrecognized or unused grants immediately.
  • Enable Conditional Access App Control: Deploy Conditional Access policies that block or require compliance for OAuth token issuance from unmanaged or non-compliant devices.
  • Alert on suspicious consent events: Configure SIEM rules or Microsoft Sentinel analytics to detect bulk consent grants, consent from non-standard locations, and grants to newly registered applications.
  • Educate users on consent prompt red flags: Users should be trained to pause on any OAuth consent screen that requests Mail.Read, Files.ReadWrite, or full_access_as_user permissions — these are high-risk scopes frequently abused.
  • Harden clipboard behavior: For privileged users and shared workstations, consider endpoint policies that alert or restrict clipboard paste into administrative terminals and browser address bars.

Longer-Term Controls

  • Adopt a Zero Trust posture for identity — validate every token request against device compliance, location, and behavior baselines, not just credential validity
  • Implement Continuous Access Evaluation (CAE) in Microsoft 365 to revoke tokens in near-real-time when risk signals are detected
  • Invest in identity threat detection and response (ITDR) tooling capable of monitoring OAuth activity, lateral movement via tokens, and anomalous graph API calls
  • Conduct tabletop exercises that specifically simulate OAuth consent abuse scenarios — most IR playbooks are still built around credential theft, not token abuse

The era of "enable MFA and you're protected" is over. Modern identity attacks operate in the trust layer above authentication, and defenders must evolve their controls — and their assumptions — accordingly. Shield53 strongly advises organizations to treat OAuth consent governance as a tier-one identity security control, not an afterthought.