The FBI's Kali365 Warning Is Not a Phishing-Resistance Problem. Here's Why That Matters.

When the FBI issued its alert about Kali365, the headline most people took away was "AI-powered phishing kit bypasses MFA." That framing is technically true and almost completely unhelpful, because it points defenders at the wrong fix. The instinct, reasonable enough, is to reach for stronger authentication: hardware security keys, FIDO2, passwordless. If MFA is being bypassed, surely better MFA is the answer.

It isn't. And understanding why is the whole point.

We build phishing-resistant authentication for a living, so we want to be precise about something that sounds counterintuitive: the strongest possible login would not have stopped this attack. Not a FIDO2 security key, not a passkey, not Circle Access. Kali365 doesn't attack the login. It attacks what happens after a perfectly legitimate one.

What Kali365 Actually Does

Kali365 is a phishing-as-a-service platform, first observed in April 2026 and sold through Telegram. What makes it different from a decade of phishing kits is the mechanism. It doesn't steal passwords and it doesn't intercept MFA codes. It abuses a legitimate feature of OAuth 2.0 called the device authorization grant, better known as device code flow.

Device code flow exists for a good reason. It lets you sign into something on a device that has no keyboard or browser: a smart TV, a conference-room display, a printer, an IoT terminal. The device shows you a short code, you go to a normal login page on your phone or laptop, you type the code in, you authenticate as usual, and the original device is now signed in. Convenient and, in its intended use, fine.

Here is how Kali365 turns that against you, per the FBI's advisory:

1. Lure. The attacker sends a phishing email impersonating a trusted service, like a DocuSign request, a SharePoint share, or a OneDrive alert. The email contains a device code and tells you to go enter it at Microsoft's real verification page.


2. Authorization. You navigate to the genuine Microsoft page (microsoft.com/devicelogin, the real one) and paste in the code. In doing so, you unknowingly authorize the attacker's device to access your account.


3. Token theft. The attacker, who initiated the device code flow on their end, receives the OAuth access and refresh tokens that result from your login.


4. Persistence. They now reach Outlook, Teams, and OneDrive without a password and without completing any further MFA challenge, and the refresh token lets them stay there.

Read step 2 again, because it is the entire story. You are not on a fake site. You are not handing your credentials to a proxy. You are on Microsoft's legitimate page, authenticating with your real account, and the attack still works, because the thing you are being tricked into doing is not logging in, it's granting consent for someone else's device.

Why "Stronger Authentication" Misses the Target

This is where the popular framing leads people astray. The reflex is to treat "MFA was bypassed" as a signal that the authenticator was too weak. So the proposed cure is a stronger one.

But look at where each authentication method does its work.

A FIDO2 security key (or a passkey, or any origin-bound credential) protects the authentication event. Its superpower is that it cryptographically binds your login to the real domain, so a credential meant for login.microsoftonline.com is useless on an attacker's lookalike site. That defeats adversary-in-the-middle phishing, where the victim is lured onto a fake page. It is a genuinely important defense, and it is the right tool for that problem.

It does nothing here. In a device code attack the victim is on the real domain, authenticating legitimately, with whatever strength of factor you like. The origin binding is satisfied because the origin is genuine. The security key signs the real challenge for the real site and the login succeeds, exactly as designed. The weakness was never in proving who you are. It was in the separate act of consenting to authorize a device, and that act sits downstream of authentication entirely.

We'll say this plainly even though it's our own product: Circle Access wouldn't have stopped this either. Circle Access defends its own authentication and authorization flow: out-of-band QR signing, a server-pinned return URL, signatures an attacker can't relay. Circle Access does not insert itself into Microsoft's device code consent step. A user who authenticates to Microsoft beautifully and then pastes an attacker's device code into Microsoft's real page has bypassed nothing in their authentication. They've misused a consent flow that lives on Microsoft's side. Strong authentication is a precondition that was met, not a gate that failed.

This is the same category of risk as post-authentication session hijacking, where an attacker lifts a live session token after a legitimate login. In both cases the login is sound; the abuse happens after it. No authenticator, however strong, claims to govern what a legitimately authenticated session is then used to authorize. Pretending otherwise is how security promises get embarrassed.

What Actually Stops It

If the fix isn't stronger authentication, what is it? The honest answer is that this is a policy and consent-governance problem, and the controls that address it are unglamorous. The FBI's own mitigations point straight at the mechanism rather than the login:

• Restrict or block device code flow. Most organizations don't actually need it. The FBI recommends a conditional access policy that blocks device code flow for all users, with narrow exceptions for the genuine business processes that depend on it. If the flow can't be abused, the attack has nowhere to land.


• Audit existing device code usage first. Before you block it, find out who legitimately relies on it, like the conference rooms, the kiosks, and the IoT devices, so you carve out exceptions deliberately instead of breaking things and rolling back.


• Block authentication-transfer policies. These let a session migrate from a computer to a mobile device; the FBI calls out disabling them to close a related path.


• Exclude emergency access accounts from blanket restrictions so a tightened policy doesn't lock you out of your own tenant.


• Monitor for the signature of the attack. Device code authentications from unexpected locations, new devices appearing on accounts, and anomalous token activity are the telltales. The interesting events here happen after a successful sign-in, so detection has to watch what authenticated sessions do, not just whether authentication occurred.

Notice what every one of these has in common: they operate on the consent and authorization layer, not the credential layer. They reduce the attacker's opportunity to abuse a legitimate flow, and they catch the abuse when it happens. That is the correct axis for this threat.

The Lesson Worth Keeping

Kali365 is a useful reminder that "bypasses MFA" is a description of an outcome, not a diagnosis of a cause. Attackers are increasingly moving past the moment of authentication and going after everything that surrounds it: the tokens it mints, the sessions it creates, the consent flows it enables. Those are different surfaces with different defenses.

Phishing-resistant authentication remains one of the most valuable upgrades an organization can make. It shuts the door on credential phishing and adversary-in-the-middle attacks, which are still the most common way accounts get taken over. We'd recommend it without hesitation. But it's a tool with a specific job, and the mark of taking security seriously is knowing the job it doesn't do.

For device code phishing, the answer isn't a better key. It's governing the flow that's being abused: restricting device code authorization, watching what authenticated sessions go on to do, and treating consent as a thing that deserves the same scrutiny as the login that precedes it.