Kali Linux you know. Kali365 is something else entirely
Kali365 is a phishing-as-a-service kit the FBI warned about in May 2026. It takes Microsoft 365 OAuth tokens through device code phishing — no password stolen, no MFA prompt raised.

If you have spent any time around security people, you know Kali Linux: the Debian-based distribution full of penetration-testing tools, maintained by OffSec, used by every red team and half the students on every security course. Legitimate, well-documented, openly published.
Kali365 has nothing to do with it. Same first word, entirely different thing — and the borrowed name is doing real work, because it makes a criminal subscription service sound like a researcher's toolkit. It is a phishing-as-a-service platform aimed squarely at Microsoft 365 tenants, sold by subscription, and the FBI issued a public service announcement about it on 21 May 2026 (alert I-052126-PSA) after first observations in April.
If you take one thing from this article: it does not want your password, and your MFA will not fire.
How the device code flow is supposed to work
Microsoft's OAuth 2.0 device authorization grant — device code flow — exists for a genuine problem. Some things that need to sign in have no usable keyboard or browser: a meeting-room display, a smart TV, a command-line tool on a headless server.
So the flow splits authentication across two devices. The input-constrained device asks Microsoft for a short code and shows it to you. You go to a Microsoft sign-in page on your phone or laptop, type the code in, authenticate normally — password, MFA, the lot — and approve. Microsoft then issues tokens to the device that requested the code.
That last sentence is the whole problem. The flow is designed so that the thing receiving the token is not the thing you authenticated on.
How Kali365 turns that around
The attack is three steps and it is almost insultingly simple.
- A code arrives. You get a message — a shared document, a voicemail notice, a Teams invitation, a security alert, something ordinary — that leads to a page carrying a device code and an instruction to enter it.
- You sign in, for real. The sign-in happens on Microsoft's own page, at the real address, with a valid certificate. Nothing about it is fake, because nothing about it needs to be. You complete MFA exactly as you have been trained to.
- They keep the token. The code you entered belonged to a session the attacker started. Microsoft issues the access and refresh tokens to them.
No credential was captured. No lookalike domain was involved. No MFA prompt was intercepted or replayed — the prompt was answered correctly, by the right person, on the right page. The ceremony was simply performed on the attacker's behalf.
Why "MFA bypass" is the wrong phrase for it
You will see Kali365 described as bypassing multi-factor authentication. It is a reasonable shorthand and a slightly misleading one.
Nothing was bypassed. MFA ran, and it succeeded. The token is the output of a successful multi-factor authentication, and the token is what was stolen. This matters because it changes what defends against it: strengthening the authentication does not help if the authentication was never the weak point.
That is the uncomfortable part for anyone who has just finished a passwordless rollout. Phishing-resistant credentials solve credential phishing and adversary-in-the-middle proxying. They do not solve this, because the user is not being tricked into authenticating somewhere fake — they are being tricked into authorising something they did not start.
Why a stolen token is worse than a stolen password
A stolen password is a nuisance with a well-understood fix. A stolen refresh token is a tenancy.
- It survives a password reset. Resetting the password is the reflex response to account compromise, and on its own it does not end a token-based session. Sessions have to be revoked explicitly.
- It renews itself. A refresh token's whole purpose is to get fresh access tokens without asking the user anything. Left alone, it keeps working.
- It looks like the user. Activity arrives inside a legitimately-issued session for a real account, so a lot of the signals you would normally rely on — impossible travel, failed sign-ins, password spray patterns — never appear.
- It reaches everything the user reaches. Mail, Teams, OneDrive, SharePoint. The same inheritance that makes Copilot useful makes a stolen session useful.
What follows is usually commercial rather than dramatic: mailbox reconnaissance for invoice and payment threads, mail-flow rules that quietly divert the replies, and onward phishing from a genuine internal address — which is far more effective than anything sent from outside.
The part that makes it a trend rather than an incident
Device code phishing is not new. Security researchers have been writing about it for years, and competent attackers have used it for about as long.
What changed is packaging. Kali365 is sold as a service, with lure templates, campaign management and dashboards, which means the technique no longer requires the person using it to understand it. That is the same shift the industry watched with ransomware: the interesting development was never the encryption, it was the affiliate programme.
The FBI's PSA is, in that sense, less a warning about one kit than a warning that this particular technique has reached the volume end of the market.
About the name
It is worth being blunt about this, because the confusion is the point.
Kali Linux is a published, documented security distribution with an identifiable maintainer, used under authorisation and with a scope document. Kali365 is a criminal service sold to anonymous subscribers, whose purpose is unauthorised access to other people's tenants. Borrowing the name buys a veneer of research-tool respectability that nothing about the thing deserves.
If someone in your organisation repeats "it is a pen-test tool" in a meeting, that is the sentence to correct.
What to do about it
The good news is unusually good: because device code flow is rarely needed, the primary control is one Conditional Access policy, and most tenants can apply it with a small number of exclusions. The work is in finding those exclusions first, and in checking whether anything already happened.
We have written that up as a separate checklist: is your Microsoft 365 tenant protected against Kali365? — audit, block, harden, hunt, and what to do if you find one.
Copilot SafeScan reads your tenant's identity posture read-only — Conditional Access policies, MFA coverage, guests, app registrations — and scores it alongside the exposure checks, with remediation steps per failing item. It is one way to find out where you stand before you start changing policy.
Related: the defensive checklist, why posture drifts when nobody did anything wrong, and what to fix first.




