Kali365 Phishing Kit Broadens Beyond Microsoft 365 to AWS, Okta, and Russian Platforms

A phishing kit that beats MFA without ever touching a password is dangerous enough against one platform. The news is that Kali365 now points that same trick at the cloud and single-sign-on providers that gate everything else.

EDEN PRAIRIE, Minn. — Kali365, the phishing-as-a-service platform the FBI warned about in May for stealing Microsoft 365 access tokens past multi-factor authentication, has broadened its target surface well beyond Microsoft, according to research Arctic Wolf published this week and coverage by Dark Reading on June 2, 2026.

Arctic Wolf describes the kit evolving from a purely Microsoft-focused tool into a broad account-compromise platform whose malicious hosts now impersonate AWS, Okta single sign-on, Xerox DocuShare, the German email provider GMX, and several major Russian services — among them Mail.ru, Yandex Disk, the social network Odnoklassniki, and the MAX messenger — alongside Microsoft Outlook and Microsoft Live.

What Happened

Arctic Wolf this week documented a significant expansion of Kali365, the phishing-as-a-service kit that the FBI's Internet Crime Complaint Center flagged in May 2026 for hijacking Microsoft 365 OAuth access tokens. According to the research, reported by Dark Reading on June 2, the kit has grown from a Microsoft-focused phishing tool into a broader account-compromise platform. Its malicious hosts now impersonate a wide range of services: Microsoft Outlook and Microsoft Live, Okta single sign-on, Xerox DocuShare, the German email provider GMX, Amazon Web Services naming conventions, and several major Russian platforms including Mail.ru, Yandex Disk, the social network Odnoklassniki, and the MAX messenger.

It is worth being precise about what is new and what is not. The novel development is the target surface — Kali365 is now aimed at cloud (AWS) and single-sign-on (Okta) identity providers, not just Microsoft email. The core technique is not new: device-code phishing was already Kali365's signature when the FBI warned about it in May. That technique abuses the OAuth 2.0 Device Authorization Grant, the flow designed for input-constrained devices such as smart TVs. Rather than steal a password, the attacker initiates a device-login request and socially engineers the victim into completing the authorization on the real identity provider; because the victim authenticates and approves through the legitimate IdP, the attacker receives a valid access token and multi-factor authentication is satisfied without the attacker ever holding the victim's password or device. Kali365 wraps this in AI-generated lures, automated campaign templates, real-time target-tracking dashboards and token-capture tooling, and sells it through Telegram.

Why AWS and Okta Are the Consequential Additions

Of the new targets, AWS and Okta are the ones that should focus a defender's attention, because of what sits behind them. An AWS account compromise is direct control of cloud resources — compute, storage, data, and the ability to spin up infrastructure on the victim's bill. An Okta compromise is arguably worse in reach: Okta is a single-sign-on hub, so a foothold there often federates out to dozens of downstream SaaS applications that trust Okta for authentication. In both cases the value of a captured token is multiplied by what the identity unlocks. Kali365 expanding from Microsoft email into these identity-and-cloud providers is therefore not a lateral move to an equivalent target; it is a move up the value chain, from one company's mailboxes to the identity fabric that gates an organization's entire SaaS and cloud estate.

Device-Code Phishing Defeats Credential-and-MFA Defenses by Design

The reason device-code phishing matters is that it sidesteps the defenses most organizations have invested in. Credential-capture detection, password-spray alerting, and even much of the value of multi-factor authentication assume the attacker is trying to obtain or replay a secret. Device-code phishing captures no secret: the victim genuinely authenticates, genuinely passes MFA, and genuinely approves a device — they have simply been tricked about which device they are approving. The result is a legitimately issued token in the attacker's hands. That is why this technique sits alongside the Tycoon2FA OAuth device-code variant that turns Microsoft's own login page against M365 and the FBI-flagged Kali365 Microsoft 365 token theft The CyberSignal first covered in May, and why the mitigation lives at the OAuth-flow design layer — restricting or disabling device-code grants, scoping them to specific apps and contexts, and treating any unexpected device-authorization prompt as a phishing event — rather than at the credential layer. Even phishing-resistant passkeys do not fully neutralize it, because the victim is not being asked for a credential at all.

Phishing-as-a-Service Scales With Subscribers, Not Skill

Kali365's Telegram distribution model is the part that turns a clever technique into a volume problem. By packaging device-code phishing with AI-generated lures, automated campaign templates and target-tracking dashboards, the kit lets low-skill operators run high-capability attacks, which means the number of Kali365-launched campaigns scales with the subscriber base rather than with any individual attacker's ability. That is the same phishing-PaaS evolution arc The CyberSignal has watched across the cycle — and it connects to the broader identity-and-token attack surface that includes the Meta AI support bot tricked into account takeovers, the Dashlane vault-download escalation, and the Microsoft Android token-isolation exposure. The AI-lure component also rhymes with the offensive use of generative tools documented in the GreyVibe campaign: commoditized AI is lowering the production cost of convincing phishing at the same time the kits lower the technical bar to deploy it.

Scope and Impact

The exposure is defined by the technique plus the newly targeted platforms. Any organization that uses AWS, Okta, or Microsoft 365 — which is to say most organizations — is now in Kali365's addressable target set, and the Russian-service additions (Mail.ru, Yandex Disk, Odnoklassniki, MAX) widen it toward Russian-speaking users and regions. Because the kit is subscription-distributed via Telegram, the realistic threat is not one sophisticated actor but a population of affiliates running templated campaigns, so defenders should expect breadth and volume rather than precision targeting. The verification caveat the brief flagged is worth carrying: the exact per-platform capability inventory comes from Arctic Wolf's analysis, and whether the FBI has issued a follow-up advisory beyond its May IC3 PSA should be confirmed before treating any government-update claim as current.

The defensive scope question is specific and answerable: does your environment permit OAuth device-code grant flows, and for whom? Many organizations have the Device Authorization Grant enabled by default without ever using it intentionally, which leaves the door Kali365 walks through standing open. The single highest-leverage scoping action is to determine where device-code flows are enabled across AWS, Okta and Entra, and to disable or tightly restrict them where they are not a deliberate requirement — a configuration change, not a product purchase, and one that closes the exact path this kit depends on.

Response and Attribution

For CISOs running AWS, Okta or hybrid SSO, the immediate work is to audit OAuth device-authorization flows: confirm whether device-code grants are enabled in each tenant, disable them where they are not strictly required, and where they are needed, restrict them to specific app contexts and trusted device populations and apply conditional-access policies that block device-code flows from anomalous source IPs or untrusted devices. Brief privileged users — administrators, finance, executive assistants — that any prompt asking them to 'enter this code on another device' should trigger out-of-band verification before they act. For SOC teams, hunt for anomalous OAuth device-code authorization events in AWS CloudTrail, Okta system logs and Microsoft Entra sign-in logs over the past 30 days, treat any successful authentication from a previously-unseen device during the active window as a Kali365 hypothesis, and pivot on Kali365 indicators — the impersonated-platform domains and kit signatures — as Arctic Wolf and the FBI publish them.

For identity-product security leaders, the generalizable lesson is that device-code phishing is now a documented, commoditized PaaS capability, so any identity provider that supports the OAuth Device Authorization Grant should assume it is in scope and design additional verification into that flow — out-of-band confirmation, geo-validation, and device-fingerprint checks. On framing, this is criminal phishing-as-a-service rather than a single named state or crime group, and the responsible read is that Kali365's reach now scales with its affiliate base; the board-level point is that identity-provider compromise is downstream of phishing-PaaS innovation, not of user password discipline, and the controls that matter are at the OAuth-flow and conditional-access layers.

The CyberSignal Analysis

Signal 01 — The Expansion Is Reach, Not a New Trick

It would be easy to write this up as 'Kali365 adds device-code phishing,' but that would be wrong, and the distinction matters for defenders calibrating their response. Device-code phishing was Kali365's signature from the start — it is why the FBI warned about it in May. What changed this week is the target surface: the same token-stealing technique now points at AWS, Okta, Xerox DocuShare and a roster of Russian services. The lesson is that mature phishing kits grow by broadening which identity providers they impersonate, not by reinventing their core mechanism, because the mechanism already works. Defenders should therefore not wait for a 'new technique' headline to act; the technique is stable and known, and the right move is to harden the OAuth device-code flow now, before the kit adds the next platform.

Signal 02 — Identity Providers Are the Real Prize

The choice of AWS and Okta as expansion targets is a statement about where value concentrates. Attackers are not chasing individual mailboxes anymore; they are chasing the identity and cloud-access fabric that everything else hangs off. An Okta token can federate into dozens of SaaS apps; an AWS token is direct infrastructure control. For defenders, the implication is to treat identity-provider and cloud-IdP compromise as a top-tier scenario in the threat model and to instrument it accordingly — conditional access, anomalous-token-issuance detection, and tight scoping of any authentication flow, like device-code, that can produce a token without a traditional login. When the phishing kits move up the value chain to the identity layer, the defenses have to be densest exactly there.

Signal 03 — PaaS Turns a Technique Into a Volume Problem

The most durable thing about Kali365 is not any single capability but its business model. Selling device-code phishing through Telegram, bundled with AI-generated lures and automated dashboards, decouples attack volume from attacker skill: a subscriber who could never build this tooling can now run it at scale. That changes the defender's planning assumption from 'how good is the adversary?' to 'how many adversaries can afford the subscription?' — and the answer trends toward many. The practical consequence is that the defenses cannot rely on attacker error or sophistication gaps; they have to be structural and universal, applied to every identity provider in the estate, because the kit guarantees that unsophisticated operators will keep probing the same OAuth flows against the same platforms until something gives.

Sources