What the FBI Actually Flagged
In May 2026 the FBI's Internet Crime Complaint Center issued a public service announcement about Kali365, a phishing-as-a-service platform first observed in April. The advisory is worth reading not because the kit invents anything, but because of what it documents: hundreds of attacks in a single month against organizations across North America and Europe, all running the same rented infrastructure.
Kali365 targets Microsoft 365 accounts and steals access tokens rather than passwords. That distinction is the whole story. A stolen password is a credential that multi-factor authentication is designed to backstop. A stolen access token is a session that has already cleared authentication, including the second factor. Once the token is captured, the additional code or app prompt no longer stands between the attacker and the account.
For a threat tracker, the useful record is not "a new kit exists." It is that token theft, which used to require an operator who understood OAuth and device-code flows, is now sold as a product to people who understand neither.
The Market Shift That Matters
The reported pricing tells you who the customer is. Arctic Wolf observed Kali365 renting for roughly $250 for thirty days or $2,000 for a year. That is not the cost structure of a bespoke operation. It is a consumer subscription aimed at attackers who want results without building tooling.
What the subscription buys is the labor that used to be the barrier. The platform provides AI-generated phishing lures, automated campaign templates, real-time tracking dashboards, and the token-capture machinery itself. A buyer does not assemble a credential-harvesting page, manage a reverse proxy, or hand-write a convincing message. They pick a template, launch, and watch a dashboard fill with captured sessions.
This is the same productization curve that adversary-in-the-middle kits followed before it. Each turn of that curve widens the pool of people who can run a technique and shortens the time from intent to a working campaign. The defensive consequence is that the *volume* of token-theft attempts rises even when the underlying method holds steady, because the method is no longer the scarce resource.
Why Token Theft Beats the Second Factor
The mechanism Kali365 leans on is a legitimate Microsoft feature: the device-code flow, which lets a device with limited input borrow an authenticated session from another device. In a normal use, you enter a short code on a phone or laptop to sign a smart TV or a CLI tool into your account.
In the attack, the victim receives a message that appears to come from a cloud service or collaboration tool, carrying a short device code and instructions to enter it at Microsoft's real verification page. Because the page is a genuine Microsoft URL, the usual tells are absent. There is no lookalike domain, no fake login form, and no password typed into a suspicious field. The victim authenticates to Microsoft as themselves, completes MFA as themselves, and in doing so authorizes the attacker's waiting device.
That is why awareness advice built around "check the URL" and "look for the padlock" does not engage here. The URL is correct and the connection is genuinely Microsoft's. The deception is not in the page; it is in the reason the victim was given to enter the code at all. We walked through the underlying mechanics in our earlier device-code phishing walkthrough; Kali365's contribution is to wrap that mechanism in a kit so the operator never has to understand it.
The Rented Dashboard
The tracking dashboard deserves attention because it changes the tempo of an attack. A captured token has a limited useful life, and a real-time view of incoming sessions lets an operator act inside that window. They can move from capture to mailbox access, OAuth app consent, or data exfiltration while the session is still valid, rather than discovering a stale token hours later.
The dashboard also makes scale manageable for an unskilled buyer. Hundreds of simultaneous targets are a spreadsheet, not a craft. Templated lures go out in bulk, and the operator works only the conversions the dashboard surfaces. The economics favor a wide, shallow campaign that needs only a small fraction of recipients to enter a code.
For defenders, the takeaway is about timing. If the attacker's advantage is a short, monitored window between token capture and abuse, then detection that arrives the next morning is detection that arrives after the account is already worked. The control that matters is the one that fires on the token event itself.
Detection and Response
Start by narrowing the surface. Device-code flow is genuinely useful for a small set of devices and tools, and genuinely dangerous everywhere else. Where the business can tolerate it, restrict or disable device-code authentication through conditional access, and constrain which users and locations may complete it. A flow that few legitimate users need is a flow whose every use is worth inspecting.
Then watch identity, not email. The signals that matter are token-centric: device-code redemptions, new OAuth grants, and sign-in sessions that appear from an unfamiliar device or location shortly after an inbound message rather than after a normal interactive login. A device-code redemption that is immediately followed by mailbox rule creation or an OAuth consent is a sequence, and the sequence is a stronger signal than any single event.
Red teams should use Kali365's existence as a scoping argument. If a $250 subscription puts token theft in reach of an unskilled actor, an access assessment that only tests credential-harvesting pages is testing yesterday's method. Exercises should prove whether the organization can see a token redeemed through a legitimate flow and revoke it before the session is abused. Blue teams should rehearse exactly that revocation: when a valid token is the loss, password resets are not the remedy, and the response that counts is killing the session and the grants it spawned.