Microsoft 365 MFA Bypass: How Device Code Phishing Actually Works

Your organization has multi-factor authentication switched on. An attacker is reading a mailbox anyway, and when you look at the sign-in logs the sign-in looks completely normal — right user, correct password, MFA satisfied, no failed attempts. Nothing was broken into. This article explains the technique behind that, in plain English, and the settings that stop it. The important thing to understand up front is that the attacker never had the password and never defeated MFA. They got the user to complete MFA for them.

First, what a token is

Think of MFA as the bouncer at the door. You show your ID and your phone, the bouncer waves you in, and you get a wristband that says "already checked, let this person through." For the rest of the night you flash the wristband instead of doing the whole ID check again. That wristband is your token — the digital pass Microsoft 365 issues after a successful sign-in, so you are not asked to prove who you are every time you open Outlook or Teams.

Attackers stopped trying to fake the ID. They went after the wristband. And the technique in the FBI's advisory has a particularly uncomfortable property: the wristband is never handed to the user in the first place. It goes straight to the attacker, issued by Microsoft, in response to a check the real user passed.

How device code phishing works

On 21 May 2026 the FBI published an advisory — IC3 alert I-052126-PSA, at ic3.gov/PSA/2026/PSA260521 — titled "Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens." (No relation to the Kali Linux distribution; the name collision is coincidental.) The FBI's own summary is that the kit lets attackers obtain Microsoft 365 access tokens and bypass MFA "without intercepting the user's credentials." That last phrase is the whole story.

Device code sign-in is a genuine Microsoft feature, built for devices that cannot show a proper login screen — a conference room display, a TV app, a headless server. You get a short code, you type it into a Microsoft page on your phone or laptop, and the device you were setting up gets signed in. Perfectly legitimate. The attack abuses it exactly as designed:

1. The attacker starts the sign-in on their own machine. Microsoft hands them a code, valid for a few minutes.
2. They send the code to your user inside a plausible lure — a meeting invite, a document share, an IT request.
3. Your user enters it on a real Microsoft page. Not a fake. The genuine page, on the genuine domain, with a valid certificate. They type their real password and approve their real MFA prompt, and everything works.
4. Microsoft issues the tokens to the attacker. The code your user typed belonged to a sign-in request the attacker opened seconds earlier, so the session that successful authentication produced is delivered to the attacker's server.

There is a second detail that decides how long the intruder stays. Along with the short-lived access token, the attacker requests a refresh token. That is the one that matters. An access token expires in about an hour; a refresh token keeps producing new ones and continues working until somebody explicitly revokes it. That is why this is an account takeover rather than an hour of access.

The other route into the same outcome

Device code phishing is not the only way an attacker ends up holding a valid session. The other common route is an adversary-in-the-middle page: a proxy that relays the genuine Microsoft sign-in page to the victim, passes their password and MFA response through to Microsoft, and keeps a copy of the session cookie that comes back. Same result, different plumbing — and the same kit families often ship both. If that is the one you are looking at, the mechanism and the containment steps are covered in detail in Microsoft 365 session token theft.

The practical point is that these are two detection surfaces, not one. A plan that watches for proxy phishing and ignores device code sign-ins is only half a plan.

A note on the name

If you search "Kali365" today you will find that the operators announced they were shutting down — on 21 May 2026, the same day the FBI advisory landed. Treat that with suspicion rather than relief. SpyCloud's researchers, who had been tracking the operation, reported that capture activity continued daily afterwards and that only the brand went quiet, consistent with a planned rebrand; Huntress separately reports the same platform operating under more than one name. Customers had reportedly been told about new infrastructure two weeks before the "shutdown."

Two lessons for anyone using this article to brief a team. First, hunt the technique — device code sign-ins and session cookie replay — not the brand name, because the brand is the part that changes. Second, be careful with dates and numbers in this subject: the FBI says it first observed the kit in April 2026, while SpyCloud places the earliest sighting about six weeks earlier, and the widely repeated claim that "hundreds of organizations" were targeted does not appear in the FBI advisory at all. It comes from press coverage of a different kit.

On cost, since it is usually the detail that lands in a board conversation: two named research teams — Todyl and SpyCloud — independently observed an entry price of roughly $250 for 30 days advertised by the operators themselves. The FBI confirms distribution via Telegram but states no price. That is criminal advertising observed by researchers, not an audited fact, and it is worth repeating in that form. The point stands either way: this is not a nation-state capability. It is a subscription.

What MFA covers, and what it does not

Five settings that close the gap

In rough order of protection per hour spent. Licensing is stated honestly, because the difference between "included" and "needs Entra ID P2" is the difference between a plan you can act on this week and one you cannot.

1. Block device code sign-in — free, and the highest-value change here

This shuts the door the whole attack walks through, and you do not need a premium license for it. Blocking device code flow is part of Security Defaults, which costs nothing, and since 1 July 2026 all new Microsoft Entra tenants block device code flow by default under Security Defaults. If you have Entra ID P1 — included with Microsoft 365 Business Premium, E3 and E5 — you can do it more selectively with a Conditional Access policy and exclude the accounts that genuinely need it.

Check what breaks first. Device code flow has legitimate users: Teams Rooms and other conference room devices, some IoT and headless equipment, and certain device registration flows. Turning it off tenant-wide without looking is an outage. Look at your sign-in logs for device code authentications, find out who is actually using it, then block everyone else.

2. Move to phishing-resistant sign-in

Passkeys, FIDO2 security keys and Windows Hello for Business are tied to the real sign-in address, so a proxy on a lookalike domain gets nothing. Note the limit honestly, though: phishing-resistant credentials defeat the proxy route above, and they do not by themselves stop device code phishing, because in that attack the user is on Microsoft's real page and the credential works exactly as intended. Blocking device code flow is what stops that one. You want both, and this is why.

3. Sign-in risk policies, and knowing what CAE is

Risk-based Conditional Access — block or force reauthentication when a sign-in looks risky — requires Entra ID P2. That is a real cost and worth planning rather than assuming.

Continuous access evaluation is often listed as something to switch on. It is not: CAE is enabled automatically as part of Conditional Access, and the session control that exists in the portal is there to disable it. Useful to know its limits before relying on it: it can take up to about fifteen minutes to act on a critical event, it does not support guest accounts, and it only recognises IP-based named locations — which is the usual reason an admin concludes it is not working.

4. Alert on the tells — with the right names

Most guidance on this gets the detection names wrong, which sends people hunting for switches that do not exist:

• Atypical travel is the native Entra ID Protection detection and needs Entra ID P2. Impossible travel is a different detection that comes from Defender for Cloud Apps and needs P2 plus a Defender for Cloud Apps license, or Microsoft 365 E5 with EMS E5. They are two detections, not two names for one.
• Unfamiliar sign-in properties is what covers a sign-in from an unrecognised device, IP, location or browser. It is real-time, and it needs P2.
• New mail-forwarding rules — use the built-in Microsoft 365 alert policy "Creation of forwarding/redirect rule", which works on E1, E3 or E5 with no premium identity license. Two caveats that matter: it only catches rules created in Outlook on the web or through Exchange Online PowerShell, so a rule made in the Outlook desktop client is missed, and it fires at Informational severity — route it somewhere a person actually reads. Do not go looking for the old Defender for Cloud Apps "Suspicious inbox forwarding" policy; Microsoft disabled that in June 2025 and folded it into a newer detection model.

5. Know how to revoke, before you need to

A password reset on its own does not evict an attacker holding a refresh token. Microsoft's own revocation guidance is more particular than most people expect: a user-initiated password change, a self-service reset, or an admin reset performed from the Azure portal revokes password-based sessions and leaves other token classes alive — while the same admin reset performed from the Microsoft Entra admin center or the Microsoft 365 admin center does revoke them. Rather than memorising which portal behaves how, revoke explicitly.

Microsoft's emergency procedure is three actions, not one: disable the account, revoke the refresh tokens (Revoke-MgUserSignInSession, or "Revoke sessions" in the portal), and disable the user's registered devices. On a hybrid tenant, reset the on-premises password twice — Microsoft's stated reason is to limit pass-the-hash exposure where password replication lags. And before you re-enable the account, delete any authentication methods the attacker registered, or you have handed it back with their key still in it.

Where this gets costly

The danger of a stolen session is how quiet it is. There is no failed login and no MFA prompt, so the intrusion often stays invisible for days. In that window the pattern is predictable: the attacker sets a mail-forwarding rule to read incoming mail, watches for an invoice or a payment thread, then sends a message from the real account asking a client or a bookkeeper to change payment details. The customer pays the attacker. The email came from a genuine account, so it passes every spam filter, and the first anyone hears about it is a call about a missing payment.

Cleaning that up — the forensics, the disclosure, the conversations with the customer whose money went elsewhere — costs considerably more than the configuration change that would have prevented it.

What to do this week

1. Search your sign-in logs for device code authentications. If the answer is "none, ever," blocking the flow costs you nothing and closes the main door.
2. If there are some, find out which devices they belong to before you block anything.
3. Check whether your help desk runbook says "reset the password" or "revoke the sessions." If it says the first, fix that sentence today — it is free.
4. Confirm the forwarding-rule alert is switched on and that it reaches a person.
5. Decide, deliberately, whether you are buying Entra ID P2 for the risk detections — or accepting that you are running without them.

Most of this is configuration you already own rather than something to buy. The first item on that list is free, takes an afternoon to check properly, and closes the exact route the FBI advisory describes.

---

Sources

• FBI / IC3 — "Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens," Alert Number I-052126-PSA, 21 May 2026 (ic3.gov/PSA/2026/PSA260521)
• Microsoft Security Blog — device code phishing campaign analysis, April 2026; and Microsoft's reporting on Storm-2372's use of a first-party client ID in device code attacks
• Microsoft Learn — Security Defaults (blocking device code flow; new tenants from 1 July 2026), Conditional Access licensing, Continuous access evaluation, What are risk detections?, Anomaly detection policies in Defender for Cloud Apps, Alert policies in the Microsoft Defender portal
• Microsoft Learn — Refresh tokens in the Microsoft identity platform (revocation table), and Revoke user access in an emergency
• Arctic Wolf Labs, Proofpoint Threat Research, Todyl, SpyCloud and Huntress — independent analyses of the kit, its pricing, its infrastructure and its rebranding. Pricing and rebrand claims are attributed to those teams, not to the FBI
• MITRE ATT&CK — software entry S9044

Microsoft, Microsoft 365, Microsoft Entra ID, Microsoft Teams, Microsoft Defender, Exchange Online and Outlook are trademarks of the Microsoft group of companies. AZ Innovations is an independent IT services provider and is not affiliated with or endorsed by Microsoft.