Device code phishing is moving from a niche trick into a repeatable identity-theft pattern. Proofpoint says new device-code tools are appearing weekly, with campaigns using URLs, PDF attachments, and QR codes to send victims to landing pages that display a short verification code. The victim is then pushed to Microsoft’s real microsoft.com/devicelogin flow, where entering the attacker-provided code can grant access without the attacker needing the password itself [1].
The important shift is psychological. Classic credential phishing asks a victim to type a password into a fake page. Device code phishing can feel safer because the final login happens on a legitimate Microsoft domain. That is exactly the trap: the user is not “logging in to view a document” so much as authorizing the attacker’s session. Proofpoint observed multiple lookalike device-code phishing variants in a short April 2026 window, including activity tied to PhaaS-style kits such as EvilTokens, Tycoon, ODx, and Kali365 [1]. On May 21, 2026, the FBI/IC3 issued PSA260521 warning that Kali365 was first seen in April 2026, distributed mainly through Telegram, and built to capture Microsoft 365 OAuth access and refresh tokens without stealing the password itself [2].
FBI Kali365 Warning: What To Do Now
The FBI’s Kali365 PSA describes a simple chain: a message impersonates a trusted cloud or document-sharing service, gives the victim a device code, sends them to Microsoft’s legitimate verification page, and then lets the attacker capture OAuth access and refresh tokens. The practical takeaway is that changing the password alone is not enough if the stolen token is still valid [2].
- If you received the lure but did not enter the code: do not use the code, report the message, and verify document shares or Teams requests by opening Microsoft 365 directly rather than following the email flow.
- If you entered the code: revoke active sessions and refresh tokens, remove unfamiliar devices or app consents, then reset the password from a clean device. Review mailbox forwarding, inbox rules, OneDrive/SharePoint activity, and recent sign-ins because token access can outlive the original message.
- For administrators: audit legitimate device-code usage, review sign-in logs for device-code authentication, restrict or block the flow with Conditional Access where possible, and block authentication transfer policies where they are not required. Preserve email headers, login times, IP addresses, locations, and unauthorized sessions for incident reporting.
What Makes This Different From Password Phishing
For ordinary Microsoft 365 users, the red flag is not only a strange password page. It is any message that tells them to copy a code from an email, PDF, QR destination, “secure document,” HR notice, court portal, or signing page and paste it into Microsoft’s device login page. If they did not intentionally start login from a TV, conference-room device, CLI tool, or another device without a browser, that code flow should be treated as suspicious.
For administrators, this is a token and session problem, not just a password problem. Microsoft’s own Entra documentation describes device code flow as high risk and says it can be controlled with Conditional Access authentication-flow policies [3]. A useful response sequence is to review sign-in logs for device-code flow, look for unfamiliar applications or locations, revoke refresh tokens for affected users, reset passwords only after revocation, and consider blocking device code flow except where a real business device requires it.
This also explains why recent Microsoft-themed phishing stories are converging. AiTM kits, Teams help-desk lures, and now device-code campaigns all try to move the fight away from a simple password check and toward session control. Gridinsoft recently covered Microsoft AiTM phishing and Teams help-desk lures dropping ModeloRAT; device-code phishing belongs in that same family because the victim action looks legitimate while the attacker receives the useful access.
Related context: Operation Ramz shows how phishing infrastructure can sit behind fake login pages and compromised devices, not only behind one visible form.
Related context: Microsoft later described Storm-2949 abusing Self-Service Password Reset, another case where trusted Microsoft identity flows became the attack path.
References
- Proofpoint Threat Research. “Device Code Phishing is an Evolution in Identity Takeover.” Proofpoint, May 13, 2026, accessed June 1, 2026. Proofpoint report
- Federal Bureau of Investigation / Internet Crime Complaint Center. “Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens.” IC3, May 21, 2026, accessed June 1, 2026. IC3 PSA260521
- Microsoft Learn. “Authentication flows as a condition in Conditional Access policy.” Microsoft, accessed June 1, 2026. Microsoft Learn guide
