Kali365 PhaaS Kit Hijacks Microsoft 365 OAuth Tokens and Bypasses MFA — What Healthcare Security Teams Need to Do Now

AI Security Series #42

On May 21, 2026, the FBI issued PSA alert I-052126-PSA warning organizations about Kali365, a Phishing-as-a-Service platform that hijacks Microsoft 365 accounts without ever touching a user's password — and defeats MFA in the process. Security firms had already documented hundreds of attacks in April alone across healthcare, finance, government, and education in North America and Europe. Every one of those victims was using MFA.

This one is worth reading carefully. The attack works by abusing a legitimate Microsoft authentication feature, the lure lands on a real Microsoft page, and the tokens it steals provide persistent access to Outlook, Teams, and OneDrive until explicitly revoked. The mitigations are specific and actionable — but require Identity/Entra ID configuration changes that many organizations haven't made yet.

What Kali365 Is

Kali365 is a PhaaS platform first observed in April 2026, distributed through Telegram for as little as $250 for a 30-day subscription ($2,000 annually), with payments accepted in cryptocurrency. It operates like a commercial SaaS product — tiered pricing, a reseller layer, and a client affiliate tier where purchased access to already-compromised accounts can be traded between subscribers. Arctic Wolf Labs documented a three-tier commercial structure: admin authors, reseller agents, and paying client affiliates. That last point matters: a criminal who never sent a single phishing email can purchase access to pre-compromised M365 accounts directly from the platform.

What Kali365 packages is an AI-generated phishing lure engine, automated campaign templates, real-time target tracking dashboards, and OAuth token capture capabilities — all in one subscription. The AI-generated lures are worth flagging specifically: they produce contextually convincing, grammatically clean phishing emails that mimic trusted enterprise services like DocuSign, SharePoint, OneDrive, and Adobe Acrobat Sign, stripping away the typos and formatting errors that user training traditionally teaches staff to spot.

How the Attack Works

The attack chain abuses the OAuth 2.0 Device Authorization flow — a legitimate Microsoft feature built for input-limited devices like smart TVs, conference room displays, and industrial terminals that can't easily display a browser. The device code flow works by generating a short code on one device that a user enters on a companion screen to authenticate. Kali365 hijacks that flow by making the attacker's application the "device" requesting authorization.

The four steps are straightforward:

Lure: The victim receives a phishing email impersonating a trusted cloud service, containing a device code and a link to microsoft.com/devicelogin — a real Microsoft URL.
Authorization: The victim navigates to the genuine Microsoft page and enters the code, believing they are completing a legitimate verification step. Because the page is real, standard URL-inspection defenses don't flag it.
Token Theft: Microsoft issues OAuth access and refresh tokens to the attacker's device. These tokens prove authentication without containing a password and don't trigger a new MFA challenge.
Persistence: The attacker accesses Outlook, Teams, and OneDrive using the captured tokens. In documented Arctic Wolf Labs incidents, attackers also created inbox rules to suppress security notifications and registered secondary devices against the victim's account to extend access beyond the initial token's expiration window.

The inbox rule behavior is particularly useful for detection: rules filtering emails containing words like "spam," "security," or "phishing" appearing in a user's mailbox without their knowledge are a near-universal post-compromise indicator across documented Kali365 incidents.

Why MFA Doesn't Protect Against This

This is the question most healthcare security teams will ask first, so it's worth being direct. MFA is not bypassed here — it's satisfied by the victim during the legitimate authentication flow. The victim completes MFA as intended. What the attacker captures is the resulting OAuth token, after authentication has already succeeded.

This also means phishing-resistant MFA — FIDO2 hardware keys and passkeys — does not protect against device code phishing. FIDO2 binds authentication to the legitimate domain, which stops adversary-in-the-middle attacks. But device code phishing doesn't put the attacker between the user and Microsoft. The victim authenticates directly with Microsoft, on a real Microsoft page, and the attacker's device receives the token as an authorized application. FIDO2 was never in the picture.

The lesson is not that MFA is useless — it still blocks the vast majority of credential-stuffing and password spray attacks. The lesson is that token-based persistence is now a primary attack surface, and the controls that address it live in Conditional Access and token policy, not the MFA configuration itself.

This Attack Didn't Start With Kali365

Kali365 is the commoditized version of a technique with a documented history. Proofpoint tracked a sharp increase in device code phishing beginning in September 2025, when state-aligned threat actors — including groups attributed to Russia — adopted the technique at scale against government targets. By October 2025, financially motivated criminal groups had followed. By February 2026, PhaaS tools like EvilTokens had fully commoditized the technique, and Huntress documented over 340 compromised organizations across five countries from a single related campaign. Kali365 is the current iteration — lower cost, more polished, with an AI lure engine layered on top.

The trajectory matters for risk modeling: this is not an emerging threat that might become relevant. It is an active, commoditized threat with documented healthcare victims and a $250 entry price for any attacker.

What This Means for Healthcare

Healthcare organizations face specific compounding risks from Kali365 that go beyond the general M365 account takeover scenario.

PHI and HIPAA Exposure

Microsoft 365 is deeply embedded in healthcare workflows — document sharing, clinical communications, billing, and patient administration all flow through M365 in most mid-to-large health systems. A compromised M365 account is not just an email breach. Depending on what the account holder can access, it can mean unauthorized access to PHI in SharePoint, clinical messaging in Teams, and billing data in OneDrive-linked systems. Under HIPAA, that triggers breach notification obligations, investigation timelines, and potential OCR enforcement — regardless of whether the initial compromise was the result of a sophisticated attack or a user entering a code on a real Microsoft page.

The AI Lure Problem

Healthcare security awareness training has historically taught users to identify phishing by spotting poor grammar, mismatched URLs, and suspicious sender domains. Kali365's AI-generated lures eliminate the grammar signal. The URL is real (microsoft.com/devicelogin). The sender domain can be a convincing impersonation of a cloud service. The only behavioral tell is that the email is asking the user to enter a device code — a workflow most clinical and administrative staff have never seen before and have no trained response to. This is a training gap that needs to be addressed specifically, not covered by existing general phishing awareness modules.

Shared Workstations and Kiosk Terminals

Healthcare environments have a higher-than-average density of shared workstations, nurse station kiosks, and clinical terminals — the exact device types that the OAuth device code flow was designed to support. This creates a tension: some of these devices may have legitimate dependencies on device code flow that need to be preserved when locking down the Conditional Access policy. Auditing before blocking is essential, and the audit list in healthcare is likely to be longer and more operationally sensitive than in other verticals.

BEC Risk from Compromised Clinical Accounts

Once inside Outlook, an attacker with a compromised clinical or administrative account can send internally-trusted emails from a legitimate address — requesting fund transfers, redirecting vendor payments, or initiating internal access requests that bypass normal scrutiny because they appear to originate from a known sender. BEC attacks originating from legitimately authenticated internal accounts are substantially harder to detect than external impersonation attempts.

Mitigation: Entra ID Configuration Changes

The FBI, Arctic Wolf, and Proofpoint align on the same primary mitigation: block device code flow via Conditional Access. The implementation has three tiers.

Tier 1 — Block Device Code Flow (Primary Control)

In Microsoft Entra ID (formerly Azure AD), create a Conditional Access policy targeting all users and all cloud applications that explicitly blocks device code flow authentication. Narrow exceptions should be scoped only to verified processes that genuinely require the flow — meeting room devices, shared kiosk terminals, and specific legacy clinical integrations identified during the pre-deployment audit.

Before enforcing the policy, audit existing device code flow usage in your tenant via Entra ID sign-in logs, filtering on the device code authentication method. In healthcare, expect to find legitimate dependencies in room booking systems, some EHR companion apps, and shared clinical workstations. Document each one, assess whether it can be migrated to a more secure auth flow, and define the minimum exception scope before going live.

Tier 2 — Block Authentication Transfer

Enable the authentication transfer block policy to prevent users from transferring authentication sessions from computers to mobile devices. This closes a secondary persistence path that Kali365 operators use after initial token capture.

Tier 3 — Token Protection

Enable Token Protection in Conditional Access (currently in preview for sign-in sessions). Token protection binds tokens to the device on which authentication occurred, making a stolen token non-portable — it cannot be replayed from the attacker's device even if successfully captured. This is the control that directly addresses the underlying mechanics of the Kali365 attack beyond just blocking device code flow.

Detection Priorities for Your SOC

If Conditional Access changes aren't immediate, the following monitoring signals should be in your Fusion Center detection queue now:

Entra ID sign-in events using device code flow from unfamiliar devices or locations
OAuth application registrations that are new, unrecognized, or registered outside normal change windows
Inbox rules created without user-initiated action — especially rules filtering on "security," "spam," "phishing," or "click"
Access to OneDrive or Teams from IP addresses inconsistent with the user's normal geolocation or device baseline
Refresh token grants with unusually long lifespans or repeated token refreshes outside business hours

The Bigger Picture

Kali365 is the clearest illustration yet of how AI is lowering the attacker skill floor in a specific and measurable way. The technical capability — device code phishing — existed and was being used by nation-state actors as recently as September 2025. What Kali365 adds is an AI lure engine that removes the last remaining behavioral tell (poor writing quality), packages the whole attack chain into a $250 subscription, and distributes it through Telegram. The result is a nation-state-grade identity attack available to any threat actor with a cryptocurrency wallet.

For healthcare security programs, the immediate action is the Entra ID Conditional Access work outlined above — audit device code flow dependencies, block the flow with scoped exceptions, enable authentication transfer blocks, and get token protection on the roadmap. The less immediate but equally important action is updating phishing awareness training to specifically address the device code phishing scenario. Most clinical and administrative staff have never been trained on what a legitimate device code prompt looks like versus a malicious one — because until recently, it wasn't a realistic threat vector for healthcare environments.

That gap is now closed. Kali365 made sure of it.

This is entry #42 in the AI Security Series.