Security researchers have uncovered a sophisticated new phishing technique called ConsentFix that weaponizes Microsoft's own OAuth authentication flows and the Azure Command-Line Interface (Azure CLI) to hijack Microsoft accounts without passwords, without directly bypassing multi-factor authentication (MFA), and often without creating obvious audit trails. This browser-native attack represents a significant evolution in identity-based threats, exploiting the implicit trust organizations place in first-party Microsoft applications and the subtle social engineering of users into completing seemingly harmless actions.
The Anatomy of a ConsentFix Attack
ConsentFix operates through a multi-stage process that begins with sophisticated targeting and ends with attackers gaining programmatic access to Microsoft Graph and other tenant resources. According to research from Push Security and corroborated by independent analysis, the attack follows a precise sequence that leverages legitimate Microsoft authentication mechanisms against users.
Initial Targeting and Lure
The attack typically begins with search-engine poisoning or compromised legitimate websites. Attackers create convincing user interfaces, often mimicking Cloudflare Turnstile verification challenges, to filter visitors and identify corporate targets. When users visit these sites, they're prompted to enter their email address. The system filters out personal email domains, focusing exclusively on corporate accounts that provide access to valuable organizational resources.
For selected targets, the site presents a "Sign In" button that opens a legitimate Microsoft sign-in page in a new browser tab. This is a critical distinction from traditional phishing—users aren't interacting with a fake login page but with Microsoft's actual authentication service. If the user already has an active Microsoft session, they might complete this step with a single click, making the attack even more seamless.
The OAuth Redirect and Social Engineering Hook
After authentication, Microsoft's system redirects the browser to a localhost URL containing an OAuth authorization code. This is a normal part of many OAuth flows for native applications and developer tools, including Azure CLI. The URL typically looks something like http://127.0.0.1:port/?code=AUTH_CODE&...
Here's where the social engineering occurs: The original phishing page instructs the victim to copy this localhost URL from their browser address bar and paste it back into the malicious site to "complete verification." This single copy-paste action appears harmless to users but completes the OAuth grant flow under the attacker's control, handing them the authorization code needed to obtain access tokens.
Exploiting Azure CLI's Elevated Trust
What makes ConsentFix particularly dangerous is its targeting of Azure CLI, a first-party Microsoft application that enjoys elevated trust within Microsoft Entra ID (formerly Azure AD). According to Microsoft documentation and security researchers, Azure CLI's application ID is treated differently from third-party applications in several critical ways:
- Implicit Trust: As a Microsoft-managed application, Azure CLI benefits from built-in trust within the Entra ID ecosystem
- Consent Bypass Potential: Some flows may allow requests for powerful Graph scopes with reduced consent requirements
- Operational Constraints: Many tenants cannot fully block or remove certain Microsoft-managed service principals through standard portal controls
This elevated status means attackers can obtain tokens with broad permissions that might otherwise require administrative approval for third-party applications.
Why First-Party Applications Are Attractive Targets
ConsentFix highlights a broader trend in identity attacks: adversaries are increasingly targeting trusted first-party applications rather than attempting to register malicious third-party apps. Several factors make these applications particularly attractive:
Trust and Operational Realities
First-party Microsoft applications like Azure CLI are built into the Entra ID ecosystem. Many organizations cannot outright remove these service principals through normal administrative interfaces, creating operational challenges for security teams. While Microsoft has documentation acknowledging that certain Microsoft-managed applications may not be removable via standard portal controls, this creates a gap that attackers can exploit.
Powerful Access Scopes
Some OAuth flows for first-party applications allow requests for powerful Microsoft Graph scopes, including both documented permissions and, in some cases, undocumented internal scopes. Once attackers obtain tokens with these permissions, they gain programmatic access to perform high-impact actions across the tenant.
Consent Governance Gaps
Although Microsoft has tightened default user-consent policies in recent years, organizational settings vary widely. Many companies still permit user consent for certain delegated scopes or leave admin consent options enabled for privileged roles. Attackers specifically target these gaps and high-value users (administrators or developers) to maximize their impact.
Low Detection Footprint
Because ConsentFix operates within the browser and uses legitimate Microsoft backend flows, traditional endpoint detection and response (EDR) tools and network monitoring may not flag the activity as malicious. The attack generates minimal endpoint artifacts, making cloud and identity telemetry the primary detection surface.
Community Perspectives and Real-World Concerns
WindowsForum.com discussions reveal significant concern among IT administrators about the practical implications of ConsentFix. Community members highlight several operational challenges that make this attack particularly concerning for organizations of all sizes.
The "Cannot Be Blocked" Dilemma
Forum participants note that while security researchers sometimes describe certain Microsoft-managed applications as "cannot be blocked or deleted," this represents an operational reality rather than an absolute technical impossibility. As one administrator explained, "The practical truth is that many of us can't remove these first-party service principals through our normal admin portals, even if there might be programmatic ways to restrict them."
This creates a significant defensive challenge, as organizations must implement layered controls rather than relying on simple application blocking.
User Education Challenges
Community discussions emphasize the difficulty of training users to recognize consent phishing. Unlike traditional credential phishing, where users are trained to look for suspicious URLs and login forms, ConsentFix uses legitimate Microsoft pages and asks users to perform actions that appear benign. "How do you train users to be suspicious of copying and pasting a URL?" asked one security professional. "That's a fundamental workflow for many legitimate applications."
Detection Complexity
IT administrators on the forum shared their experiences with detecting similar attacks, noting that traditional security monitoring often misses the subtle signs of consent phishing. "We're seeing attacks that look like normal application activity in our logs," reported one enterprise security analyst. "The Graph API calls, the OAuth flows—they all look legitimate because they are legitimate flows being abused."
Detection and Mitigation Strategies
Defending against ConsentFix requires a multi-layered approach that combines technical controls, monitoring enhancements, and user education. Based on both the original research and community discussions, organizations should implement the following strategies.
Immediate Detection Actions
Monitor Azure CLI Activity: Create alerts for interactive Azure CLI sign-ins, particularly for users who don't normally use command-line tools. Focus on device-code and localhost redirect flows that don't align with normal user behavior patterns.
Audit Consent Events: Regularly review "Consent to application" events in Entra ID/Sign-in logs. Look for unexpected enterprise applications or consent grants requesting broad Graph scopes, especially those targeting first-party Microsoft applications.
Token Management: Implement processes to revoke suspicious refresh tokens and force sign-outs for potentially compromised accounts. Shorter token lifetimes can significantly reduce attacker dwell time.
Technical Controls and Configuration
Restrict User Consent: Disable or severely restrict user application registration and self-consent where not required by business processes. Implement admin consent workflows for high-impact permissions, requiring explicit approval for sensitive access requests.
Conditional Access Policies: Apply Conditional Access policies that enforce device compliance, location restrictions, and risk-based assessments for OAuth token issuance. Treat OAuth consent events with the same suspicion as interactive sign-ins, applying similar security controls.
Token Lifetime Management: Reduce access token lifetimes and enable refresh token rotation where possible. Implement least-privilege principles for application scopes, granting only the minimum permissions necessary for each application's function.
Organizational and Process Controls
App Consent Governance: Maintain a whitelist of approved applications and require publisher verification for third-party apps. Conduct regular access reviews for application consent and service principals, automating alerts for newly registered applications requesting high-impact scopes.
Privileged Access Workstations: Require Privileged Access Workstations (PAWs) or similarly hardened devices for administrators performing consent decisions. Separate duties so that a single administrator cannot silently grant tenant-wide privileges to unvetted applications.
User Training Evolution: Develop phishing simulations that include consent-phishing scenarios, demonstrating how OAuth consent differs from traditional sign-in processes. Train users to recognize red flags such as unknown application names, unusual redirect URIs, and prompts to copy/paste local URLs.
The Broader Threat Landscape
ConsentFix represents more than just an isolated attack technique—it reflects a fundamental shift in how adversaries target cloud identities. Recent history shows attackers increasingly gravitating toward:
Trusted Infrastructure Abuse: Using legitimate vendor domains and first-party applications to bypass URL-based protections and benefit from implicit trust relationships.
OAuth and Token-Based Attacks: Focusing on obtaining bearer credentials through consent manipulation rather than stealing passwords, allowing attackers to bypass MFA and other authentication controls.
Low-Noise Operations: Leveraging API-based activity and cloud automation to persist and exfiltrate data without generating traditional endpoint artifacts, making detection more challenging.
This evolution underscores why identity has become the new perimeter in cloud security. As noted in community discussions, "We've spent years building stronger authentication, but now attackers are going around it by manipulating the authorization layer."
Microsoft's Response and Platform Evolution
Microsoft has been actively working to improve default security settings across its identity platform. In 2025, the company introduced Secure-by-Default managed policies and has continued to tighten default consent settings. However, as forum participants note, these improvements don't automatically protect organizations with legacy or custom configurations.
Key platform improvements include:
- Enhanced Consent Policies: Tighter restrictions on user consent for sensitive permissions
- Admin Consent Workflow: Improved processes for requiring administrative approval for high-risk permissions
- Token Protection Features: Enhanced capabilities for monitoring and controlling token usage
Despite these improvements, organizations must actively verify their tenant settings rather than assuming vendor defaults provide complete protection. As one administrator warned, "Microsoft can improve the defaults, but we're responsible for our configurations."
Strategic Implications for Cloud Security
The emergence of ConsentFix has significant implications for how organizations approach cloud identity security:
Identity-First Defense Posture: Organizations must shift from perimeter and credential-centric security models to identity-first approaches that treat OAuth grants, tokens, and application consent as critical control points.
Continuous Verification: Zero-trust principles—assuming no implicit trust for any application or flow and continuously verifying authorization claims—have moved from theoretical concepts to operational necessities.
Telemetry Investment: Comprehensive identity telemetry from Entra ID, Microsoft 365, and Azure activity logs has become essential for detecting sophisticated attacks that bypass traditional security controls.
Cross-Signal Correlation: Effective detection requires correlating multiple signals across identity systems, including consent events, application registrations, Graph API activity, and resource access patterns.
Practical Checklist for Immediate Action
Based on the combined insights from security research and community experience, organizations should prioritize the following actions:
-
Enforce Admin Consent: Require administrative approval for high-impact Graph scopes and disable user application registration unless specifically required for business operations.
-
Monitor Azure CLI Activity: Implement alerts for unexpected interactive Azure CLI sign-ins and localhost redirect flows, treating unusual CLI activity as high-priority security events.
-
Audit Consent Grants: Regularly review "Consent to application" events and revoke suspicious grants. Implement processes for rotating or revoking refresh tokens for potentially compromised accounts.
-
Apply Conditional Access: Require compliant device posture or Privileged Access Workstations for administrative consent decisions and high-risk OAuth flows.
-
Manage Token Security: Shorten token lifetimes, enable refresh token rotation, and enforce least-privilege principles for delegated permissions.
-
Evolve User Training: Develop and implement consent-phishing simulations that mirror the copy-paste mechanics used in attacks like ConsentFix, helping users recognize these subtle social engineering techniques.
Conclusion
ConsentFix represents a sophisticated evolution in identity attacks that exploits the very convenience and trust mechanisms designed to make cloud applications more usable. By weaponizing legitimate Microsoft OAuth flows and the implicit trust in first-party applications like Azure CLI, attackers can bypass traditional security controls with minimal user interaction and low detection visibility.
The defense against such attacks requires a fundamental shift in security posture—treating OAuth consent and first-party application behavior as high-risk controls, implementing comprehensive identity telemetry, and combining technical controls with realistic user education. Organizations that proactively audit their consent configurations, restrict unnecessary application permissions, monitor for unusual Azure CLI and Graph activity, and enforce least-privilege principles will be better positioned to defend against ConsentFix and the broader class of token-based attacks that follow similar patterns.
As the cloud identity landscape continues to evolve, the lesson from ConsentFix is clear: in modern cloud environments, identity isn't just another security control—it's the front line of defense, requiring continuous attention, investment, and evolution to match the sophistication of emerging threats.