Part of the ongoing Big Tech's War on Users series.

The FBI issued a warning last week about a phishing-as-a-service platform called Kali365 that can completely bypass multi-factor authentication on Microsoft 365 accounts. Not by breaking MFA. By going around it entirely — using a legitimate Microsoft feature against you.

Before I get into how, let me set the stage on why this one stings more than the average security story.

Look, the whole industry has been on a years-long MFA crusade. Your bank, your gaming platform, random retail apps, services where the actual threat model doesn't come close to justifying the friction. Everything and its mother is pushing MFA now, and increasingly pushing passwordless on top of that — something I've already gone into at length — sometimes for accounts that contain nothing worth stealing, because some product manager needed to hit a security compliance checkbox. The nagging is universal at this point.

But Microsoft took it further than most. What started as relentless messaging — "90% of breaches could be prevented with MFA," enable it or you're irresponsible, here's a security score that tanks if you don't comply — eventually became something closer to a mandate. Conditional Access policies block sign-in entirely without it. Baseline protection policies enforce it at the platform level regardless of what your tenant settings say. For a lot of users and admins, MFA isn't a choice anymore — Microsoft decided for you. That's the part that makes what comes next particularly galling.

So users did the responsible thing. They complied. They enabled MFA. They followed the guidance from the platform they pay enterprise prices to trust.

And now there's a phishing-as-a-service platform selling access to exactly those "protected" accounts on the dark web— I mean Telegram, for $250 a month.

How It Works

The attack exploits something called device code authentication — a flow Microsoft built for hardware with limited input capability, think smart TVs and streaming sticks, things that can't easily handle a full login form. The flow generates a short code that you enter on a real Microsoft website to authenticate the device. Legitimate. Intentional. And now completely weaponized.

Attackers kick off the authentication process themselves, then use phishing or social engineering to get you to enter the code on a real, legitimate Microsoft page. No fake login. No sketchy redirect you might catch if you're paying attention. You're authenticating on Microsoft's actual infrastructure. Once you do, Microsoft hands the attacker an access token and they're in — no MFA challenge for them to solve, because you already solved it for them.

There's a second attack path too: browser cookie hijacking that routes your session through attacker-controlled infrastructure while transparently proxying the real Microsoft login. You see Microsoft's site. Everything looks correct. Nothing looks wrong because nothing on your end is wrong.

Once they're in, they have the run of the place — OneDrive files, Outlook email, connected services like Salesforce. They can register new devices. They can set up custom inbox rules to hide their activity and silently bury Microsoft's own security alerts. This isn't smash-and-grab; it's quiet, persistent access.

Security researchers at Arctic Wolf documented the Kali365 campaign in April. They noted part of its danger is sheer ease of use — AI-generated phishing lures, templates, victim tracking dashboards. The FBI's notice confirms that even "less-technical" attackers can run this effectively. It's a full subscription business: admins, resellers, affiliates, custom branding per tenant. Kali365 isn't even alone — similar services like EvilTokens and Tycoon2FA are running the same playbook, and device code phishing was already being used at scale by nation-state actors as far back as September 2025 before the criminal groups caught up.

The FBI's recommended defense for individual users? Watch your email subject lines. Kali365 relies on a set of fixed phishing templates with recognizable patterns — fake SharePoint shares, OneDrive notifications, Teams messages, DocuSign requests, invoice alerts.

But before we even get to subject lines, here's the most useful thing I can tell you that most security writeups gloss over: if you didn't do anything to prompt it, ignore it. Microsoft, your bank, DocuSign, SharePoint — none of these services are going to randomly email you out of the blue asking you to authenticate something. If you didn't just try to log in, didn't just share a file, didn't just sign a document — and suddenly there's an urgent notification in your inbox asking you to enter a code or click a link? That's your sign. Don't engage. Report it as phishing and move on.

This Isn't a New Attack. It's a Legacy Problem.

Here's the thing about device code authentication: it's old. Not ancient, but old enough that the industry largely moved on from it. The reason you don't see most services asking you to type a code into a website anymore is because they graduated to push notifications, QR codes you scan with an already-authenticated device, and passkeys. The "type this code on a website" model has an inherent social engineering vulnerability — the code is human-entered, which means it's human-manipulable. The industry figured that out and moved on.

Microsoft didn't retire it. They left it running in 365 — their enterprise flagship, the product businesses cannot easily leave — while loudly marketing MFA and, if your account qualifies, passkeys as the security answer.

And look, I've written at length about why passkeys aren't the clean answer the industry pretends they are. Theoretically, passkeys solve the device code problem — a passkey is cryptographically bound to the legitimate domain, so it can't be replayed through attacker infrastructure. In practice, Microsoft's passkey implementation is a mess. Half the time it works on web. Try it on a device and it actively fails — attempts, fails, tries again, fails again, and eventually you're left either retrying the same broken flow or hunting through buried menus trying to find the fallback password option they've deliberately obscured because they'd rather you not use it.

That post basically predicted this without knowing it was predicting it. The pattern is the same: mandate the new thing, implement it badly, leave the old vulnerable thing running underneath it, and let the user absorb the consequences when it breaks.

And here's the part that really crystallizes how broken this is. Microsoft didn't just implement passkeys badly — they walled them off. Rather than implementing the open FIDO2 standard cleanly — and let's be honest, Apple and Google have their own walled garden passkey tendencies — Microsoft took it further by tying their implementation to a specific stack: Windows Hello hardware, Entra ID joined or registered devices, minimum Windows versions, domain controllers running Server 2016 or later with specific patches, and Conditional Access policies explicitly configured to permit it. Support for personal and unmanaged devices that aren't Entra joined is only rolling out right now — years after the passwordless push began. MFA worked on basically anything that could run a browser or an authenticator app. The thing they're replacing it with requires a qualifying device, the right account tier, the right OS version, and an admin who knows which policy toggle to find. They mandated the direction before the destination existed for most of their users.

The Xbox Footnote That Makes This Worse

Xbox authentication is a useful window into how this actually broke across Microsoft's product line. The app-based MFA approval flow on Xbox — where you'd get a prompt on your phone, approve it, done — worked fine. It wasn't fancy but it was solid and it did what it was supposed to do.

Then Microsoft rolled passkey support into Microsoft Entra, their centralized identity platform that every product calls back to for authentication. And this is my read on what happened — I can't confirm the internals — but it fits the pattern almost perfectly: the Entra team shipped passkey support at the platform level, every product that depends on Entra for auth picked it up whether the individual product teams were ready or not, and nobody fully tested what that would do to existing working flows downstream.

The result, confirmed across multiple user reports and Microsoft's own support documentation, is that Xbox auth is now in the same hell as everything else. Phone shows "You're now signed in to Xbox. You can now safely close this window." Console sits there. Nothing happens. Microsoft's support docs confirm "Xbox consoles currently have limited support for passwordless sign-in using passkeys." The official recommended fix? Temporarily disable passwordless sign-in, add a password back, use that to get into the console, then re-enable passwordless. The fix for the broken passkey implementation is to undo the passkey implementation. Nobody re-enables it.

This is what makes it worse than siloed incompetence. It's one broken centralized implementation radiating dysfunction outward to every product simultaneously. Xbox, 365, Windows Hello — all calling the same underlying system, all picking up the same half-baked passkey support, all leaving users in the same place. Different product, same broken platform underneath, same outcome.

They had something working. The platform modernization initiative broke it. And the device code vulnerability in 365 is still sitting there underneath all of it.

The Implicit Contract

The promise, when Microsoft mandated MFA, was simple. You do your part, we do ours. Comply with the security requirement, get the security benefit.

Users held up their end. They enabled MFA. They followed the guidance. They pay the subscription fees.

Microsoft left a legacy authentication flow running that renders the whole stack bypassable. They've known the device code pattern is a social engineering risk — it's not obscure, and it was being actively exploited at scale for months before Kali365 even launched. The "fix" is disabling device code flows in Conditional Access policies. Here's what that actually involves — and why most individual users and small business admins will never get there:

1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator
2. Browse to Protection → Conditional Access → Policies
3. Select New policy
4. Under Assignments → Users or workload identities → Include: All users
5. Under Exclude: add your emergency access accounts
6. Under Target resources → Include: All resources
7. Under Conditions → Authentication Flows → set Configure to Yes → select Device code flow → Done
8. Under Access controls → Grant: select Block access
9. Set Enable policy to Report-only first to audit impact, then switch to On

If you made it to step 9 without your eyes glazing over, congratulations — you're ahead of most. Now do that for every tenant you manage. And notably there's no GPO for it — Group Policy being Microsoft's standard mechanism for exactly this kind of administrative control, the thing admins already know, already use, already expect. Instead it's nine steps through the Entra admin center that most admins outside large enterprise environments will never touch.

And here's the kicker: Microsoft actually started rolling out a managed Conditional Access policy to block device code flow back in February 2025 — over a year ago. It shipped in report-only mode by default, and it only covered fourteen highly privileged admin roles. Not regular users. Not your staff. The admins. Meanwhile Kali365 targets everyone.

That's not a security posture. That's the cost of the breach landing on you instead of them.

It's the same dynamic I keep documenting across this series — the passkey nightmare, the GitHub security failures, the same leopard, same spots. The incentive to actually fix the foundation isn't there when the lock-in is already complete. Engineering time costs money. Enterprise customer complaints during a transition cost more. The cost of leaving the vulnerability open lands on users. The cost of closing it lands on the quarterly numbers. In most boardrooms that's not even a hard decision.

So you get mandatory MFA, a broken passkey implementation, a legacy auth flow left running for compatibility, and subject line advice.

Meanwhile the subscription fees go up. Hooray for shareholders.

Find me on Mastodon at @ppb1701@ppb.social

Part of the ongoing Big Tech's War on Users series.