Kali365 is not interesting because it bypasses Microsoft 365 MFA with some clever exploit. It is interesting because it does not need to. The victim completes the login on a real Microsoft page. The MFA challenge succeeds. The OAuth access and refresh tokens go to the attacker because the victim entered a device code that authorized the attacker's session.
That distinction matters. The failure is not "MFA is broken." The failure is that device code flow was designed for devices with bad keyboards, and the security ceremony happens away from the device being authorized. Microsoft documents the risk directly: device code flow can be part of a phishing attack, can be used to access corporate resources from unmanaged devices, and should be blocked wherever possible with Conditional Access. That is the control. Not more user training. Not another MFA enrollment campaign. A policy that removes the authentication flow unless there is a real business need.
The current Kali365 reporting is useful mostly because it puts a commercial wrapper around an old primitive. The kit reportedly packages AI-generated lures, campaign templates, victim tracking dashboards, and OAuth token capture for Microsoft 365. That does not make the technique new, but it changes the labor economics. A low-skill operator can now run a flow that ends with persistent access to Outlook, Teams, and OneDrive without ever seeing the user's password.
The operational fix is boring and therefore good:
- Put a Conditional Access policy in report-only mode that targets authentication flows and measures device code flow usage.
- Identify the real exceptions: conference-room devices, signage, developer tooling, and emergency access accounts.
- Block device code flow everywhere else.
- Review sign-in logs for the original transfer method so refreshed sessions do not hide the initial risky flow.
- Revoke suspicious refresh tokens when a user entered a code they did not initiate.
This is the same lesson as every mature identity control: the deterministic boundary beats the ceremony. MFA is still necessary. Phishing-resistant MFA is better. But if an attacker can ask the user to complete a legitimate OAuth flow for the wrong device, the answer is not a better lecture about links. The answer is to remove that flow from the places it does not belong.
See also
- Your MCP Configs Are an Attack Surface Now - the same token-governance problem in local agent configuration
- The Lethal Trifecta Has Receipts - why deterministic controls beat probabilistic defenses
- Using IAP on Cloud Run for Single-User Apps - a concrete identity boundary for small production apps
References
- Conditional Access: Authentication flows, Microsoft Learn.
- OAuth 2.0 device authorization grant, Microsoft Learn.
- FBI warns of Kali phishing scam hitting Microsoft OAuth tokens, TechRadar, 2026-05-25.