Kali365 is a phishing-as-a-service kit the FBI says can hijack Microsoft 365 OAuth tokens and keep access to Outlook, Teams and OneDrive even when MFA is enabled. The practical fix is not “train users harder.” You need to restrict device code flow, audit where it’s used, and tighten Conditional Access before a fake Microsoft prompt becomes a real tenant compromise.
Kali365 warning: what the FBI actually said
On 21 May 2026, the FBI’s Internet Crime Complaint Center published Alert I-052126-PSA, titled “Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens.” The agency said Kali365 first appeared in April 2026 and is primarily distributed through Telegram.
The warning matters because Kali365 doesn’t have to steal your password in the old-fashioned way. According to the FBI, the kit captures OAuth access and refresh tokens, which can give attackers persistent access to Microsoft 365 environments after a victim completes a legitimate-looking Microsoft authorization step.
Outlook, Teams and OneDrive are specifically named as affected services. That’s a painful trio: email for identity resets and invoices, Teams for internal trust, and OneDrive for files that often contain contracts, spreadsheets, customer lists and credentials saved where they shouldn’t be.
If your mental model of phishing is still “somebody types a password into a fake page,” update it. For a useful refresher on the difference between password guessing and reused-login attacks, see this plain-English guide to brute force attacks versus credential stuffing. Kali365 sits in a different lane: it targets authorization, not just credentials.
How the Kali365 attack chain works
The FBI describes a fairly clean attack path: phishing email, legitimate Microsoft verification page or device code entry, attacker device authorization, OAuth token theft, then persistent Microsoft 365 access. Clean doesn’t mean harmless. It means repeatable.
A victim may believe they’re approving a normal Microsoft sign-in, especially if the lure references a Teams meeting, shared OneDrive file, voicemail, or account verification. Once authorization happens, the attacker can obtain tokens that may let them interact with Microsoft 365 services without needing to intercept the user’s password or one-time MFA prompt.
Here’s the pitfall many generic warnings miss: “successful MFA” in your logs can be part of the attack, not proof that everything is fine. Device code phishing abuses a legitimate authentication flow, so security teams that only look for failed logins, impossible travel, or password spray patterns may miss the more interesting signal.
Kali365 also lowers the skill barrier. The FBI says it includes AI-generated phishing lures, automated campaign templates, real-time target tracking dashboards and OAuth token capture capabilities. SafeBrowz reported on 28 May 2026 that operators pay roughly $199 per month for hosted landing pages, automated victim funneling and a console, though that pricing is from a secondary report rather than the FBI alert.
Why MFA alone won’t save Outlook, Teams and OneDrive
MFA is still worth using. No serious defender should tell you otherwise. But Kali365 is a reminder that MFA is a control, not a force field.
In this case, the attacker’s goal is to trick the user into authorizing access through a legitimate Microsoft flow. If the victim completes the process, the attacker may receive OAuth tokens that allow continued access. Refresh tokens are the nastier part because they can extend a session beyond the initial moment of compromise, depending on tenant policies and token lifetime controls.
Think about the business impact in numbers. If one compromised mailbox contains 18 months of email and the user receives 60 messages a day, that’s around 32,400 messages exposed in a single account in 2026. Add OneDrive sync folders and Teams chats, and the attacker may not need to move laterally immediately; the first account can already be rich enough.
Arctic Wolf activity cited by BleepingComputer and reported by TechRepublic on 26 May 2026 involved mailbox access, malicious inbox rules and new device registrations in victim environments. Treat that as reported observation, not a universal pattern. Still, inbox rules are a classic quiet move: forward invoices, hide security notices, and keep the victim unaware.
Remote staff are especially exposed because Microsoft sign-in prompts are routine in distributed work. If your workforce lives in browsers, Teams calls and cloud files, the basics in a 2026 remote-worker cybersecurity checklist pair well with tenant-level controls, but they don’t replace them.
Controls that reduce the risk fast
The FBI’s mitigation guidance is unusually practical. It points to restricting or blocking device code flow, using Conditional Access policy, auditing existing device code-flow usage, blocking authentication transfer policies, and excluding emergency access accounts where a full restriction isn’t possible.
Microsoft Learn documentation indexed in June 2026 confirms that Conditional Access can restrict device code flow for Teams devices and can be used to block device code flow with limited exclusions. That last phrase matters. Some organizations genuinely rely on device code flow for shared devices, meeting room equipment, Teams devices, or constrained input hardware.
- Identify where device code flow is actually used in your tenant before turning it off globally.
- Create a Conditional Access policy that blocks or restricts device code flow for normal user accounts.
- Build narrow exclusions only for validated device classes or workflows, not broad departments.
- Exclude emergency access accounts where Microsoft and FBI guidance makes a full block impractical.
- Audit sign-ins, new device registrations, mailbox rules and unusual OAuth grants after policy changes.
Honestly, a global block with no inventory is a good way to break a boardroom, a warehouse scanner workflow, or a Teams Rooms setup five minutes before an executive meeting. The smarter move is fast inventory, tight default denial, then documented exceptions with owners and review dates.
Companies growing from informal IT to formal security often struggle here because the old rule was “don’t block productivity.” That stops working once attackers rent professional tooling. If that sounds familiar, this piece on how security priorities change as organizations grow gives useful context for moving from ad hoc decisions to policy-based controls.
Which signals should security teams hunt first?
Start with authentication flows and token-related activity, then work outward. Kali365 is not just an email problem, so don’t trap the investigation inside the mail gateway.
Useful signals include device code authentication events, unexpected successful sign-ins from unfamiliar devices, new device registrations, unusual OAuth consent activity, suspicious inbox rules, and access to Teams or OneDrive from locations or user agents that don’t fit the person’s normal pattern. A single signal may be explainable. A cluster is not.
| Area to check | Why it matters in 2026 | Practical response |
|---|---|---|
| Device code flow sign-ins | FBI says Kali365 abuses legitimate Microsoft verification and device authorization steps | Restrict or block through Conditional Access after auditing real usage |
| OAuth access and refresh tokens | FBI says token capture can enable persistent Microsoft 365 access | Revoke sessions for suspected users and review app grants |
| Mailbox rules | TechRepublic reported Kali365-linked activity involving malicious inbox rules | Search for forwarding, deletion and hiding rules created after suspicious sign-ins |
| New device registrations | Reported victim activity included new device registrations | Validate device ownership and remove unknown devices |
| Teams and OneDrive access | FBI names Teams, Outlook and OneDrive as affected services | Review file access, sharing changes and unusual chat activity |
Security teams using a SOC or automation platform should encode these as chained detections, not isolated alerts. A device code flow sign-in followed by a new inbox rule and OneDrive bulk access deserves a higher priority than any one of those events alone. For teams rethinking response automation, this overview of an AI SOC platform approach in 2026 is relevant background.
A realistic response plan for a suspected Kali365 hit
Speed matters, but panic creates blind spots. If you suspect Kali365 token theft, preserve logs while cutting off the attacker’s access. Don’t only reset the password and call it done.
Revoke active sessions for the affected account, review refresh-token exposure, remove suspicious devices, inspect OAuth app permissions, and check mailbox rules. Then review Teams and OneDrive activity for file access, sharing changes and messages sent from the compromised identity.
Next, widen the search to people who received similar lures. Phishing-as-a-service kits are built for campaigns, not one-off pranks. The FBI says Kali365 includes automated campaign templates and target tracking dashboards, which means one confirmed victim may be the visible part of a broader run against your tenant.
Communications deserve care. Tell users what happened in concrete terms: “You may see a Microsoft device code prompt you didn’t initiate; don’t enter codes from email links or chat messages.” Vague warnings train people to ignore you.
There’s also an edge case for incident responders: emergency access accounts. The FBI guidance recognizes that where full restriction isn’t possible, emergency accounts may need exclusions. Those accounts should be few, monitored, physically protected where appropriate, and tested, because an emergency account that nobody can use during an outage is theater.
What to make of the wider reporting
Several outlets covered the FBI warning in late May 2026. TechRadar highlighted OAuth token capture and phishing emails that direct users to legitimate Microsoft verification pages. ITPro emphasized device code flow restrictions and auditing legitimate dependencies, and reported on 26 May 2026 that Microsoft had not responded to its request for comment on the attacks.
TechRepublic identified Outlook, Teams and OneDrive as services accessible after token theft and cited reporting on Arctic Wolf observations. The Cyber Signal also discussed Kali365 alongside EvilTokens and claimed Microsoft had reported hundreds of Microsoft 365 compromises daily across affected environments, but that figure was not found in the primary FBI or Microsoft material provided here, so you shouldn’t treat it as confirmed.
My view: the verified FBI warning is enough to act on without inflating the story. You don’t need a dramatic global compromise number to justify blocking a risky authentication flow. A single finance mailbox with persistent token access can ruin a quarter.
For broader risk planning, remember that Kali365 is not a zero-day exploit in the classic sense. It abuses legitimate identity flows and human trust. If you want the contrast, this explainer on what a zero-day exploit is in 2026 helps separate software flaws from identity abuse.
FAQ
What is Kali365?
Kali365 is a phishing-as-a-service platform the FBI says appeared in April 2026 and targets Microsoft 365 OAuth tokens. It is primarily distributed via Telegram, according to the FBI.
Does Kali365 bypass Microsoft MFA?
The FBI says Kali365 can bypass MFA without intercepting user credentials by capturing OAuth access and refresh tokens through a legitimate Microsoft authorization flow. MFA still helps against many attacks, but it isn’t enough by itself here.
Which Microsoft 365 apps are affected by Kali365?
The FBI names Outlook, Teams and OneDrive as affected Microsoft 365 services. After token theft, attackers may be able to access email, chats, files and related account data.
Should you block device code flow completely?
For many normal user accounts, blocking or restricting device code flow is sensible. Audit legitimate usage first, because Teams devices, shared hardware or constrained-input devices may need narrow Conditional Access exclusions.
What’s the first thing to do after suspected token theft?
Revoke sessions, remove suspicious devices, inspect OAuth grants and check mailbox rules. A password reset alone may not remove persistent access created through stolen tokens.
EN 
FR 
ES