A practical, no-hype guide to the phishing kit that walks past MFA, and the configuration changes that shut it down.
Most security advice small businesses hear still assumes attackers are after your password. Kali365 is a reminder that the game has moved on. It is a phishing kit, sold as a subscription service, that does not need your password at all. It steals the session token your Microsoft 365 account issues after you log in, which means multi-factor authentication (MFA) does not stop it, and changing your password afterward does not evict the attacker.
The FBI issued a public advisory about Kali365 in May 2026, having first observed it in April 2026. Since then, researchers at Huntress have taken the kit apart and documented how it works. The picture is not comforting, but the fix is refreshingly boring: a handful of configuration changes inside Microsoft 365 close the door almost entirely. This guide explains what Kali365 does in plain language, then walks through the exact steps to defend against it.
What Kali365 is
Kali365 is a phishing-as-a-service platform. Think of it the way you think of any subscription software, except the customers are criminals. For a monthly fee, someone with almost no technical skill gets ready-made phishing templates, automated campaigns, and a dashboard to track victims. The FBI reports it has been sold mainly through Telegram, and researchers have also seen it operating under the names Octopi365 and Freedom365.
What makes it dangerous is not the phishing email. It is the login trick behind it, known as device code flow abuse.
How the attack works: the device code trick
If you have ever signed a smart TV into a streaming service by typing a short code into a website on your phone, you have used device code flow. It is a legitimate Microsoft feature, designed to let a device that is awkward to type on borrow a login from a device that is not. Kali365 turns that convenience against you.
Here is the sequence, drawn from the FBI advisory:
- The lure. You get an email that looks like a normal document-sharing or productivity notification, for example a shared SharePoint file or an encrypted message. It contains a short code and instructions to visit a real Microsoft verification page.
- The authorization. You go to the genuine Microsoft page, because it is genuine, and you enter the code. Nothing looks wrong. In doing so, you approve the attacker’s device to sign in as you.
- The token theft. Microsoft issues an access token and a refresh token, and the attacker’s system captures both.
- The persistence. The attacker can now reach your Outlook, Teams, and OneDrive without a password and without answering any MFA prompt.
Two details make this worse than ordinary phishing. First, because you approved a real login, MFA is already satisfied, so your authenticator app never warns you. Second, the refresh token lets the attacker stay signed in even after you change your password. Huntress documented cases where an attacker gained persistent access in as little as 42 seconds from the click.
What happens after they are in
Once inside a mailbox, the operators do not just look around. Huntress found that the more advanced versions of the kit include tools that scan for wire-transfer, invoice, and payroll threads, draft convincing fraudulent replies, and send mail as the victim to phish other people in the company and its contacts. Some versions can alter mail-flow rules and mail connectors at the tenant level if they capture an administrator account. In short, one approved code can turn into invoice fraud, a data exposure, and a launch pad for attacks on your clients.
The point is leverage, not fear. Almost everything Kali365 relies on can be switched off with settings you already own in Microsoft 365. You do not need a bigger budget. You need the right few changes, made in the right order.
Why small businesses are squarely in scope
It is tempting to assume token theft is an enterprise problem. It is not. The same trick works against a solo Outlook user as against a 500-person company, and because the kit lowers the skill needed to run a campaign, attackers are casting wide. For a small business, a single compromised mailbox often holds banking details, client records, and the authority to approve payments. That is exactly what these operators are hunting for.
The reason this article is a checklist rather than a warning is simple: the primary defense is a setting, not a purchase.
The step-by-step defense
Below are the controls in priority order. The first four are configuration changes inside Microsoft 365. The last two are about detection and habits. If you run your own IT, you can follow these directly. If you have an IT provider, this is the list to hand them.
Before you start. Conditional Access requires Microsoft Entra ID P1 licensing, which is included with Microsoft 365 Business Premium, and an account with at least the Conditional Access Administrator role. Always test in report-only mode first, and always exclude your break-glass accounts, covered in Step 4.
Step 1: Audit how device code flow is used today
Do not block anything yet. First, find out whether anyone in your environment legitimately relies on device code flow, because a handful of older tools and hardware do. In the Microsoft Entra admin center, open the sign-in logs and filter for device code authentications. Microsoft’s guidance is to audit existing usage and confirm it is still necessary before you restrict it. In most small businesses the honest answer is that nobody needs it, which makes the next step easy.
Step 2: Block device code flow with a Conditional Access policy
This is the single highest-impact control. Microsoft recommends that organizations get as close as possible to a complete block on device code flow, and Huntress, after dissecting Kali365, agrees. Here are the exact steps:
- Sign in to the Microsoft Entra admin center at entra.microsoft.com as a Conditional Access Administrator.
- Go to Entra ID, then Conditional Access, then Policies.
- Select New policy and give it a clear name, for example Block device code flow.
- Under Assignments, select Users. Under Include, choose All users. Under Exclude, add your emergency access (break-glass) accounts.
- Under Target resources, choose Resources, then Include, then All resources.
- Under Conditions, open Authentication Flows, set Configure to Yes, select Device code flow, and choose Done.
- Under Access controls, open Grant, select Block access, then Select.
- Set Enable policy to Report-only, then create it.
- Let it run in report-only for a short period, review the results to confirm nothing legitimate is caught, then switch Enable policy from Report-only to On.
That report-only step matters. It lets you see what the policy would have blocked without actually blocking anyone, so you catch the rare legitimate use before it becomes a help-desk ticket.
Step 3: Block authentication transfer
While you are in Conditional Access, close a related door. Authentication transfer lets a user hand a signed-in session from a computer to a mobile device, and it is another path attackers can lean on. Create a second policy the same way:
- New policy, named something like Block authentication transfer.
- Under Assignments, Include All users, and Exclude your break-glass accounts.
- Under Target resources, Include All resources.
- Under Conditions, Authentication Flows, set Configure to Yes, select Authentication transfer, then Done.
- Under Access controls, Grant, select Block access, then Select.
- This one rarely affects normal work, so you can enable it directly. Confirm your settings and set Enable policy to On.
Step 4: Protect your break-glass and service accounts
Every Conditional Access policy needs an escape hatch. A break-glass account is a highly protected emergency administrator login that you exclude from your policies, so that a misconfiguration can never lock every admin out of the tenant. Create at least one, give it a long unique passphrase stored somewhere safe, and exclude it from both policies above. Audit that exclusion list regularly so it never quietly becomes a backdoor.
Service accounts and service principals, the non-human logins that run background tasks, also need attention. User-scoped Conditional Access does not apply to service principals, so review them separately and, where possible, replace them with managed identities.
Step 5: Watch for the attack in your sign-in logs
Configuration blocks the front door. Detection catches what slips through, for instance if a policy has a gap or a legitimate exclusion is abused. The tricky part with Kali365 is that once an attacker replays a stolen token, their activity can resemble a normal signed-in user, complete with the usual single-sign-on session. Huntress notes the useful signals are things like device code sign-ins you did not expect, logins from unusual networks or hosting providers, and outdated or unusual browser identifiers. Reviewing sign-in and audit logs regularly, or better, having a service watch them around the clock, is what turns a silent compromise into an early alert.
Step 6: If you suspect a compromise, revoke tokens, do not just reset the password
This is the response detail most people get wrong. Because the attacker holds a refresh token, resetting the password alone does not remove them. You have to revoke the active sessions and refresh tokens, review the mailbox for newly created forwarding or inbox rules and any changes to mail flow, re-check MFA registrations, and then reset credentials. Report the incident to the FBI Internet Crime Complaint Center at ic3.gov, and preserve the phishing email headers and any suspicious sign-in details, because they help.
The habit that prevents the click
All of this technical work buys you a strong safety net, but the cheapest control is teaching your team one specific rule: a legitimate service will never email you a code to type into a Microsoft login page you did not personally start. If an email hands you a code and tells you where to enter it, that is the red flag. Once people know the exact shape of this trick, the lure stops working.
The short version
If you do nothing else, work down this list in order.
| Step | Control | Why it matters |
| 1 | Audit device code flow usage | Find any legitimate use before you block, so nothing breaks |
| 2 | Block device code flow (Conditional Access) | Removes the main path Kali365 relies on |
| 3 | Block authentication transfer | Closes a related session-handoff bypass |
| 4 | Set up break-glass and service accounts | Prevents lockouts and closes policy gaps |
| 5 | Monitor sign-in and audit logs | Detects stolen-token replay that slips past config |
| 6 | Revoke tokens on any suspected compromise | A password reset alone does not evict the attacker |
| 7 | Train staff on the device-code rule | Stops the lure before anyone clicks |
Closing thought
Kali365 is a clever attack, but it is not an unstoppable one. The controls that neutralize it are already sitting in your Microsoft 365 tenant, waiting to be switched on in the right sequence. Blocking device code flow, closing authentication transfer, protecting your emergency accounts, and keeping an eye on your sign-in logs will put you ahead of the vast majority of businesses that have never touched these settings.
Want a second set of eyes? If you are not sure whether these policies are set up correctly, or you would like someone to review your Microsoft 365 configuration with you, we are glad to help. Call Harmony MSP at (407) 720-6540 and we will walk through it at your pace.
