Kali365 Explained: How the Microsoft 365 Phishing Kit Works and How to Harden Your Tenant

In May 2026 the FBI published a public service announcement (alert I-052126-PSA) about Kali365, a phishing-as-a-service platform built specifically to take over Microsoft 365 accounts. Since then, almost every client conversation I’ve had about security has included the same question: “Are we protected?”

The honest answer for most tenants is “not yet”, but the fix is far simpler than the headlines suggest. In this post I explain how Kali365 works, why MFA doesn’t stop it, and the six-step hardening checklist I’m applying to client tenants.

What Kali365 is (and isn’t)

First, the name. Kali Linux is a legitimate, well-documented penetration testing distribution maintained by OffSec. Kali365 has nothing to do with it. The borrowed name makes a criminal subscription service sound like a researcher’s toolkit. If someone in a meeting calls it “a pen-test tool”, correct them.

Kali365 is sold by subscription with lure templates, campaign management and dashboards. That’s what makes it a trend rather than an isolated incident: the technique it uses, device code phishing, has been known for years, but it no longer takes any skill to run.

How device code flow is meant to work

The OAuth 2.0 device authorisation grant exists for a real problem. Some devices that need to sign in have no usable keyboard or browser: Teams Rooms displays, smart TVs, command-line tools on headless servers. The flow splits sign-in across two devices:

1. The device asks Microsoft for a short code and displays it.
2. You go to the Microsoft sign-in page on your phone or laptop, enter the code and authenticate normally, with password and MFA.
3. Microsoft issues tokens to the device that requested the code.

That last step is the whole problem. By design, the thing receiving the token is not the thing you authenticated on.

How Kali365 abuses it

1. A code arrives. The user gets an ordinary-looking message, such as a shared document, a voicemail notice, a Teams invite or a “security alert”, that tells them to enter a code.
2. The user signs in for real. On Microsoft’s genuine sign-in page, with a valid certificate, completing MFA exactly as they’ve been trained to.
3. The attacker keeps the tokens. The code belonged to a session the attacker started, so Microsoft issues the access and refresh tokens to them.

No password was captured. No fake domain was used. No MFA prompt was intercepted. The sign-in was simply performed on the attacker’s behalf.

Why “MFA bypass” is the wrong way to describe it

Nothing is bypassed. MFA runs and succeeds, and the token it produces is what gets stolen. That’s uncomfortable if you’ve just rolled out passkeys: phishing-resistant MFA is worth having, but it won’t stop this. The user isn’t tricked into signing in somewhere fake. They’re tricked into authorising something they didn’t start.

Why a stolen token is worse than a stolen password

• It survives a password reset. Sessions have to be revoked explicitly.
• It renews itself. A refresh token keeps getting new access tokens without asking the user.
• It looks like the user. No failed sign-ins, no password spray, often no impossible-travel alert.
• It reaches everything the user can. Mail, Teams, OneDrive and SharePoint. If the user has Copilot, the attacker has a very efficient search engine across all of it.

What follows is usually financial: reading mailboxes for invoice threads, adding inbox rules that divert replies, and sending phishing from a genuine internal address.

The six-step hardening checklist

1. Audit before you block

In the Microsoft Entra sign-in logs, filter for device code flow over the last 30–90 days. In most tenants the result is empty, or a handful of entries such as Teams Rooms and signage, CLI or automation tools on servers, some VDI and thin-client setups, and developers using CLI tools. Note each one and its owner. Each one becomes either a deliberate exclusion or something you move to a better sign-in method.

2. Block device code flow with Conditional Access

Create a Conditional Access policy for all users and all cloud apps, using the Authentication flows condition set to device code flow, with the grant control Block access.

• Exclude your break-glass (emergency access) accounts. Always.
• Start in report-only mode for a week and compare the results with your audit.
• Scope exclusions narrowly, to specific accounts or device groups, never “the whole tenant until we work it out”.

3. Block authentication transfer too

The same condition covers authentication transfer, which moves a signed-in session from one device to another. The FBI advisory mentions it for the same reason. Audit it and block it unless you can name what needs it.

4. Reduce the value of a stolen token

• Continuous access evaluation (CAE) lets supporting apps react to revocation in near real time.
• Token protection binds sessions to the device they were issued to. Check current support for your apps and platforms before relying on it.

5. Hunt for what already happened

Blocking stops new attempts. It does nothing about a token stolen last month. Look for:

• Successful device code sign-ins before your block went live.
• Refresh-token activity with no preceding interactive sign-in.
• Microsoft client apps signing in from hosting providers or other unexpected networks.
• Inbox rules mentioning invoice, payment, bank or remittance.
• Mail forwarding, new mail-flow rules and new connectors.
• Recent OAuth app consents, especially by non-admins.
• Newly registered authentication methods.

6. Revoke properly

If you find a compromised account, a password reset alone is not enough. Revoke the user’s sessions, either with Revoke sessions in the Entra admin centre or Revoke-MgUserSignInSession in Microsoft Graph PowerShell. Then reset the password, re-register authentication methods, and remove the rules, forwarding and app consents the attacker added. Remember that existing access tokens can stay valid for up to about an hour in apps that don’t support CAE.

Make it a standing check

Security posture drifts. An exclusion gets added during an incident and never removed. An acquired tenant arrives without the policy. Someone turns a policy off “just to test” on a Friday. The real question isn’t “did we block device code flow?” but “is it still blocked, and would we notice if it wasn’t?” Make it a quarterly check with a named owner, alongside MFA coverage, guest accounts and app registrations.

If you want an automated way to check this, LogiSam’s Copilot SafeScan reviews Conditional Access, MFA coverage, guests and app registrations in read-only mode and generates remediation steps. For scripted audits, see my PowerShell scripts for Microsoft 365.

FAQ

Does phishing-resistant MFA protect against Kali365?

No. The user authenticates correctly on the real Microsoft page. The weakness is where the resulting token goes, not how the user proves who they are.

Will blocking device code flow break anything?

It can, which is why you audit first and run the policy in report-only mode. Teams Rooms, signage, some CLI tools and some thin clients may rely on it.

Is resetting the password enough after a compromise?

No. You must revoke sessions and refresh tokens, then clean up any persistence the attacker added, such as inbox rules, forwarding and OAuth consents.

Related reading: Overshared SharePoint: your biggest Copilot risk · Before you turn on Copilot