# ConsentFix v3: Automated OAuth Abuse Escalates Threats to Azure Environments


Cybersecurity researchers have identified ConsentFix v3, an evolving attack technique that combines OAuth abuse with automation to systematically compromise Azure cloud environments at scale. The attack builds on previous ConsentFix methodologies by automating the exploitation process, significantly reducing the technical barrier and increasing the potential impact for threat actors targeting enterprise organizations.


## The Threat


ConsentFix v3 represents a dangerous evolution in OAuth consent phishing attacks, a technique where adversaries trick users into granting malicious applications broad permissions within their Microsoft Azure/Microsoft 365 environments. Unlike earlier versions that relied on manual steps, v3 incorporates automation that allows threat actors to:


  • Systematically enumerate target organizations and identify users likely to grant permissions
  • Automate phishing email generation with credible-looking requests
  • Auto-harvest and monitor granted tokens without ongoing user interaction
  • Scale attack operations across hundreds or thousands of targets simultaneously
  • Persist long-term access by maintaining dormant OAuth tokens

  • The technique is reportedly circulating on underground hacker forums and dark web communities, with evidence suggesting active development and refinement by multiple threat actor groups.


    ## Background and Context


    ### Understanding OAuth and Consent Attacks


    OAuth 2.0 is a widely-adopted authorization protocol that allows users to grant third-party applications access to their cloud accounts without sharing passwords. When a user grants permission, they receive an access token—a credential that allows the application to act on their behalf.


    Legitimate use cases abound: integrating project management tools with email, connecting analytics platforms to cloud storage, or authorizing mobile apps to sync calendar data. However, this same mechanism can be abused.


    Consent phishing exploits the trust users place in familiar-looking permission screens. An attacker crafts a malicious application registered in Azure's app ecosystem, then uses social engineering to convince users that granting permissions is necessary—whether through:

  • Impersonated IT support emails
  • Fake security alerts
  • Compromised legitimate email accounts
  • Executive impersonation (CEO fraud-style)

  • Once consent is granted, the attacker receives an OAuth token with whatever permissions the user approved—potentially including:

  • Full mailbox access
  • Ability to read all files in OneDrive/SharePoint
  • Delegation rights to perform actions on behalf of the user
  • Access to sensitive business data

  • ### Evolution from ConsentFix v1 and v2


    The ConsentFix family of attacks emerged several years ago with:


    | Version | Key Feature | Limitation |

    |---------|-------------|-----------|

    | v1/v2 | Manual phishing campaigns targeting specific users | Operator-intensive; low scale |

    | v3 | Automated targeting, token harvesting, and persistence | Significantly higher impact potential |


    Earlier versions required threat actors to manually craft emails, manage target lists, and monitor which victims had granted permissions. This made the attacks labor-intensive and relatively limited in scope.


    ## Technical Details


    ### How ConsentFix v3 Works


    Phase 1: Reconnaissance and Targeting

  • Threat actors register seemingly legitimate applications in Azure's app registration portal (accessible to anyone with a Microsoft account)
  • They acquire target email lists through data breaches, OSINT, or LinkedIn scraping
  • Automated tools identify which targets work at organizations likely to have valuable cloud assets

  • Phase 2: Automated Phishing

  • Mass phishing emails are generated using templates that mimic legitimate vendor communications or internal IT notices
  • The emails contain links to the attacker's malicious OAuth consent screen
  • Unlike traditional malware attachments, these links don't trigger most email security controls because they point to Microsoft's legitimate OAuth infrastructure

  • Phase 3: Token Harvesting

  • When a user clicks the link and grants permission, Azure issues an OAuth access token directly to the attacker
  • Automated systems immediately capture and validate the token
  • The system records which permissions were granted (some users may grant less than requested)

  • Phase 4: Stealth and Persistence

  • Rather than immediately exfiltrating data, sophisticated threat actors may sit dormant, observing and planning
  • They can monitor when the user is likely to be offline, then quietly access email, files, or sensitive applications
  • The granted application appears legitimate in the user's OAuth consent list, often overlooked during security audits
  • Tokens typically remain valid until explicitly revoked—potentially for months or years

  • Automation Framework

    The v3 variant incorporates:

  • Machine learning-based targeting to identify high-value users (executives, IT staff, finance teams)
  • Dynamic email generation that varies phishing content to evade email filters
  • Automated consent screen customization requesting only the minimum permissions needed for each target
  • Real-time token validation and monitoring dashboards accessible via the dark web

  • ## Implications for Organizations


    ### Immediate Risks


    Organizations running Azure or Microsoft 365 face several critical concerns:


  • Compromised email access: Attackers can read sensitive communications, including contracts, financial data, and strategic information
  • Data exfiltration: All files accessible to the compromised user can be silently downloaded
  • Privilege escalation: Compromised administrative accounts can grant broader access or create backdoor accounts
  • Lateral movement: Tokens can be used to move from cloud services into connected on-premises infrastructure
  • Regulatory exposure: Unauthorized data access may trigger HIPAA, GDPR, CCPA, or SOX compliance violations

  • ### Detection Challenges


    ConsentFix v3's reliance on legitimate OAuth infrastructure creates detection blindspots:


  • Legitimate appearance: The attack uses Microsoft's own consent screens—nothing looks malicious
  • No malware indicators: Traditional endpoint detection and response (EDR) tools don't flag OAuth tokens
  • Audit trail gaps: Many organizations don't actively monitor their OAuth app registrations
  • User behavior mimicry: Legitimate cloud usage looks identical to unauthorized access

  • ### Scope and Scale


    Early intelligence suggests active campaigns targeting:

  • Financial services firms (high-value data, account access)
  • Legal and professional services (confidential client data)
  • Healthcare organizations (HIPAA data, patient records)
  • Technology companies (intellectual property, source code access)
  • Government contractors (classified or sensitive unclassified information)

  • ## Recommendations


    ### Immediate Actions


    For IT Security Teams:


    1. Audit OAuth app registrations immediately

    - Review all apps with admin consent in Azure portal

    - Identify apps installed in the last 90 days

    - Check for suspicious app names or permissions


    2. Revoke suspicious tokens

    - In Azure AD, disable risky sign-ins and sessions

    - Force password resets for accounts showing OAuth grants to unfamiliar applications


    3. Enable conditional access policies

    - Require additional verification for apps requesting elevated permissions

    - Block legacy authentication protocols

    - Implement risk-based sign-in detection


    4. Deploy email security controls

    - Configure URL rewriting to warn users before OAuth consent screens

    - Block emails containing OAuth authorization URLs from untrusted domains

    - Train users to verify sender identity before granting permissions


    For End Users:


  • Review your Microsoft account's connected apps regularly (account.microsoft.com/permissions)
  • Never grant permissions to applications you don't actively use
  • Verify that permission requests come from legitimate sources
  • Be skeptical of unexpected "verify your account" or "confirm access" emails

  • ### Long-Term Hardening


  • Implement Zero Trust principles: Assume compromised credentials; verify every access request
  • Use application-level controls: Restrict what data specific apps can access (principle of least privilege)
  • Enable Azure AD sign-in risk detection to flag impossible travel, unusual locations, or bulk data access
  • Conduct regular security awareness training on OAuth phishing and social engineering
  • Maintain an updated inventory of all cloud services and integrated applications
  • Establish incident response playbooks for OAuth compromise scenarios

  • ### Monitoring and Detection


    Organizations should monitor for:

  • Unusual OAuth app registrations by standard users
  • Sign-ins from unfamiliar locations or outside business hours
  • Bulk email or file downloads via OAuth-authenticated apps
  • Changes to OAuth permissions or delegated administrative rights

  • ## Conclusion


    ConsentFix v3 demonstrates how threat actors continuously evolve cloud-specific attack techniques to maintain effectiveness at scale. By automating what were once labor-intensive phishing campaigns, the attack significantly lowers the barrier to entry for threat actors while exponentially increasing the risk to enterprise organizations.


    The attack's success hinges on a fundamental challenge: OAuth consent screens are designed to be transparent and user-friendly, making it difficult to distinguish legitimate requests from phishing without behavioral context. Organizations must assume that some users will be compromised and implement defense-in-depth strategies that detect and limit the damage of successful OAuth abuse attacks.


    Security teams should prioritize OAuth hygiene and monitoring alongside traditional endpoint security—the next breach may come not through malware, but through a permission screen that looked legitimate.