ConsentFix v3 the tactic that steals tokens taking advantage of the pregranted trust in OAuth

A new attack vector known in forums such as ConsentFix v3 is showing a recurring weakness in architectures that trust OAuth flows: it is not always the password or MFA that determines security, but how and to whom trust is granted. Unlike traditional phishing attacks, ConsentFix v3 automates and scale a technique that takes advantage of OAuth2's clearance flow to get valid tokens through Microsoft applications that are already pre-approved or within the tenant's set of confidence applications.

The technical innovation of this variant is not a new cryptographic explosion, but the combination of social engineering with public cloud tools to orchestrate the campaign: phishing pages served from Cloudflare Pages that start a legitimate Microsoft login, readdresses to a localhost containing the authorization code and an automated pipe that captures that code and immediately exchanges it by tokens using serverless platforms like Pipedream. The result is an exfiltration of tokens-based credentials that can remove controls like MFA, because the authorization is made by the user himself in an apparently legitimate flow.

Beyond punctual technique, the background problem is architectural. Microsoft and other modern clouds use "first of the house" (first-party) applications and mechanisms such as Family of Client IDs (FOI) that facilitate user experience but also create an attack surface: when an authorized client shares permissions and refresh tokens, compromising an authorized flow can give access to multiple resources without asking for frequent reauthentication. Security teams must understand that the desirability of pregranted confidence increases the risk of abuse on a scale. In order to further identify the families of Microsoft customers, public research can be found in GitHub: Family of Client IDs.

The practical effects of a valid tokens intrusion range from the theft of mail and files to the use of automated permits to move laterally in the tenant. In reported campaigns, attackers combine advanced social engineering - custom mails, PDFs hosted in legitimate services such as DocSend - with automation to reduce the time between the victim "authorizes" and the effective obtaining of the refresh token. Integration platforms such as Pipedream are used as webhook, code exchange engine and tokens collector in real time; in other cases captured tokens are imported to control panels for further exploration (e.g. Specter or other tokens abuse tools).

What can security teams do right away? First, recognizing that effective mitigation requires policy changes and detection, not just awareness-raising. Block or restrict user-level application consent reduce the surface: force new applications to require administrative consent, limit the use of pre-approved applications and regularly review applications with high permits. Implementing Conditional Access policies that require managed devices or sessions with risk-bound tokens can raise the cost of automated operation.

Second, improve telemetry and detection. Auditing OAuth events (code issue, tokens code exchange, refresh tokens issue) and creating behavior rules to detect atypical patterns - for example, code exchange from locations or unusual agents, or immediate exchange from external domains - allows you to respond faster. Complementing with the infrastructure block used in campaigns (phishing page hosts, recurrently used webhook endpoints) can help to interrupt automation.

Third, specific technical measures to be reviewed: limit the length and duration of refresh tokens, establish more aggressive expiry policies, enable implementation restrictions (which apps may request certain scopes) and evaluate the use of "token binding" or token binding mechanisms to reliable devices where they are available. There is no single silver bullet: effective defence combines prevention of excessive consent, control of the authentication environment and detection of behaviour. To better understand the authorisation flow and the points where the detection is to be activated, Microsoft's documentation on the authorisation flow is a useful reference: OAuth 2.0 authorisation code flow (Microsoft).

No less important is the training of staff with a focus on specific techniques used for these attacks. Teach to recognize strange interactions that ask to paste or drag URLs that point to localhost, and establish operational rules in which you never accept to paste redirection chains out of verified contexts, reduces the effectiveness of the social trick that supports ConsentFix.

Finally, response teams should prepare playbooks for quick tokens revocation and session blocking when they detect signs of abuse. As a reminder, the presence of a technique in forums does not imply its immediate mass adoption, but the automation proposed by ConsentFix v3 makes the entry barrier low and therefore the risk of escalation real. The combination of stricter consent policies, focused telemetry and risk-based access controls is the most effective line of defence against these attacks today.

To audit dependencies and exposure points to these techniques, to review applications with high permissions and external integrations is a priority task that complements the operational response and reduces the likelihood that a single committed authorisation code will become a domain of sustained attacks.