Kali365 code phishing Microsoft 365

Last updated: June 3, 2026

Your team members get a lot of email. Most of it is routine. So when something shows up that looks like a Microsoft document share or a Teams notification, they open it. That’s exactly what attackers are counting on.

The FBI issued a public warning in May 2026 about a phishing-as-a-service platform called Kali365. It lets attackers get into Microsoft 365 accounts without ever needing your employees’ passwords, and without getting blocked by multi-factor authentication. If your business runs on Microsoft 365 — email, Teams, OneDrive, SharePoint — this is worth understanding.

What is a phishing-as-a-service platform?

Phishing attacks used to require some technical know-how. You needed to build infrastructure, write convincing lures, track victims, and capture whatever tokens or credentials you were after. That’s no longer the case.

Phishing-as-a-service (PhaaS) platforms sell ready-made attack kits on a subscription basis. Think of it like SaaS, but for cybercrime. Kali365 is one of these platforms. According to the FBI, it’s been distributed primarily through Telegram since it was first seen in April 2026. For a subscription fee, an attacker gets AI-generated phishing emails, automated campaign templates, dashboards to track who clicked what, and the core capability that makes this attack dangerous: OAuth token capture.

How the Kali365 attack works, step by step

The FBI advisory lays out the attack sequence. It’s worth walking through because it exploits something that looks completely legitimate at every step.

Step 1 — The lure. Your employee gets an email that looks like it’s from a trusted cloud service. A shared document, an invoice, a collaboration request. The email contains a device code and tells the recipient to visit a real Microsoft page to enter it.

Step 2 — The authorization. The employee goes to the legitimate Microsoft page and types in the code. Nothing looks wrong. The page is real. Microsoft’s branding is real. There’s no fake login form, no malicious download.

Step 3 — Token theft. By entering that code, the employee has unknowingly authorized the attacker’s device to access their Microsoft 365 account. The attacker now holds OAuth access and refresh tokens.

Step 4 — Persistent access. The attacker can now read Outlook email, access Teams conversations, browse OneDrive files, and use SharePoint — without a password, and without triggering MFA. Refresh tokens can extend that access well beyond the initial session.

Steven Campbell, a threat intelligence researcher at Arctic Wolf, which has been tracking Kali365 since early April 2026, put it plainly: because the attack uses legitimate Microsoft infrastructure, the activity looks normal to the victim. It’s harder to spot than a traditional phishing attack, and it doesn’t require the attacker to build anything sophisticated from scratch.

Who is being targeted?

According to Arctic Wolf’s research, Kali365 campaigns have targeted organizations across manufacturing, education, insurance, financial services, healthcare, and government. That’s a wide net. These aren’t highly selective, targeted attacks against a single company. Attackers are running volume campaigns and going after whoever they can catch.

Small and mid-sized businesses are often more exposed here, not because they’re specifically targeted, but because they’re less likely to have the conditional access policies and monitoring in place that larger enterprises use. If your Microsoft 365 environment is configured mostly out of the box, your defaults may allow device code flow with no restrictions.

What you can do right now

The FBI advisory includes specific technical mitigations. These are real steps, not vague best-practice advice. Your IT team or MSP can act on these directly:

• Block or restrict device code flow. Create a conditional access policy in Microsoft Entra ID (formerly Azure AD) that blocks device authentication codes for all users. Before doing this, audit your environment to make sure no legitimate business processes depend on device code flow — some legacy hardware or kiosk setups do.
• Block authentication transfer. Add a policy that prevents users from transferring authentication from a desktop to a mobile device. This cuts off another route attackers use.
• Review active sessions and OAuth tokens. Check Microsoft Entra ID for any unfamiliar apps or devices that have been granted access to your tenant. Revoke anything that shouldn’t be there.
• Train your team on device code phishing. Most employees have never heard of a device code. If they know that a legitimate Microsoft email will never ask them to go enter a code on a separate page, they’re harder to fool.
• Protect emergency access accounts. If you do restrict device code flow, exclude your break-glass admin accounts from the policy so you don’t lock yourself out of your own tenant.

CISA also has published phishing guidance that covers this attack type in more detail if your team wants to go deeper.

Why MFA alone doesn’t stop this

This is probably the most important thing to understand about Kali365. MFA is still worth having. But MFA protects the login, not the token. If your employee completes MFA normally, logs in, gets an OAuth token issued, and an attacker then steals that token through a device code attack, your MFA requirement has already been satisfied. The token is the proof of authentication, and now the attacker has it.

This is why conditional access policies matter more than a simple MFA toggle. Conditional access lets you say things like “this account can only authenticate from a company-managed device” or “block any device code authentication entirely.” That’s the layer that actually stops this kind of attack.

If your Microsoft 365 setup is still running on basic MFA with no conditional access, you have real exposure here. Checking your configuration should be near the top of your to-do list.