ConsentFix v3: Exploiting Azure's First-Party Trust for Automated OAuth Abuse
Even with MFA and Conditional Access, sophisticated attacks like ConsentFix v3 can bypass controls, exploiting implicit trust within Microsoft's ecosystem. This new variant automates Azure OAuth abuse, posing a significant challenge for security teams.
While ConsentFix v1 and v2 have proven effective in campaigns, the v3 variant, with its automated approach, represents a significant escalation. These are not simple credential grabs; this is a sophisticated account compromise method that bypasses network-level filtering by using valid domains. It even circumvents multi-factor authentication (MFA), representing the core problem.
The Evolution of an Exploit: From ClickFix to Automated Azure Takeovers
ConsentFix evolved from ClickFix, a concept Push Security presented in December. The core idea was to trick a victim into completing a legitimate Microsoft login flow, often via the Azure CLI. The victim would then paste a localhost URL containing an OAuth authorization code. This code, once captured, allowed an attacker to obtain tokens and hijack accounts without needing a password or directly bypassing MFA at the login prompt. It's a token grab, not a password grab.
John Hammond then refined this with ConsentFix v2. He streamlined the phishing flow, replacing the manual copy/paste with a drag-and-drop of that localhost URL. This made the social engineering aspect even more effective.
Now, ConsentFix v3 is reportedly circulating on underground forums. This version automates the process further, specifically targeting Microsoft Azure environments. It maintains the abuse of the OAuth2 authorization code flow but focuses on first-party Microsoft applications that are already pre-trusted and pre-consented. This pre-existing trust is central to its effectiveness.
The Attack Chain: Pipedream, Cloudflare, and Implicit Trust
ConsentFix v3 operates through a precise, multi-stage attack chain:
First, attackers conduct reconnaissance. They verify an Azure presence by checking for valid tenant IDs. Then, they gather employee details—names, roles, email addresses—to personalize their impersonation attempts. This level of personalization is highly effective, often allowing campaigns to bypass generic spam filters.
Next, attackers establish their infrastructure. This involves creating multiple accounts across various services: Outlook, Tutanota, Cloudflare, DocSend, Hunter.io, and Pipedream. Each service plays a specific role in phishing, hosting, data gathering, and exfiltration.
Pipedream, a free serverless integration platform, serves as a central component. It acts as the webhook endpoint to receive the victim's authorization code. It's also the automation engine that immediately exchanges that code for a refresh token using Microsoft's API. Furthermore, it functions as the central collector, making captured tokens available to the attacker in real time. This level of automation significantly enhances v3's scalability, allowing attackers to process numerous compromises simultaneously.
The attacker then deploys a phishing page, often hosted on Cloudflare Pages, designed to look exactly like a legitimate Microsoft or Azure interface. They initiate a real Azure OAuth flow through Microsoft's login endpoint.
The victim interacts with this page, gets redirected to a localhost URL containing the OAuth authorization code, and is tricked into pasting or dragging that URL back into the phishing page. The moment this occurs, the phishing page sends the captured URL to the Pipedream webhook. The backend automation then immediately exchanges the authorization code for tokens.
To deliver the phishing link, attackers create highly personalized emails, often using the harvested employee data. They embed malicious links inside a PDF hosted on DocSend. This improves credibility and, crucially, bypasses many spam filters that might catch direct links.
Once the tokens are obtained, they are imported into Specter Portal. This allows the attacker to interact with the compromised Microsoft environment, accessing email, files, and other services permitted by the token. This enables a full takeover of the compromised Microsoft environment, bypassing traditional password-based authentication.
The Challenge of Implicit Trust
ConsentFix v3 is not just a novel phishing technique; it exposes a systemic challenge. The inherent, often unchangeable, trust placed in first-party applications like Azure CLI creates a fundamental blind spot. Microsoft designed these apps for convenience, pre-consenting them and allowing localhost redirects. Attackers are now exploiting these legitimate design choices.
This undermines the efficacy of layered defenses like MFA and Conditional Access from within the trusted perimeter. You might have Conditional Access policies that state, "Only allow access from compliant devices," but if an attacker has a valid token obtained through a trusted app flow, those policies can be circumvented. The token, by its nature, inherits this implicit trust.
Organizations relying on Azure face significant risk, as any user who falls for this phishing scheme can grant an attacker access to their resources, potentially leading to data exfiltration, further lateral movement, or even administrative control over cloud infrastructure, depending on the victim's permissions. This highlights the critical vulnerability of Azure OAuth abuse.
What We Can Do: Beyond Generic Advice
Mitigating ConsentFix v3 is complicated because the trust in first-party apps is architectural. Features like Family of Client IDs (FOCI), which let Microsoft applications share permissions and refresh tokens, are useful for user experience but also present a challenge here.
Some common mitigation advice, like "educate your users," often gets met with skepticism. And they're not entirely wrong. While user education remains important, technical controls that don't solely rely on perfect user behavior are increasingly necessary.
One crucial technical control involves implementing token binding to trusted devices. This can ensure a stolen token is only usable from its original device, adding a crucial layer of defense.
Beyond token binding, establishing robust behavioral detection rules is equally critical. Look for anomalous token usage: a token suddenly used from a new IP, a different geographical location, or to access previously untouched resources. This requires thorough logging and a Security Information and Event Management (SIEM) system capable of correlating these events.
Finally, applying app authentication restrictions offers another layer of defense. Consider restricting which users can consent to or use specific high-privilege first-party applications. This limits the blast radius. Review enterprise applications and their permissions: can user consent be disabled for certain apps entirely? Can specific users or groups be restricted from provisioning or using particular applications? Such granular control is essential to prevent ConsentFix v3 Azure OAuth attacks.
The Path Forward
ConsentFix v3 highlights a critical need for security models to adapt to how attackers exploit inherent trust. While the full extent of v3's deployment is still emerging, similar attacks are observed in active campaigns.
Reliance solely on traditional MFA or network perimeter defenses is insufficient when the attack originates from within the trusted authentication flow. We need to re-evaluate our 'trusted' application models, implement stronger behavioral analytics, and apply granular authentication restrictions wherever possible. The convenience of pre-consented first-party apps carries a significant security cost that warrants close examination.
