Authorization phishing: why attackers stopped targeting the login

For most of phishing's history, the objective was simple: steal the credential. Whether through a fake login page twenty years ago or through an attacker in the middle (AiTM) reverse proxy today, the entire attack chain has been oriented around defeating authentication. So defenders have focused on making the login harder to compromise.

This investment is starting to pay off. While MFA as a blanket control is routinely defeated by AiTM attacks (the default phishing method today), phishing-resistant passkeys are used in a relatively small number of logins, but growing steadily each year. And core identity platforms are taking steps to make them the default method. For example, Microsoft is making passkeys the default sign-in method for Entra ID from September 2026, and users stuck on SMS or voice authentication will be force-migrated. 

AiTM phishing kits remain dominant, but the detection surface is improving — behavioral detections now catch the kit's page behavior regardless of the domain it's hosted on. Authentication controls are genuinely getting harder to beat (though even with passkeys, not impossible, as shown in downgrade attacks — shown in the video below).

So it makes sense that attackers are looking for alternatives. In 2026, we’ve seen device code phishing explode into mainstream adoption, with 30+ distinct kits now offering the technique (this number jumps every time we write a new update). 

Device code phishing sees the attacker target the authorization layer instead — OAuth consent flows that operate after authentication has already succeeded. We're calling this class of attack authorization phishing, and it represents a structural shift in how identity attacks work.

But device code phishing is one technique in a broader shift. ConsentFix, first discovered by Push in December 2025, has already been commoditized into criminal tooling. 

Authentication phishing vs. authorization phishing

Authentication phishing targets the login — the moment a user proves their identity. AiTM reverse-proxy kits like Tycoon2FA and Sneaky2FA relay credentials and session tokens in real time, effectively defeating MFA by capturing the authenticated session as it's created. This has been the dominant phishing technique since roughly 2023, and it remains the most common attack we come up against in the wild.

Authorization phishing targets what happens after the login. Instead of stealing a session from the authentication flow, these attacks abuse OAuth authorization mechanisms — consent grants, device code flows, and token exchanges. The attacker never touches the authentication flow at all.

Consent phishing: the classic OAuth attack

Consent phishing is the oldest of the three, and the classic OAuth attack. The attacker creates a malicious third-party application and tricks the user into granting it permissions via an OAuth consent prompt. The app then uses those permissions to access the user's data via API.

Identity providers have substantially hardened their default configurations against consent phishing. Most platforms today do not allow users to consent to apps that have not already been admin-consented into the tenant. For example, Microsoft now blocks unverified third-party app consent by default, as does Google, and GitHub restricts OAuth apps to org-owner approval. 

Device code phishing: the breakout threat of 2026

Device code phishing targets a different OAuth flow entirely: the RFC 8628 device authorization grant, originally designed for input-constrained devices like smart TVs and IoT hardware. The attacker generates a code, delivers it to the victim via a phishing page that auto-polls for a fresh code on page load (which can arrive over email, Teams messages, LinkedIn DMs, voice calls, malvertising, or compromised websites), and the victim enters the code on the real device code for the target app. In the wild this is usually Microsoft, but last year's ShinyHunters campaign saw Salesforce targeted too.

This grants the attacker an access token scoped to whichever application was targeted, and critically, because device code phishing targets apps that are already consented in the user's tenant (usually first-party Microsoft apps), it sidesteps the consent restrictions that have made traditional consent phishing harder. 

In Microsoft environments, the impact can extend beyond API access — if the attacker targets the Microsoft Authentication Broker, they can register a virtual device against the victim's account and escalate to a full Primary Refresh Token, gaining an interactive SSO-enabled session that can laterally move across any SSO-joined application.

ConsentFix: the new ClickFix-OAuth hybrid

ConsentFix occupies an interesting middle ground. It targets the same OAuth flow as consent phishing — the authorization code grant (RFC 6749) — but it targets pre-approved first-party apps rather than attacker-created third-party apps, which means the consent restrictions that shut down traditional consent phishing don't apply.

First observed in Russia-linked APT29 campaigns in late 2025, the original attacks appeared on compromised websites and were tightly targeted — the attack only activated for specific email domains, allowing non-targets to use the site as normal. ConsentFix combines ClickFix-style clipboard injection with OAuth consent abuse, exploiting apps that use a localhost redirect URI as part of the handshake to capture authorization codes that are usually picked up by a server-side callback.

Push detected and blocked ConsentFix the first time it was seen in the wild, and within months of disclosure, a criminal ConsentFix toolkit appeared on the XSS forum, making the technique more widely available.

What defenders think works (and what actually does)

As we've already established, authentication controls like passkeys have no impact on these attacks, which can come as a surprise for those that have bought into the "phishing-resistant" tag of passkeys at face value. That isn't to diminish their value, the passkey isn't phished in this scenario, it's just being circumvented.

Passkeys remain the strongest available protection against AiTM and credential theft. But they address a different layer of the problem, and treating them as a complete answer to phishing creates a dangerous blind spot as attackers shift to authorization-layer techniques.

Evaluating post-authentication controls like Conditional Access Policies

Conditional access policies are the primary layer of defense cited against these authorization-layer attacks. We tested the most cited conditional access controls against both device code phishing and ConsentFix, and the results vary significantly.

Since the policy for require phishing-resistant authentication pertains to the enforcement of passkey-based logins, this has no impact here as we discussed above.

Block device code flow is the most direct control, and it works — but only against device code phishing, not ConsentFix. It also blocks legitimate device code use cases (Azure CLI, conference room hardware, developer tooling), so organizations with real device code dependencies need per-user group or per-app exceptions that create potential gaps.

Require compliant device is the most effective broad control. Device code flows can't present the TPM-bound proof-of-possession that device compliance requires, so they're blocked outright. However, as above, if you have legitimate uses for device code logins in your environment, you’d need to implement exceptions to this policy. 

ConsentFix, on the other hand, passes through this check. BYOD scenarios also create gaps — personal devices authenticating via browser without a Primary Refresh Token won't satisfy the compliance requirement either, for legitimate and malicious flows alike.

Token protection, currently in preview, binds refresh tokens to the device's TPM. It performed better in testing than expected for some ConsentFix scenarios — depending on the scopes requested and the target app — but it doesn't apply to all apps and resources.

Conditional access can be tricky to manage, however, particularly for larger organizations. User groups need maintaining, new apps need scoping, exceptions accumulate, and policies interact in ways that aren't always obvious from the admin console. It's easy to accidentally leave policies in report-only mode (I found this myself during testing) or create exceptions for specific apps that inadvertently open the authorization attack surface. And ticking the box doesn't tell you whether it works in practice.

Microsoft is taking additional steps to reduce the attack surface here — device code flow is blocked by default in new tenants, and they appear to be locking down apps and reply URLs to reduce the ConsentFix attack surface, including adding explicit "this might be a phishing attack" warnings on certain reply URLs used in ConsentFix scenarios. But the gap between a default deployment and a hardened one remains wide.

What about blocking the apps themselves?

The challenge is that the apps being abused aren't malicious — they're legitimate first-party Microsoft applications like Azure CLI, Microsoft Office, and Teams. They exist in every Entra tenant by default, are pre-consented with broad permissions, and can't simply be removed.

An admin can toggle "assignment required" on a service principal and restrict which users can authenticate through that app, but that means pre-creating and managing user assignments for every first-party app that could be targeted. Over-restricting broadly used apps like Teams or Office may break core workflows.

The future of authorization phishing

Several developments will determine how fast this category matures. Device code phishing is a core technique now, supported by most PhaaS vendors and bolted onto AiTM kits. ConsentFix criminal adoption is still early but could follow suit at any time. 

Non-Microsoft targets are the logical next step — device code phishing has already been demonstrated against Salesforce, and I showed off GitHub targeting in my recent webinar. Any platform that supports the authorization code grant with localhost redirect or the device authorization grant is a potential target. 

But OAuth is complex, and the authorization mechanisms that have been abused so far likely don't represent the full attack surface. Everything discussed so far has been initial access, but OAuth is also powerful at the persistence and lateral movement layers — an attacker who plants a malicious OAuth grant during a compromise has a stealthy persistence mechanism that survives credential resets and password changes, and can be extremely difficult to detect. As authorization phishing matures, we expect these post-compromise OAuth techniques to become more common too.

The poisoned tenant attack surface also remains largely undefended, which could see more typical consent phishing come back around. Historically, consent phishing involved an attacker creating a malicious app and inviting their targets to it. But you can just set up a tenant on a legit SaaS app and use that instead.

Most SaaS platforms let anyone create a workspace impersonating any organization, and few offer controls for admins to restrict which tenants their employees can join. We recently experienced this directly when an attacker created a fake OpenAI organization under our company's name and invited specific employees to join it.

What defenders should actually do

First, test your defenses against authorization attacks specifically. Don't assume that MFA, passkeys, or conditional access policies handle this. Run a device code phishing simulation against your environment and verify that your conditional access configuration actually blocks it. Test ConsentFix scenarios. If your controls rely on configuration assumptions you haven't validated, you have a gap.

Second, don't treat this as exclusively a Microsoft problem. Device code phishing can work against several apps. GitHub exposes broad scopes including full repository access and uses device code as the default CLI sign-in method — meaning developers encounter legitimate device code flows routinely, making phishing lures harder to distinguish from normal workflow. ConsentFix-style attacks targeting authorization code grants with localhost redirects could also expand beyond Microsoft as the technique matures.

Third, update your security awareness training. Most employees have no concept of authorization phishing — it doesn't look or feel like any phishing that they're used to. There's no suspicious login page, no credential entry on an unfamiliar domain. Traditional awareness training does not prepare users for this.

But to detect and block these attacks as they happen, you need to be in the browser. Push detects and blocks authorization attacks in real time, when the user is tricked into performing the malicious consent grant. We detected ConsentFix the first time it appeared in the wild, before any other vendor, and device code phishing detection has been live since the technique first entered mainstream use.

Watch the research

I recently talked about authorization phishing at BSides Las Vegas 2026, walking through live demonstrations of device code phishing (including against passkey-protected accounts), ConsentFix, and conditional access policy bypass testing. The full talk is available to watch on YouTube (starts at 27:12).