Blog

ConsentFix - The Newest Phishing Method Explained

May 18, 2026 / Jonas Mönnig

Since the beginning of the year, a phishing technique called ConsentFix has been making the rounds. It is pretty much the most absurd thing we have ever seen, but it is nevertheless being used by real attackers. We were able to test ConsentFix with our clients and can now explain not only how the technique works, but also what chances of success attackers have with it.

More and more organizations are using phishing-resistant authentication methods, such as passkeys, which means attackers are running into dead ends with traditional phishing techniques. That is why attackers are constantly looking for new techniques that can also succeed in particularly hardened systems. For example, so-called device code phishing has been popular for some time, where the device code flow of the OAuth 2.0 authorization protocol is abused. In response, many organizations have since disabled the device code flow in their Entra ID tenants.

In this constant back and forth between attackers and defenders, a new technique appeared at the beginning of the year and was named ConsentFix by security researchers. Just like with device code phishing, attackers intervene directly in the OAuth flow. To explain the attack, we therefore need to take a short step back and explain how a typical authorization process via OAuth 2.0 usually works.

The OAuth 2.0 Protocol Explained

Because the OAuth 2.0 standard is complex enough to fill ten blog articles, we will limit ourselves to the part that is relevant for the attack: the authorization of an application running locally on the user’s device, such as the Azure CLI, using the so-called authorization code flow.

Some readers may have noticed the use of the word “authorization” instead of “authentication”. This is not a coincidence, because authentication, meaning the verification of the user’s identity, is only a small part of the OAuth protocol. What actually happens here is that a user grants certain permissions to an application.

Using the graphic above, we will explain the protocol steps relevant to ConsentFix in a highly simplified way.

  1. The application starts the OAuth flow with a GET request to the OAuth server’s /authorize endpoint, which might look something like this:

    GET /authorize?client_id=04b07795-8...&redirect_uri=https://....

    We have left out the parameters that are irrelevant to the explanation for the sake of simplicity. The relevant ones for us are client_id and redirect_uri. The client_id is meant to uniquely identify the application to the OAuth provider, and the application must have been registered with the OAuth provider beforehand. The redirect_uri is the URI to which the authorization code will later be sent in step 4. For each client ID, there are fixed URIs that are allowed as values.

  2. The OAuth provider shows the user the login page.

  3. The user signs in. The authentication method (password, passkey, etc.) is irrelevant here.

  4. The OAuth provider sends the so-called authorization code to the client. This is not yet an access token, but must first be exchanged for one. The reason for this two-step process is that the application does not necessarily run on the user’s device.

    OAuth is mainly used in the context of web applications. In that case, the web application exchanges the authorization code for an access token. The web application must authenticate itself separately to the OAuth provider so that it is ensured that only this specific application can exchange the authorization code for an access token.

    In our example, where the application runs exclusively on the user’s device and therefore cannot keep an application password secret, the process is secured using PKCE. We have intentionally omitted this here.

    The authorization code is transmitted through a redirect to the URL specified as the redirect_uri in step 1. For a local application, this could look something like this:

    HTTP/1.1 302 Found
Location: http://localhost/callback?code=SplxlOBeZQQYbYS6WxSbIA

  5. The application can now use the received authorization code to request an access token, usually a JSON Web Token (JWT), from the OAuth server. It does this by submitting the code to the OAuth server’s /token endpoint.

  6. The application then receives a JWT from the server.

  7. The application can now use the JWT to access the resources for which it was authorized as part of the OAuth process.

ConsentFix Explained

We can now describe how attackers use the ConsentFix technique to intervene in this process and obtain access tokens. First, the user is shown a login page.

After clicking the “Sign in” button, the OAuth process starts in a new window. If the user is already signed in, they only have to select the correct account, as shown in the following screenshot.

This is also what makes this phishing technique so insidious. The user actually signs in on the real Microsoft login page and not on the phishing page itself.

From this point on, however, the attacker intervenes in the OAuth process, because the OAuth parameters are controlled by the attacker. As already described above, two of them are relevant for the phishing technique:

  • client_id: In our test, we used the client ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46, which is used by Microsoft’s own command-line tool Azure CLI. This client ID is already implicitly trusted in Entra ID because it is a Microsoft first-party application. In addition, it is not covered by existing Conditional Access policies by default, which means possible restrictions can be bypassed.

  • redirect_uri: Here, the attacker specifies http://localhost/. This is an allowed value for the client ID being used, but in this case it leads to an error because there is very likely no service running there on the victim’s machine.

The attacker now gets the user to copy the URL from the login window into the phishing page. In the variant we recreated for our phishing campaign, this is done through a drag-and-drop action. The URL contains the authorization code the attacker is interested in. The attacker can exchange this code for an access token at the OAuth provider and thereby obtain the user’s permissions.

POST /oauth/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=Qcb0Orv1v3&
client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46

ConsentFix in Practice

We were able to test ConsentFix with our clients as part of phishing campaigns and apply the technique to several hundred employees. Since there are no widely available tools for this yet, we had to quickly develop one ourselves. However, the effort required is manageable and can be reduced even further with AI-assisted development. The tooling is therefore relatively easy for real attackers to obtain.

So what chances of success does an attacker have with this technique, which appears very complicated at first glance? In our latest campaign, we saw the following result:

  • 99 employees clicked the link in the phishing email
  • 71 employees clicked Sign in on the phishing page and started the OAuth process
  • 12 employees copied a value into the phishing page
  • 6 times, an access token could actually be obtained with it (the user performed the action correctly)

After users clicked the link, we were therefore able to obtain a valid access token in roughly 6% of cases. In normal phishing campaigns, values between 50% and 80% are common. ConsentFix’s success rate is therefore roughly one tenth of that. However, it can also be used to steal access tokens from particularly hardened cloud tenants, and given the volume of phishing emails that cybercriminals send today, the chances of success are likely to be good.

It is therefore not surprising that this attack technique, absurd as it may seem at first glance, is also being used in the real world.

Conclusion and Mitigation Measures

ConsentFix is a novel phishing technique that seems absurd at first glance, but is nevertheless being used by cybercriminals. The success rate is significantly lower than with traditional password phishing, but it can still be used to obtain access to cloud tenants that exclusively use phishing-resistant authentication methods.

While the method is not yet very widespread at the current point in time, based on our test we consider it likely that it will gain popularity in the future.

As a first technical measure to protect against ConsentFix, access to first-party applications such as Azure CLI can be restricted in Entra ID. It is recommended to block these completely using Conditional Access policies and then only allow them for users who actually need them.