Sign in Subscribe
the-docket

The Docket: Kratos Shows Phishing-as-a-Service Is Identity Infrastructure

The Kratos takedown shows phishing is now rented identity infrastructure, not just deceptive email.

The Docket: Kratos Shows Phishing-as-a-Service Is Identity Infrastructure

BKA and ZIT say law enforcement dismantled Kratos, a phishing service supported by more than 200 servers and used by more than 1,800 criminal franchisees. That is not a small phishing kit with a new name. It is a reminder that stolen identity now has infrastructure, customers, subscriptions, and a legal record.

The useful question is not whether phishing remains dangerous. Everyone already knows that. The useful question is whether an organization can prove what happened after a fake Microsoft login page worked.

What Happened

Germany's Federal Criminal Police Office and the Frankfurt public prosecutor's cybercrime unit said they worked with U.S. law enforcement and Indonesian authorities to disrupt the central Kratos infrastructure. BKA said Indonesian authorities arrested the developer and technical administrator, and police action disabled more than 200 Kratos servers.

The scale matters because it changes the control story. BKA described Kratos as a digital kit for creating and managing convincing Microsoft authentication pages. The service then rented that capability to other criminals, a model BKA explicitly called phishing-as-a-service.

According to BKA, investigators identified about 850 victims across 35 countries, particularly in Europe and the United States. Authorities also said the group generated more than 300,000 euros since 2024 and that more than 1,800 criminal franchisees used Kratos to run about 15,000 phishing campaigns per month.

Those numbers do not prove every campaign succeeded. They do prove something else: credential theft has a distribution channel. When a criminal service can package infrastructure, payment, templates, and campaign operations for customers, the victim organization's problem does not end at the inbox.

The Operator Lesson

Phishing-as-a-service turns identity compromise into a rented business process. The buyer does not need to build the kit, manage the infrastructure, or understand every authentication detail. The buyer needs access to the service and a target list.

That creates a different legal and operational burden for defenders. A company responding to this kind of campaign should not stop at user-awareness records or a password reset ticket. It needs tenant evidence: sign-in logs, session activity, token behavior, mailbox rules, OAuth grants, device state, and the closure memo that explains why the account is safe again.

Trend Micro's Kratos analysis sharpens that point. The company described Kratos as an evolution of Sneaky2FA, an adversary-in-the-middle phishing kit that targeted Microsoft 365 accounts. Trend Micro says Sneaky2FA relayed live authentication sessions and could capture credentials and session tokens as they passed through.

That claim should stay attributed to Trend Micro, not stretched into a universal statement about every Kratos campaign. But the defensive lesson is sound: MFA reduces risk, but it is not the entire control. If the attack path can involve live authentication flows or session material, the response has to include session revocation, token abuse review, and tenant-level evidence.

This is where many organizations lose the thread. They treat phishing as a human error problem. Kratos shows why that framing is too small. The real issue is whether the identity plane can absorb a rented criminal service without leaving persistent access behind.

What to Do This Week

If your organization sees Microsoft-themed phishing tied to rented infrastructure, treat it as an identity incident until the evidence says otherwise.

  1. Pull sign-in logs for targeted users, especially impossible travel, unfamiliar devices, suspicious user agents, and abnormal application access.
  2. Revoke sessions for suspected accounts and document when revocation happened.
  3. Review mailbox rules, forwarding settings, delegated access, and OAuth application grants for persistence.
  4. Validate conditional-access coverage for high-risk users, privileged users, and external access paths.
  5. Preserve phishing indicators, user reports, affected-message samples, and tenant logs before retention windows close.
  6. Check whether phishing-resistant authentication, token protection, or device-bound session controls can reduce token replay risk for sensitive roles.
  7. Write the closure memo in evidence language: what was checked, what was found, what was revoked, and why the organization believes the identity risk is contained.

That last step is not paperwork theater. It is the difference between saying "we trained users" and proving the organization could investigate a professional identity-compromise service.

Sources

Read next