Identity

Device-Code Phishing: The 2026 Attack That Walks Past MFA — and the CIS Hardening That Stops It

The Kali365 phishing kit (FBI PSA I-052126, May 2026) hijacks Microsoft 365 accounts without a password and without defeating MFA — it lets you approve the login yourself. Here is how device-code phishing works, why MFA alone does not save you, and how CIS Benchmark identity hardening closes the door.

Published 14 June 2026

In May 2026 the FBI issued public service announcement I-052126 warning that a phishing-as-a-service kit called Kali365 was hijacking Microsoft 365 accounts across hundreds of organizations. What made the warning notable was not the scale — it was the method. Kali365 does not steal passwords, and it does not defeat multi-factor authentication. It gets the victim to approve a real Microsoft login on the attacker's behalf.

This is device-code phishing, and it is the identity attack that defined the first half of 2026. The uncomfortable part for most Microsoft 365 tenants: it succeeds against the default identity configuration. A tenant hardened against the CIS Microsoft 365 Foundations Benchmark has far less room for it to work.

How the attack works

The technique abuses Microsoft's legitimate device code flow — the OAuth mechanism built for signing into devices that cannot show a browser, like a smart TV or a CLI tool. The steps are deceptively simple:

A convincing email arrives. It impersonates SharePoint, DocuSign, or Microsoft itself — increasingly AI-generated, so the usual spelling-and-grammar tells are gone.
The link goes to the real Microsoft login page. Not a look-alike. There is no fake domain to spot, because the attacker is driving the genuine microsoft.com/devicelogin flow.
The victim enters an attacker-supplied device code and approves the sign-in — completing a perfectly genuine MFA prompt on their own phone.
Microsoft issues access and refresh tokens to the attacker's session. The attacker is now signed in as the user.

Because the victim satisfied MFA legitimately, MFA was never bypassed — it was used as designed. That is what makes the attack so effective, and why kits like Kali365 (sold on Telegram for as little as $250 a month, with automatic token capture) and tooling such as EvilTokens have commoditized it. Security vendors tracked the technique scaling from state-aligned actors in late 2025 to mainstream criminal use by early 2026, with hundreds of compromised organizations across multiple countries.

There is a second sting in the tail: resetting the victim's password does not evict the attacker. The stolen refresh token lives independently of the password, so the standard "reset and move on" response leaves the door open. You have to revoke the sessions and tokens.

Why this is really a configuration problem

It is tempting to file device-code phishing under "user awareness" and move on. But the reason it works at scale is that most tenants run identity at its permissive defaults:

The device code flow is available to every user because nobody scoped it with a Conditional Access policy.
MFA is satisfied by phishable factors (SMS codes, push approvals) rather than phishing-resistant ones.
Sign-ins from unmanaged devices and unusual locations are not challenged.
Over-privileged accounts mean one phished user can reach far more than they should.

Every one of those is a configuration decision — and configuration is exactly what a benchmark governs.

Where the CIS Benchmark comes in

The CIS Microsoft 365 Foundations Benchmark v5.0.0 defines 129 controls across 9 sections. The largest by far is Section 5 — Microsoft Entra (Identity), with 37 controls covering MFA, Conditional Access, authentication methods, and Privileged Identity Management. That is the entire surface device-code phishing depends on.

The specific countermeasures the FBI and Microsoft recommend for this attack — a Conditional Access policy that blocks or tightly scopes the device code flow, phishing-resistant MFA (passkeys / FIDO2), and challenging unmanaged-device and unusual-location sign-ins — are precisely the kind of identity hardening Section 5 moves a tenant toward, and away from the defaults the attack relies on.

And the benchmark limits the blast radius even when a user is fooled:

Section 1 — Microsoft 365 admin center (14 controls) keeps administrators cloud-only, unlicensed, and few in number (the benchmark caps Global Administrators), so a phished standard account cannot become tenant takeover.
Section 3 — Microsoft Purview (4 controls) keeps the unified audit log on, so the unusual device-code sign-in is recorded and investigable instead of invisible.

A tenant assessed and hardened against these sections is not relying on every employee to spot a flawless phishing email. It has removed the conditions that let one click turn into a compromise.

Where ConfigCobra fits

ConfigCobra does not block attacks in real time — that is what your Conditional Access and identity controls are for. What ConfigCobra does is make sure those controls are actually in place and stay in place.

A full assessment connects to your tenant using read-only Microsoft Graph permissions — no agents, no scripts in your environment, no admin passwords shared — and within 20–25 minutes returns pass/fail/partial results for all 129 controls across all 9 sections, including the 37 identity controls in Section 5. For every finding you get the actual configuration value, the CIS remediation procedure, and a generated PowerShell script where applicable.

The part that matters most for an attack like this is continuous monitoring and drift detection: identity settings get loosened for a migration, a vendor, or a "temporary" exception and quietly never tightened again. ConfigCobra re-scans on the cadence you set and alerts you the moment a control regresses — so the gap that device-code phishing would walk through is caught when it appears, not after a breach.

In other words: the misconfiguration that makes this attack possible is exactly the kind of finding ConfigCobra is built to surface — before an attacker finds it first.

What to do this week

Scope the device code flow. Add a Conditional Access policy that blocks it, with exceptions only for genuine device-login use cases.
Move to phishing-resistant MFA (passkeys / FIDO2) for admins first, then everyone.
Make session revocation part of incident response — reset the password and revoke tokens/sessions.
Watch your sign-in logs for device-code authentications you do not recognise.
Assess your identity posture against CIS Section 5 so you know which of the 37 controls are actually passing today.

You can run that last step now: start a free trial to assess 15 controls against your own tenant immediately, or book a demo to see your full Section 5 results.