🎧 Prefer to listen? Audio version below — approximately 14 minutes.
The FBI issued a public warning yesterday about Kali365, a Phishing-as-a-Service platform first observed in April 2026 and distributed via Telegram. The advisory is worth reading carefully, not because the technique is new -- it isn't -- but because of what the timing tells you about where the threat landscape has arrived.
Kali365 does not steal passwords. It does not intercept MFA codes. It does not require a lookalike domain or a spoofed login page. It exploits a legitimate Microsoft authentication protocol, turns your users' correctly-functioning MFA against them, and walks out with persistent access to Outlook, Teams, and OneDrive. By the time it triggers any alarm, the attacker has already left.
To understand why this works, you need to understand the OAuth 2.0 Device Authorization Grant -- RFC 8628 in the standards library. The protocol was designed for a sensible purpose: allowing input-constrained devices such as smart televisions, printers, and IoT sensors to authenticate to cloud services without a browser or keyboard. The device obtains a short-lived code pair from the authorisation server and asks the user to complete authentication on a separate, capable device -- a phone or laptop -- by visiting a well-known URL and entering a short human-readable code.
Microsoft implements this for Microsoft 365 via a standard endpoint, and the legitimate verification URL is microsoft.com/devicelogin. That is the real Microsoft site. No lookalike domain. No suspicious certificate. No credential-harvesting form. Just the genuine Microsoft authentication page.
That is precisely the problem.
The attack is structurally simple. The attacker sends a request to Microsoft's device authorisation endpoint and receives a user_code, a device_code, and a fifteen-minute expiry window. They craft a phishing email -- impersonating a document-sharing notification, a DocuSign request, a voicemail alert, a Microsoft Forms prompt -- and embed the user_code as if it were a one-time access code. The victim, following what appears to be a routine workflow, visits the real Microsoft page and enters the code. They complete their MFA challenge. Microsoft's systems respond correctly. The attacker's polling loop succeeds, and Microsoft returns a valid access_token and refresh_token to the attacker's system.
The victim did everything right, on the real Microsoft website, with their real MFA device. They just did it for someone else.
The access token is short-lived. The refresh token is not. Depending on tenant configuration, refresh tokens can remain valid for weeks or months. More critically: they survive password resets. An organisation that discovers a compromise and resets the affected user's password without also explicitly revoking the token session may unknowingly leave the attacker's access fully intact.
Token revocation requires a specific administrative action -- a call to the revokeSignInSessions API or the equivalent operation in Microsoft Entra ID. A standard incident response playbook that goes "change the password, force re-authentication" does not close this door. Organisations that have not reviewed their IR procedures in light of token-based attacks should consider whether their current runbooks are written for a threat model that no longer describes the attacks they will face.
Post-compromise activity in documented campaigns has followed a consistent pattern: Microsoft Graph API enumeration, bulk mailbox access, OneDrive file harvesting, contact and calendar exfiltration. In some cases, attackers have registered attacker-controlled devices against the victim's Entra ID tenant -- a persistent foothold that survives token revocation entirely.
This technique did not begin as a PhaaS offering. Its origins trace to mid-2024, when Microsoft began tracking a cluster designated Storm-2372 -- a Russia-aligned threat actor targeting government agencies, NGOs, defence contractors, telecommunications providers, and energy sector entities across Europe, North America, Africa, and the Middle East. Microsoft disclosed the campaign publicly in February 2025.
The technique then followed the predictable trajectory of every effective attack method: once the playbook was documented in public threat intelligence, actors with lower technical capability began incorporating it. By September 2025, Proofpoint was observing a sharp volumetric increase in device code phishing activity. By October 2025, financially-motivated threat actors had adopted it. By February 2026, EvilTokens had packaged the entire attack chain into a subscription service -- phishing templates, token capture infrastructure, campaign automation -- and advertised it on Telegram. Within weeks, EvilTokens infrastructure was linked to compromises across more than 340 Microsoft 365 organisations spanning the United States, Canada, Australia, New Zealand, and Germany.
Affected sectors: construction, nonprofits, real estate, manufacturing, financial services, healthcare, legal services, local government. The breadth reflects the nature of PhaaS operations -- indiscriminate and opportunistic, optimised for volume rather than target selection.
Kali365, arriving in April 2026, represents the next iteration. AI-generated lures. Automated campaign templates. Real-time tracking dashboards. The commodity layer is now fully operational.
The most direct technical control available is also the most straightforward: block device code flow entirely via a Microsoft Entra ID Conditional Access policy. No device code flow, no device code phishing. The FBI PSA says it plainly. The Cloud Security Alliance research note says it plainly. Microsoft's own documentation says it plainly.
Most organisations haven't done it.
The reasons are usually operational rather than ignorance. Some environments have legitimate device code flow dependencies -- smart displays, conference room hardware, legacy integrations -- and nobody has audited which ones before creating a blocking policy. The result is that a control which is both free and effective sits undeployed because the prerequisite audit hasn't been completed.
The audit is not complicated. Query Entra sign-in logs for authenticationProtocol: deviceCode over the preceding 90 days. Review what you find. Categorise it as legitimate business requirement or legacy technical debt. Build the policy with documented exceptions. That is the work.
If device code flow is not in use anywhere in your environment, there is no operational justification for leaving it enabled. The attack surface should not exist if nothing legitimate depends on it.
The uncomfortable implication of this attack class is not that MFA is useless -- it isn't. It is that MFA's security model rests on an assumption that device code phishing systematically violates: that completing an authentication challenge correlates with the user's intent to authorise the session being created.
When the device code flow is abused, the user completes authentication entirely correctly and with full possession of their authentication factors. They validate the correct origin. They respond to the correct MFA prompt. FIDO2 origin binding provides no protection because the authentication occurs on genuine Microsoft infrastructure. Phishing-resistant authenticators are not resistant to this attack class because the vulnerability lies in the protocol architecture, not in the strength of the authentication factor.
Security awareness training that teaches users to inspect URLs, verify certificates, and avoid lookalike domains does not address this threat. The victim visits the real Microsoft website. There is nothing anomalous to detect through the approaches that traditional phishing training emphasises.
This matters for how organisations communicate about MFA deployment. "We have MFA" is frequently treated as a statement about phishing resilience. For this attack class, it isn't. Organisations that have completed MFA rollout and consider the phishing risk substantially mitigated should review whether that assessment was made before or after device code phishing became a commodity offering.
For organisations that cannot yet disable device code flow entirely, Entra sign-in logs provide the primary detection surface. Log entries for device code authentication carry authenticationProtocol: deviceCode and originalTransferMethod: deviceCodeFlow -- fields not present in conventional interactive sign-in events. Treat any unexpected occurrence as an indicator warranting investigation.
A tighter signal, specific to commodity kit behaviour: the attacker controls the client_id value submitted to the device authorisation endpoint, and off-the-shelf PhaaS kits overwhelmingly impersonate legitimate Microsoft first-party applications rather than registering their own. The reason is straightforward -- first-party App IDs appear in Entra telemetry as known Microsoft applications, bypassing the unverified-publisher detections that catch conventional OAuth phishing. Two App IDs are consistently observed across documented device code phishing campaigns:
29d9ed98-a469-4536-ade2-f981bc1d605e -- Microsoft Authentication Broker, the primary client_id observed in EvilTokens, Tycoon 2FA, and Storm-2372 campaigns. Tokens issued against this client can be used to register attacker-controlled devices in Entra ID and, in the most serious cases, obtain Primary Refresh Tokens -- the most privileged token class in the Azure OAuth schema.d3590ed6-52b3-4102-aeff-aad2292ab01c -- Microsoft Office, a longer-established choice in the original device code phishing playbooks and still in active use.The compound hunting query for Sentinel:
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where AppId in (
"29d9ed98-a469-4536-ade2-f981bc1d605e",
"d3590ed6-52b3-4102-aeff-aad2292ab01c"
)
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress,
AppId, UserAgent, RiskLevelDuringSignIn,
ConditionalAccessStatusA successful authentication (ResultType == 0) against either of these App IDs via device code flow, originating from a VPS, commercial hosting provider, or anomalous ASN, is a strong indicator of active compromise. UserAgent strings python-requests, node, or undici against these App IDs in non-interactive sign-in logs are direct fingerprints of known kit automation backends.
Organisations with legitimate device code flow dependencies should baseline their expected App IDs, user populations, and geographic origins, and alert on anything outside that profile. Unauthorised device registrations in Entra ID following a device code event are a high-priority indicator requiring immediate investigation -- particularly in the context of the Microsoft Authentication Broker client_id, where the post-compromise escalation path runs through Primary Refresh Token theft and Entra device registration to a persistent, phishing-resistant foothold that survives subsequent Conditional Access hardening.
If a compromise is confirmed: revoke sign-in sessions explicitly via revokeSignInSessions -- password reset alone does not close this. Audit Entra ID for unauthorised device registrations. Review OAuth application consents for anything registered during or after the compromise window. Check for mail forwarding rules. Assume mailbox contents, contacts, and OneDrive files were accessed.
Storm-2372 in mid-2024. Public disclosure February 2025. Financially motivated adoption by October 2025. EvilTokens as a service by February 2026. 340+ organisations compromised within weeks. Kali365 in April 2026. FBI PSA in May 2026.
That timeline is not a surprise. It is the standard commoditisation arc for any effective technique: state actor develops, researchers document, criminal ecosystem packages, script kiddies deploy. The gap between "documented in threat intelligence" and "available as a Telegram subscription" is now measured in months.
The Conditional Access policy that blocks device code flow was available before Kali365 existed. It remains available now. The organisations that will appear in the next IC3 report are, with some exceptions, ones where the audit didn't happen and the policy wasn't written.
The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy—with particular focus on Isle of Man jurisdiction and Crown Dependency issues.
Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.
