Kali365 and the OAuth Device Code Phishing Wave

The FBI has been tracking a phishing-as-a-service kit called Kali365 since April 2026¹. It ships over Telegram and targets Microsoft 365 accounts, capturing access without stealing the password or intercepting the MFA code. It does that with the device code flow, a legitimate part of the OAuth 2.0 spec (RFC 8628)² that Microsoft uses to let input-constrained devices without a browser sign in³.

How the attack runs

The victim gets a message, by email or Telegram, telling them to open a Microsoft sign-in page and paste in a code. The URL is real, the sign-in works, and MFA fires and succeeds. That is the whole trick. The MFA challenge is not bypassed. The victim completes it, on behalf of the attacker’s app registration. Once the code authorizes, Microsoft issues an access token to the attacker, and the account is theirs from that point. Nothing suspicious lands on the victim’s phone.

The user did everything right. They typed a code on a genuine Microsoft page and answered their MFA prompt. The attack works because the user executes the authentication for the attacker.

Why the mail gateway cannot see this

Mail security in my setup runs as a layered gateway in front of the mail platform, and phishing campaigns start with a lure. The gateway catches a share of them: spoofed senders, malicious links, known PhaaS URLs. Kali365’s second step happens on microsoft.com, though. No mail filter sees the victim paste a device code, and once the token exists, perimeter tooling is out of the picture. Containment is an identity-layer problem.

Detection: what I look for in the sign-in logs

Every sign-in that runs through the device code flow leaves a marker in the Entra sign-in logs: the authentication protocol field and the original transfer method field both identify the flow. I filter the sign-in log for successful device code sign-ins and review each one against the app registration.

The tell is a successful device code sign-in from an app I do not recognize, from a user who has no business using device code auth in their day to day. In a higher ed setup the baseline is noisy, because people test things, so I compare the app registration against the apps we deployed. One successful device code sign-in from an unapproved app is an incident.

Mitigation: a conditional access block

Microsoft’s guidance is to get as close as possible to a unilateral block on device code flow⁴, and Conditional Access has a dedicated “block authentication flows” control for it. I build the policy as a block on the device code flow, then scope it:

• Users: everyone.
• Apps: everything except the apps I have confirmed we need for device code sign-in.
• Conditions: deny.

Device code flow exists for devices without a full browser: smart TVs, conference room systems, streaming boxes, printers, IoT devices. If a department needs one of those, it gets an app-level exception, documented, reviewed quarterly. The default is block.

The user-side tell

The pattern to report: “go to the Microsoft device login page and paste this code” is a device code sign-in request. In my setup nobody should be doing that unless they are following a published procedure. That tell goes into the help desk playbook. If you pasted a device code you did not initiate, tell us now, and we revoke the token and the app registration.

The takeaway

Kali365 is one kit and the IC3 PSA is one warning, but the mechanism is durable. Any OAuth provider that implements device code flow can be phished this way, because it is a standard flow and not a Microsoft invention. Detection runs in the sign-in logs, and a conditional access policy blocks the flow. An unexpected device code sign-in gets treated as an active compromise.