From a Microsoft-365 Kit to a Multi-Platform Operation
When the FBI's IC3 advisory described Kali365 in late May, the picture was a Microsoft-365-shaped one. Device-code abuse against Microsoft accounts was the named method, AI-generated lures and a rented dashboard were the named features, and we covered the productization story in our [earlier Kali365 brief](/articles/kali365-phishing-as-a-service-token-theft-fbi-brief). Arctic Wolf's June 2 follow-up reframes that picture. The operator did not stop at Microsoft. The same toolchain now targets a much broader set of identity providers, with a distinct regional cluster on top.
Arctic Wolf reports a 126-host cluster active between May 6 and May 27, 2026, sharing a common banner hash and overlapping infrastructure. Within that cluster, the team identified template variants impersonating Microsoft Outlook and Live, Okta SSO, Xerox DocuShare, and AWS-style endpoints, alongside a Russian-language set covering Mail.ru, Yandex Disk, Odnoklassniki, GMX, LiveDrive, and the state-backed MAX Messenger platform. Counted by host, the Russian-language templates make up the largest single language group in the report.
The pivot is consistent with how a maturing phishing-as-a-service operator typically grows. Once the underlying delivery and capture machinery is stable, adding a new branded login page is template work. Each additional template extends the addressable market for subscribers without changing the kit's core mechanics. The defensive consequence is that an organization which restricted device-code flow in Microsoft Entra and then moved on has only protected one of the providers Kali365 can now point at.
The MAX Messenger Flow Is Worth Reading Carefully
Most of the new templates are familiar in shape: a branded login page hosted on the kit's infrastructure, a victim arriving from an email lure, credential or token capture, and a redirect that lets the session look completed. The MAX Messenger flow Arctic Wolf describes is different and worth a closer look because of what it tells defenders about where mature kits are going.
The page presents itself as a prize-claim form. The visitor enters a Russian +7 phone number, and the kit triggers an authentic MAX login attempt for that number, which causes MAX's real backend to send a legitimate SMS one-time code to the victim's phone. The victim sees a real SMS from a real platform, types the code into the kit's form, and the operator replays the code against MAX inside the still-open authentication window. The 2FA gate is defeated end-to-end because the entire authentication interaction is mediated by the attacker in real time.
This is the pattern that adversary-in-the-middle kits established for web logins, ported to a phone-number authentication path on a messaging platform. The lesson generalizes. Wherever an identity provider's primary authentication is "send a code, prove you have the device that received it," a kit that can prompt the victim to enter the code into an attacker-controlled form will defeat the gate. The presence of SMS OTPs in the chain does not slow the kit down; it is how the kit completes the flow.
Where Kali365 Sits Inside a Broader Cluster
Proofpoint's May 13 research, published before Arctic Wolf's expansion report, frames the wider environment Kali365 is part of. The team reports observing roughly seven nearly-identical device-code phishing variants in a single ten-day window in April 2026. Their assessment is that AI-assisted kit generation, what they label "vibe coding" in describing the related EvilTokens platform, has made it cheap for an operator to spin up a lookalike kit and put it on Telegram.
EvilTokens itself is positioned as a distinct PhaaS offering, advertised on Telegram in February 2026 and tied by Proofpoint's reporting to the Tycoon 2FA operator's pivot after infrastructure disruption earlier that month. Proofpoint notes that it is not always possible to tell whether nearly-identical variants are forks of a single platform sold to multiple buyers, independent AI-assisted reimplementations of a popular pattern, or both at once. The honest read is that the device-code phishing space now has a cluster of competing or cooperating kits rather than a single platform that defenders can model.
That broader picture matters for Kali365 specifically. The operator is not the only one running this pattern, and the kit's value to a subscriber is no longer only the technical mechanism. It is the breadth of identity-provider templates, the dashboarded operations, and the readiness to rotate lures when one wave is recognized. That combination illustrates how cheap lure rotation is for the operator and how unreliable a lure-keyword filter is as the defender's primary signal.
Detection That Travels Across Providers
The first move is to separate confirmed technique from exposed surface. Arctic Wolf confirms Kali365 device-code abuse against Microsoft Entra ID, and separately documents Okta SSO and Xerox DocuShare impersonation templates inside the same infrastructure cluster. Okta supports OAuth device authorization, so Okta device-flow policy belongs in the governance review, but the public Arctic Wolf report does not show Kali365 using an Okta device-code flow. Treat Xerox DocuShare as a brand/template and account-capture risk in this report unless additional evidence shows OAuth or device-code abuse against DocuShare itself. Our [earlier note on device-code phishing mechanics and detection](/articles/device-code-phishing-walkthrough-and-detection) walks through what those sequences look like on Microsoft; apply that pattern to providers where device authorization is actually enabled and observable.
The second move is content-driven hunting where Arctic Wolf has named reusable patterns. The team calls out the C2 panel domain `panel.securehubcloud.com` as a high-confidence C2 to block at egress, and points to a recognizable kit phrase, `Preparing your secure document…`, as a hunt string in web telemetry and threat intel feeds. Both come from a vendor report that explicitly intends them for defender blocking; reproducing them here is part of pushing the kit's infrastructure off the network. Treat the named domain, its sibling subdomains, and the named phrasing as starting points for blocking and hunting, not as the entire indicator surface; the kit's hallmark is fast rotation and the IOCs will change.
The third move is exfiltration-channel awareness. Arctic Wolf reports that the kit's data exfiltration paths include a Telegram bot. Egress telemetry that surfaces unexpected outbound TLS to `api.telegram.org` from corporate networks gives a useful signal regardless of which template the kit was using or which provider was being impersonated that day.
The fourth move is identity-provider-agnostic session monitoring. The reusable defender capability is the ability to enumerate active sessions and refresh tokens across the identity providers in use, kill them under suspicion, and require reauthentication. That capability contains successful account capture regardless of whether the confirmed mechanism is Microsoft device-code abuse, a branded SSO credential page, or a real-time OTP relay like the MAX Messenger flow. Our [piece on phish-report to token revocation in sixty minutes](/articles/phish-report-to-token-revocation-60-minutes) describes a workable timing target for that capability.
What This Updates for Red Teams and Threat Trackers
For red teams, the practical scoping change is that a Kali365-style exercise should not assume a single brand. Realistic test scenarios should include a confirmed Microsoft device-code flow, an Okta-branded SSO scenario, and at least one non-Microsoft pretext where the defender's instinct may be to defer to a provider-specific incident process that has not been rehearsed. The exercise question is not only whether the captured token is detected. It is whether the response works consistently when the brand, provider, and capture mechanism change.
For threat trackers, the reusable observation is the operator's behavior, not the kit's current target list. Kali365 has now been documented expanding template coverage across at least nine recognizable platforms in a six-month operational window, with the most distinctive new flow targeting a regional messaging platform and reusing legitimate SMS OTPs against it. The pattern points to where the next expansion is likely: identity providers where the authentication is built around "send a code, prove possession of the receiving device" and where defender attention is provider-shaped rather than method-shaped.
The right framing on the kit at this point is procedural. Kali365 is not interesting because it bypasses Microsoft 365 MFA. It is interesting because it has demonstrated that the device-code phishing pattern transfers cleanly across identity providers, and because its operator has chosen to invest in that transfer rather than in technical novelty. Defenders who organize their controls around the pattern rather than around any one provider will hold up better than defenders who hardened Microsoft 365 and then went back to the previous quarter's priorities.