Kali365 Microsoft 365 Token Theft: The MSP Checklist After MFA Stops Being Enough
If your Microsoft 365 security checklist still ends at "MFA is enabled," Kali365 is the part where the checklist gets awkward.
The FBI's May 2026 PSA says the Kali365 Microsoft 365 phishing-as-a-service kit can capture OAuth access and refresh tokens, then give attackers persistent access without needing the user's password or another MFA prompt. That does not mean MFA is dead. It means checkbox MFA is not an access-control strategy.
For MSPs, the useful response is not panic. It is a better assessment.
Look at admin MFA strength, Conditional Access gaps, device-code flow exposure, risky sign-ins, session revocation steps, device compliance, user reporting, and where token-theft cleanup stops being included support and starts being paid security work.
Quick answer
Kali365 is a reminder that Microsoft 365 MFA alone is not enough for MSP clients. MSPs should assess phishing-resistant MFA for privileged roles, Conditional Access coverage, device-code flow controls, sign-in review, session revocation procedures, compliant-device requirements, and clear scope boundaries for token-theft response.
That last part matters. If the client treats every token-theft cleanup as a normal help desk ticket, your team just became an incident response provider for free.
What the FBI actually warned about
The FBI IC3 PSA from May 21, 2026 says Kali365 was first seen in April 2026 and is distributed mainly through Telegram. The PSA says the platform can capture Microsoft 365 OAuth tokens and let attackers access Outlook, Teams, and OneDrive without intercepting the user's credentials.
That is the important defensive point: the user can complete a real Microsoft sign-in flow and still authorize the wrong thing.
Cybersecurity Dive's coverage adds useful context from security researchers: device-code phishing can look normal to the victim because it uses legitimate Microsoft infrastructure. The attack path is weird enough that a user might not recognize it as phishing, but normal-looking enough that a lazy security review can miss it.
Do not turn this into a how-to guide for attackers. Your client-facing version should stay at the level of:
- attackers are targeting Microsoft 365 sessions, not just passwords
- OAuth tokens can keep access alive after the login
- MFA prompts are not the same as phishing-resistant access control
- admin and high-value accounts need stronger rules than ordinary users
- token revocation needs a tested runbook, not a best-effort scramble
Why "we have MFA" is not a real answer
Traditional MFA answers one question: did the user satisfy a second factor during authentication?
Token theft changes the question: can an attacker reuse or preserve access after a sign-in flow has already happened?
Microsoft's own docs separate these controls for a reason. Authentication strengths let Conditional Access require specific methods, including phishing-resistant MFA. Microsoft's built-in phishing-resistant strength includes methods such as FIDO2 security keys, Windows Hello for Business or platform credentials, and multifactor certificate-based authentication.
For admins, Microsoft is more direct. Its phishing-resistant MFA policy guidance for administrator roles says privileged accounts are frequent attacker targets and recommends phishing-resistant MFA for roles like Global Administrator, Conditional Access Administrator, Exchange Administrator, Security Administrator, SharePoint Administrator, and User Administrator.
So the MSP checklist should stop asking, "Is MFA on?"
Ask this instead:
- Are privileged roles protected with phishing-resistant MFA?
- Are emergency access accounts excluded safely and monitored?
- Is device-code flow allowed for everyone by default?
- Do Conditional Access policies cover all users, all cloud apps, and admin roles?
- Are sign-in logs reviewed for device, location, IP address, app, and user agent patterns?
- Does the client have a session revocation runbook that someone has actually tested?
If those answers are fuzzy, the tenant has an assessment finding. Not a vibe. A finding.
The MSP checklist for Kali365-style Microsoft 365 token theft
Use this as a client-ready assessment table. It keeps the conversation practical and avoids threat-news theater.
| Control area | What to check | What to tell the client |
|---|---|---|
| Privileged access | Admin roles, break-glass accounts, guest admins, stale partner access | "Admin access needs stronger authentication than ordinary user access." |
| MFA strength | Whether admins use phishing-resistant methods or ordinary push/SMS flows | "MFA is enabled, but the method still matters." |
| Device-code flow | Whether device-code authentication is allowed broadly | "The FBI specifically recommends restricting or blocking device-code flow where possible." |
| Conditional Access | Report-only policies, exclusions, legacy auth, location rules, app coverage | "Policy coverage is uneven, so token theft risk is not controlled consistently." |
| Sign-in review | Risky users, unusual locations, unfamiliar devices, impossible travel, user agent patterns | "We need a repeatable review process, not one-off log hunting." |
| Session revocation | Who can revoke sessions, when to block users, how to handle registered devices | "Cleanup needs a runbook before the incident." |
| Device compliance | Whether sensitive apps require managed or compliant devices | "Tokens are harder to abuse when access depends on device state." |
| Client responsibilities | User reporting, approval for disruption, legal or breach decisions | "The client owns business decisions. The MSP owns the technical work in scope." |
This is where Microsoft 365 Conditional Access baseline work stops being a nice-to-have. It is the foundation for saying which users, devices, locations, apps, and authentication methods are allowed to touch client data.
It also connects directly to the shared responsibility matrix. Token theft is exactly the kind of event where everyone suddenly remembers the agreement differently.
Your token revocation runbook needs boring detail
The runbook does not need drama. It needs owners, permissions, evidence, and a tested sequence.
Microsoft's emergency access revocation guidance says compromised accounts, terminations, and insider threats can require administrators to revoke all user access. It also explains the annoying but important token detail: Microsoft Entra access tokens last one hour by default, and browser-based applications may use session tokens controlled by the application.
Translation for an MSP owner: revoking sessions is necessary, but it is not magic dust.
Your runbook should answer:
- Who has permission to disable the account and revoke sign-in sessions?
- When do you block the user first versus reset password first?
- Which registered devices get disabled or reviewed?
- Which apps need separate session cleanup because Entra cannot directly revoke every app session?
- How do you collect sign-in evidence before changing the state?
- Who tells the client that Teams or email may not be trustworthy for user verification?
- What is included in normal support, and what becomes incident response?
Microsoft's ID Protection investigation guidance recommends reviewing sign-in logs for app, device, location, IP address, and user agent, then using actions such as password reset, MFA re-registration, blocking users, and revoking sessions when risk cannot self-remediate.
That belongs in the runbook. Not buried in a senior tech's head.
Scope boundaries: where support ends and security work starts
This is the part MSPs underprice.
A token-theft scare can turn into hours of log review, user interviews, device checks, mailbox rule review, Teams message inspection, OneDrive access review, legal coordination, password resets, executive reporting, and client reassurance. If the agreement only says "Microsoft 365 support," congratulations, your margin is now a donation.
Write the boundary before the event.
| Work item | Include in monthly support? | Better scope |
|---|---|---|
| Basic MFA enrollment help | Usually yes | Normal support |
| Conditional Access assessment | No | Fixed-fee identity readiness assessment |
| Phishing-resistant admin MFA rollout | No | Security hardening project |
| Token/session revocation for one clearly compromised user | Maybe | Define a capped emergency response allowance |
| Tenant-wide sign-in review after a campaign | No | Incident response or security review project |
| Client reporting and executive summary | No | Paid assessment deliverable |
| Policy redesign after findings | No | Roadmap item with budget and approval |
If the client wants the MSP to own more, fine. Quote it.
If the client will not fund it, document the accepted risk. Do not hide the risk inside a ticket comment nobody will read during renewal.
Turn this into a QBR and roadmap conversation
Kali365 is not just a security headline. It is a client planning trigger.
Bring the finding into the next QBR as a gap analysis:
- Current state: MFA is enabled, but admins do not use phishing-resistant methods.
- Risk: token theft can preserve Microsoft 365 access after a user completes a sign-in flow.
- Required decision: approve a Conditional Access and admin MFA hardening project.
- Budget item: identity readiness assessment, rollout, user communication, and documented exclusions.
- Ongoing service: monthly sign-in review, exception review, and QBR-ready reporting.
That ties neatly into Microsoft Entra ID licensing work. Conditional Access needs Entra ID P1. Full ID Protection investigation features point at P2. If the client is on Business Standard and expects serious identity controls, the license conversation has to happen before the project quote.
Scopable is not an incident response tool. It is the place an MSP can carry findings from assessment to gap analysis, roadmap, budget, quote, and project handoff without rebuilding the story in five systems. If you want that workflow for security findings like this, join Scopable early access.
The plain-English client message
Use this with clients who heard about Kali365 and now want a yes-or-no answer.
Kali365 does not mean Microsoft 365 MFA is useless. It means ordinary MFA is only one layer. We should confirm whether your admin accounts use phishing-resistant MFA, whether risky sign-ins are reviewed, whether device-code flow is restricted, and whether we have a tested process to revoke sessions if an account is compromised.
That is specific enough to be useful. It avoids fear-selling. It also creates a path to paid, defensible work.
The bad answer is "you're covered because MFA is on."
The better answer is "MFA is on, and here is what we checked around it."
