Have you heard of Kali365, the threat targeting your Microsoft 365 tenant?

Ask around your IT team this week and you will get one of three answers. Most people have not heard of Kali365 at all. Some have, and think it is a penetration-testing tool. And a few have filed it as a Microsoft 365 vulnerability — something that will turn up in a patch cycle and be dealt with by whoever deals with patches.

That third answer is the one worth correcting, because it is the one that quietly removes the problem from anybody's list.

It is not a vulnerability, and that is the point

There is no CVE for Kali365. Microsoft has not issued a fix, and will not, because nothing is broken. The device code flow it abuses is a documented, intentional part of the OAuth 2.0 device authorization grant, working exactly as designed — a way for something without a keyboard, like a meeting-room display or a command-line tool, to get a sign-in done on a device that does have one.

Kali365 is a criminal subscription service that abuses that design. The practical consequences of the distinction are these:

• Your vulnerability management process will never surface it. No scanner flags it, no patch closes it, and no CVSS score ever appears to argue about.
• Nobody owns it by default. It is not a patching job, so it does not land with the patching team. It is a configuration and awareness job, which usually means it lands nowhere until somebody asks.
• It does not expire. A vulnerability has a shelf life — the fix ships and the window shuts. This technique works for as long as device code flow is enabled and a person can be persuaded to type a code.

That last point is why "we are fully patched" is not an answer to this question.

What it actually does, in one paragraph

A message arrives with a short code and an instruction to enter it on a Microsoft sign-in page. The page is real. The address is real. The certificate is real. You sign in properly and complete MFA properly — and Microsoft issues the resulting tokens to the device that requested the code, which is the attacker's. No password is captured and no MFA prompt is intercepted, because the authentication succeeded; it was simply performed on somebody else's behalf. We have written up the mechanics in full in Kali Linux you know, Kali365 is something else entirely.

What has changed since the FBI alert

The FBI's Internet Crime Complaint Center issued its public service announcement on 21 May 2026, after the kit was first observed in April. Reporting since then, covered by BleepingComputer and Help Net Security among others, has filled in what the service actually sells:

• Distribution through Telegram. It is sold in criminal channels to subscribers, which is what turns a technique into a volume business.
• AI-generated lures. The quality tell that staff were trained to spot — awkward phrasing, obvious translation errors — is no longer reliable.
• Campaign templates and tracking dashboards. The operator does not need to understand the attack. They pick a template and watch a dashboard.
• A second mode. Researchers describe an adversary-in-the-middle option called Cookie Link alongside the device code path, so blocking one flow does not retire the whole kit.

Microsoft's position is that customers should follow the FBI's guidance and its own published best practices — which is reasonable, and is also a reminder that this is a tenant configuration question rather than something arriving in an update.

Three defences that do not help as much as you would expect

Patching

Covered above, but worth stating plainly: a fully patched tenant is exactly as exposed as an unpatched one. The patch cycle is simply not the control surface here.

Phishing-resistant MFA

This is the uncomfortable one for anyone midway through a passwordless rollout. FIDO2 keys and passkeys are excellent, and they solve credential phishing and adversary-in-the-middle proxying properly. They do not solve this, because the user is not being tricked into authenticating somewhere fake. They are being tricked into authorising a session they did not start, and they authorise it with whatever strong credential you gave them.

Resetting the password

The reflex response to a suspected compromise does almost nothing here. No password was taken, and a refresh token survives a password reset — it renews itself, it looks like the user, and it keeps working until the session is explicitly revoked. If an account is compromised this way and the response is a password reset, the attacker still has the tenant.

Four questions worth asking this week

You do not need to run this yourself. You need to know whether somebody has.

1. Is device code flow blocked in Conditional Access? Most organisations need it for very little, so the usual answer is a block with a short, named list of exclusions.
2. Do we know what those exclusions are? This is the real work, and the reason the block sometimes stalls. Find the genuine uses first — the shared displays, the scripts — then block everything else.
3. Have we looked backwards? The technique has been available since well before the kit packaged it. Sign-in logs will show whether device code authentications have happened, and from where.
4. Does our compromise playbook revoke sessions, not just reset passwords? If the runbook stops at the password, it does not end this.

The step-by-step version of all four — what to audit, what to block, what to hunt for in the logs and how to revoke properly — is in is your Microsoft 365 tenant protected against Kali365?

Where to start if the answers were vague

If you asked those four questions and got an uncertain answer to any of them, the quickest way to replace the uncertainty with a list is to look at the tenant's identity posture directly: Conditional Access coverage, MFA coverage, guest accounts, app registrations and their permissions.

That is what Copilot SafeScan reads, read-only, in under five minutes — scoring each domain and giving your administrator the remediation steps for anything failing. It will not tell you whether you have been phished, but it will tell you how much of the surrounding posture is doing its job.

And the simplest control of all costs nothing: tell people that a device code should only ever be typed in when they started the sign-in. A code that arrives by email, chat or a shared document is not a task to complete. It is somebody else's session, waiting to be approved.