The Kratos Phishing Kit Takedown: 200 Servers Gone, 1,800 Copies Still Out There

On 20 July 2026, the Frankfurt public prosecutor's cybercrime unit and Germany's Federal Criminal Police Office announced they had taken more than 200 servers offline. Those servers ran Kratos, a phishing-as-a-service platform that Microsoft Threat Intelligence tracks as SneakyLog and that investigators estimate was behind roughly 15,000 Microsoft 365 phishing campaigns a month. Indonesian authorities arrested the man identified as its developer and operator, with support from US law enforcement.

It is a genuinely significant disruption. It is also, for defenders, an incomplete one — and the incomplete part is the part worth planning around. Investigators put the subscriber count at roughly 1,800, and those subscribers already have the code. The servers are gone; the kit is not.

What Made Kratos Effective

Kratos did not descend from nowhere. Trend Micro had tracked its predecessor, Sneaky2FA, since December 2024, watching it evolve into the Kratos platform. Along the way it accumulated the features that make modern credential phishing hard to catch:

• Session cookie theft, not just password theft. The BKA's description is blunt about why this matters: the stolen cookie alone is enough to walk past two-factor authentication and into the account as the user. Everything else in the kit exists to serve that outcome.
• Two operating modes. ANY.RUN's reverse engineering identified a plain PHP mode that harvested static credentials from a spoofed page, and a Node.js reverse proxy mode that relayed the victim's login to Microsoft as it happened and captured the resulting post-MFA session token. Subscribers chose the mode based on the target.
• Browser-in-the-browser windows, added in November 2025 — fake login popups rendered inside the page, which defeat the "check the address bar" advice most user training relies on.
• Cloudflare Turnstile challenges placed in front of the phishing page, which blunt automated crawling and sandbox analysis and slow down takedown requests.
• Legitimate services as intermediary hops. Real SharePoint, OneDrive, Canva, Tilda, and Microsoft Forms links were used as the first click, so the URL a user sees and a mail gateway inspects belongs to a service the organization already trusts.
• Exfiltration through Telegram bots or email, with stolen data POSTed to attacker endpoints named next.php and save.php.

Microsoft's own reporting gives a concrete example of what a campaign looked like. On 10 February, it caught operators sending tax-themed emails to roughly 100 organizations, mostly in the United States across manufacturing, retail, and healthcare. Each message carried a W-2 document with a QR code personalised to the recipient, leading to a fake Microsoft 365 sign-in page.

The Artefacts That Survive the Takedown

Because subscribers keep the code, the kit's fingerprints remain useful. Two published artefacts are specific enough to hunt for directly:

• The paired asset files barr.svg and lg.svg. ANY.RUN's analysis found this combination present in the large majority of Kratos sessions. Two SVG files with those names loading together is not something a legitimate Microsoft sign-in flow does.
• POST requests to next.php or save.php. These are the exfiltration endpoints. A browser posting form data to either path, in the context of what looked like a Microsoft login, is the moment credentials left the building.

Both are worth a retrospective query across proxy, web filter, and endpoint telemetry, not just a forward-looking detection rule. Kratos ran campaigns at volume since late 2024, with authorities placing victim numbers in the hundreds of thousands — the probability that your logs contain a hit predates the takedown by a long way.

Why "We Have MFA" Is No Longer an Answer

The reason AiTM kits proliferated is that they turn multi-factor authentication into a step the attacker proxies rather than a barrier they have to break. The victim receives a real prompt from Microsoft, approves it legitimately, and the reverse proxy pockets the resulting session token.

That changes the incident response question from "was the password stolen" to "was a session stolen," and the two have different remediation paths:

• Credential-only compromise — the PHP mode. A password reset and an MFA configuration review close it out.
• Session compromise — the reverse proxy mode. A password reset changes nothing on its own. The session must be explicitly revoked, or the attacker continues to hold a valid token issued before the reset.

Microsoft has been notifying affected users and draws exactly this distinction in its guidance, along with the longer-term recommendation: move high-value accounts to phishing-resistant sign-in methods such as FIDO2 or WebAuthn, which cannot be relayed by a proxy in the first place.

What to Do in the Next Two Weeks

1. Hunt the published artefacts retrospectively. Query for barr.svg and lg.svg loading together, and for POSTs to next.php and save.php, across as much log retention as you have.
2. Review sign-ins for token anomalies, not just failed passwords. A successful authentication from an unfamiliar address, immediately following a legitimate MFA approval from the user's normal location, is the shape an AiTM compromise leaves behind.
3. Revoke sessions on any suspicion, rather than resetting passwords and closing the ticket. Make session revocation a default step in your phishing playbook instead of an escalation.
4. Check inbound mail for trusted-service hops. SharePoint, OneDrive, Canva, Tilda, and Forms links are not inherently suspicious, which is the point — so evaluate where they redirect rather than what domain they are on.
5. Prioritise phishing-resistant authentication for the accounts that matter. Finance approvers, administrators, and executives are where token theft converts into fraud.
6. Expect a successor. The subscriber base is intact and it is looking for a new platform. Detection built around the technique — proxied sign-ins, session token anomalies, redirect chains through trusted services — outlives detection built around the Kratos brand.

Enrichment for the Domains and URLs That Turn Up

Retrospective hunting on a campaign this large produces a long list of URLs and domains, most of them dead by now and some of them still live on subscriber-run infrastructure. Sorting that list is the work.

• Run the landing pages and redirect targets through the URL scanner to follow the full hop sequence — kits like Kratos deliberately hide the final destination behind legitimate first-hop links, so the URL in the email is rarely the URL that matters.
• Check the hosting infrastructure with domain intelligence and domain age. Redeployed kits tend to land on freshly registered domains, and registration age remains one of the cheapest discriminators available.
• Use DNS history to see whether a domain has been repointed since your logs recorded it, which is common when subscribers migrate infrastructure after a takedown.
• Push the whole extracted list through bulk lookups instead of triaging by hand, then feed confirmed-malicious infrastructure into the blocklist so the same domains cannot succeed on the next attempt.
• Wire the enrichment into your email security and SIEM workflows through the API, so a reported phishing message arrives at an analyst's queue with the redirect chain and reputation already resolved.

The Structural Lesson

Takedowns work on infrastructure and operators. They do not work on distributed copies of a codebase held by 1,800 paying customers, and they do not work on a technique. Kratos itself was the descendant of Sneaky2FA; something will be the descendant of Kratos.

The defences that carried over from Sneaky2FA to Kratos are the ones worth investing in now: treating session tokens as credentials, revoking rather than resetting, moving critical identities to authentication that cannot be proxied, and enriching redirect chains rather than trusting the first domain in the link. Those hold regardless of which brand is selling the kit next quarter.