Device-Code Phishing Kits Drain M365 Tokens With MFA Intact

Why the mechanism matters more than the kit

The OAuth device authorization grant exists for devices that cannot render a login form: smart TVs, kiosks, CLI tools on headless boxes. The device asks Microsoft for a code, the human types that code into the real login.microsoftonline.com page on a phone or laptop, and Microsoft hands the requesting device an access token and a refresh token. Nothing in that sequence breaks when the requesting device belongs to an attacker. The lure only has to persuade a target to enter a code they were told came from IT.

That is why the two kits now circulating, Kali365 and EvilTokens, are scaling across hundreds of M365 tenants with AI-written lures and automated token capture. There is no credential to steal and no proxy to fingerprint, and the user genuinely completes MFA. The attacker walks away with a refresh token, which survives a password reset and keeps minting access tokens until it is explicitly revoked.

Where the guidance diverges

This is the week's most important disagreement in defensive advice. One line of reporting, anchored on the Kratos/SneakyLog AiTM ecosystem, pushes FIDO2 and passkeys against adversary-in-the-middle phishing. Against a proxy that replays credentials, it works. Device-code abuse is not a proxy attack. The user authenticates directly with Microsoft using whatever strong factor was deployed, and the token is issued to the attacker's device anyway. Phishing-resistant MFA raises the bar on one vector while leaving this one wide open.

The Zimbra campaign reported in parallel is the same class from a different vendor. After exploiting the mail server, the actor mints a Zimbra application passcode of the kind legacy IMAP and ActiveSync clients use, and that passcode bypasses MFA entirely. Patching the server does not revoke it. Two unrelated products, one shared failure: a legitimate secondary credential path the identity controls were never asked to evaluate.

The move

Blocking the device-code flow is a single Conditional Access policy and, for most tenants, an afternoon of work. The hard part is enumerating the handful of genuine kiosk and shared-display scenarios that need an exception before flipping it. The residual risk is any token already issued, which is why the hunt matters as much as the block. Hunt for anomalous token issuance, new device registrations, and stealthy inbox forwarding rules across the last 60 days. Those are the signals that separate a clean tenant from a quiet one.

A refresh token stolen through a flow you approved by design will outlive your password reset, your MFA re-enrollment, and your incident report.

Treat this as the template, not the incident. Every identity platform in production has at least one legacy or convenience authentication path — app passwords, legacy protocol passcodes, service-account secrets, device-code grants — enabled by default and never revisited. That inventory is now a standing deliverable, not a project.