In July 2026, a law-enforcement seizure banner replaced the login page of the Kratos phishing platform. German authorities announced that international investigators had disabled more than 200 servers and arrested its alleged developer and technical administrator in Indonesia. It was a significant disruption to a service that rented phishing tools to other criminals.
Two months later, Abnormal researchers reached and captured a Microsoft 365 credential-and-MFA harvester behind an operator panel branded “GOD.” The September investigation linked that panel to components also served by a live Kratos-branded panel. The finding points to a problem that extends beyond one name: reusable phishing components can remain useful after a service is disrupted.
Our research examines the code relationships behind that finding, the delivery route described in the September investigation, and the controls defenders can use across changing domains and panel names. The evidence connects software builds; it does not establish that the original Kratos operator resumed business.
Why Phishing Code Can Outlive a Service
Kratos sold access to a reusable toolkit. German authorities described a licensing business supported through a website and Telegram shop, with customers paying in cryptocurrency. The operators deploying phishing pages were separate from the supplier selling the tools. That distinction helps explain why disrupting central infrastructure and eliminating every deployed copy are different tasks.
Microsoft documented one example before the takedown: a February 2026 campaign sent tax-themed emails to approximately 100 organizations, primarily in the United States. Personalized W-2 documents contained QR codes leading to fake Microsoft 365 sign-in pages built with SneakyLog, which Microsoft also identifies as Kratos.
A separate October review of recovered Kratos-derived source showed software that does more than display a counterfeit password form. It contains requests to Microsoft sign-in services, branches for multifactor authentication (MFA), and functions for retaining cookie artifacts. Those implemented capabilities explain the risk of authentication relay and session collection. They do not establish successful account access in the September case.
The Evidence Behind the Code Relationship
On September 22, researchers compared publicly accessible files from two operator panels: one branded Kratos and another branded GOD. A stylesheet retrieved from the same path on both panels was byte-for-byte identical, including a shared modification to its font paths. Matching login-page behavior added evidence of a shared code relationship. The harvester was assessed separately as Shield-family software based on its structure and markers. These links connect components in a modular stack; they do not establish identical installations or a common operator.
The recovered October source provides a separate explanation for how copies can persist. Its modified licensing decision can allow the software to proceed without a successful response from the original licensing service. That supports continued use of an independent copy. It does not identify who modified or deployed it, or demonstrate a return of the original service. Shared assets remain useful research leads, but attribution requires additional evidence.
The name is a joke at the investigators’ expense
“Kratos” is the protagonist of the God of War games—and the story runs in three beats, all three of which have now happened here.
He becomes the God of War
Kratos kills Ares and takes his throne. → a platform is named Kratos.
Zeus runs him through with the Blade of Olympus
The weapon that kills Kratos. → the takedown is Operation Olympus Blade.
He claws out of the underworld and tears down Olympus
Kratos returns for the gods. → the console attacking you is branded GOD.
How Mail Routing Added Credibility
The September investigation also described an email route that bypassed the recipient’s published mail gateway. An unauthenticated message entered a subsidiary’s Microsoft 365 environment and was relayed toward its parent organization. The message acquired the subsidiary’s DKIM signature on the way out, making the onward message appear to come through authorized infrastructure. That signature authenticates the signing domain’s handling of the message; it does not establish that the original submission was legitimate.
The attachment was a 448-byte SVG, an image format that can contain script. Its script redirected the browser to the operator’s gate. The delivery route and the attachment mattered together: an apparently trusted message could lead to a phishing page without putting the destination in an ordinary email-body link.
Exposure Across Industries
Abnormal Intelligence identified more than 1,200 phishing messages associated with the GOD campaign across more than 100 organizations. Observed sectors included media, logistics and transportation, healthcare, education, technology, construction, manufacturing, and financial services. Media accounted for the largest share of messages, concentrated in two organizations. That concentration describes message volume; the wider distribution shows that the phishing extended across industries. These figures do not establish confirmed account compromise or the reach of the entire Kratos ecosystem.
The lures presented SVG attachments as business documents: EFT notices, ACH payments, settlement reports, incoming-payment confirmations, and faxed ACH receipts. Recovered attachments embedded recipients’ email addresses in their destination URLs to personalize the phishing flow. The subsidiary-to-parent forwarding route was one delivery opportunity within this broader campaign, rather than evidence that every targeted organization had the same mail configuration.
Protect the Mail Route and the Sign-in
The durable defensive clues are the route a message took, the behavior of its attachment, and the authentication activity that followed. A trusted sender domain or familiar-looking sign-in page is only one part of that investigation.
Three priorities follow from this combination of reusable phishing code and mail-routing risk:
Secure every inbound mail path. Review the parent and acquired tenants together. Microsoft distinguishes Direct Send, which uses a tenant’s own accepted envelope-sender domain, from other mail sent directly to an Exchange Online endpoint. Where mail should pass through a gateway, restrict inbound connectors to approved sources. Enable RejectDirectSend where appropriate after validating legitimate dependencies; it does not replace those connector restrictions.
Inspect attachments as well as links. Examine SVG script and redirect behavior alongside the message route and destination. The unusually small attachment in this case is an investigation clue, rather than a reliable size threshold or a sufficient basis to block every SVG.
Protect authentication and investigate session use. Require phishing-resistant authentication such as passkeys or security keys. After suspected interaction, review sign-in and resource-access logs, reset exposed credentials, and revoke relevant sessions where compromise is supported. Microsoft’s session-theft guidance highlights anomalous sign-ins, session reuse, and suspicious mailbox activity as investigation leads.
Kratos-derived code remained reusable after the takedown. Recognizing its delivery and authentication mechanisms gives defenders a more durable basis for response.