# The Login Page Was Real. That's the Point.
Microsoft's device code flow was built for smart TVs and command-line tools — devices that can't easily pop a browser window. You've probably seen it: a short code, a URL, a message telling you to approve it on another device. It's legitimate. It works. And a phishing kit called Kali365 has been quietly turning it into a skeleton key for US enterprise networks.
This isn't a spoofed login page. There's no fake Microsoft domain to catch in the address bar. The authentication happens on microsoft.com — real certificate, real UI, real token issuance. The victim does everything right and still hands over persistent cloud access to someone they've never met.
## How the Device Code Flow Becomes a Weapon
The OAuth device authorization grant was designed for a specific constraint: some devices can't handle interactive browser-based authentication. A Roku, a CLI script, a kiosk terminal. The flow works by having the device request a code from Microsoft's authorization server, then directing the user to a separate device — typically a phone or laptop — to enter that code at microsoft.com/devicelogin and approve the request.
What Kali365 does is deceptively straightforward: the attacker initiates that flow. They request the device code. They send it to the victim via a phishing email or message with plausible enterprise framing — an IT helpdesk request, a conditional access alert, a Teams notification about a new security policy. The victim goes to the real Microsoft page, enters the code, clicks approve. Microsoft issues access and refresh tokens back to whoever initiated the request.
That's the attacker.
The access token typically grants immediate read access to email and OneDrive. The refresh token is the real prize — it lets the attacker silently request new access tokens for weeks or months without the victim doing anything else. No password needed. No MFA challenge. The user already did the MFA.
## What Makes Kali365 Notable
Device code phishing isn't new. Microsoft's security team documented the technique in 2022. Russian threat actors — notably a cluster Microsoft tracks as Storm-2372 — ran coordinated campaigns against European governments and NGOs using variations of this method. What shifts with Kali365 is accessibility.
When a technique gets packaged into a kit, the barrier to entry drops from "competent threat actor who understands OAuth flows" to "anyone who can follow instructions and rent infrastructure." The US enterprise targeting is deliberate — American organizations tend to be heavy Microsoft 365 users, and the prize on the back end (email archives, SharePoint, Teams histories, Azure tenant access) is substantial.
The kit reportedly handles the token lifecycle — capturing credentials, managing refresh, potentially chaining into further access. This is commodity adversary-in-the-middle capability minus the actual middle. There's no proxy server intercepting traffic, no HTTPS spoofing to detect. The attack operates entirely through Microsoft's own infrastructure.
## The Gap in Corporate Defenses
Most enterprise phishing training is built around a core lesson: look for fake URLs, check the sender domain, hover over links. Device code phishing invalidates all of it. The URL is real. Microsoft sent the email confirmation. The organization's SSO is involved.
Conditional access policies that check device compliance or require hybrid Azure AD join can help — if the attacker's device doesn't meet policy, the token may not grant full access. But many organizations run conditional access in report-only mode, or carve out exceptions that create exploitable gaps. And phishing kits are increasingly good at targeting accounts where those guardrails are weakest: contractors, partners, accounts in the middle of onboarding.
Microsoft added some friction to device code flows in recent years, including the ability to block device code authentication entirely via Conditional Access. That's the right lever, but most organizations haven't pulled it because they use legitimate device code flows internally — for Azure CLI, VS Code, developer tooling. Locking it down requires knowing what's actually running in the environment, which is harder than it sounds.
There's also a forensics problem. Because the victim approved the request on a legitimate page, the authentication event looks normal in Entra ID logs. No anomalous login from an unexpected country. No failed MFA. The attacker's initial access may be invisible until they do something with it.
---
## HackWire Analysis
Device code phishing campaigns have been escalating quietly for three years, but Kali365 signals something worth paying attention to: the technique has cleared the commoditization threshold.
When Storm-2372 ran device code attacks against government targets in 2024-2025, it required nation-state level operational sophistication and targeting. That's a different risk model than a packaged kit running against US enterprises at volume. The trajectory here mirrors what happened with AITM phishing frameworks like Evilginx and Modlishka — techniques originally associated with advanced persistent threat groups that eventually became standard tooling for financially motivated criminals.
For defenders, the immediate question isn't "are we being targeted by Kali365 specifically" — it's "do we have visibility into device code authentication events, and have we made an active decision about whether to allow them?"
Entra ID logs every device code flow. Pull the SignInLogs table in Log Analytics and filter for clientAppUsed eq 'Device Code Flow'. If you see volumes you can't explain by known internal tooling, that's your starting point. The Microsoft Security blog from February 2025 on Storm-2372 has detection logic worth adapting.
The longer-term fix is conditional access policy that explicitly blocks device code auth for external-facing applications, with exceptions only for validated internal use cases. That's a breaking change in some environments, which is exactly why most teams haven't done it. Kali365 is a reminder of what that deferral costs.
One angle that's missing from most coverage: the refresh token persistence problem. These attacks don't end when the phishing campaign ends. An attacker who captured tokens six months ago may still be in your tenant, silently refreshing access. Token revocation — pushing users through re-authentication and invalidating existing sessions — needs to be in the incident response playbook for any suspected device code compromise.
— HackWire Editorial
---
## Related Coverage