Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Phishing-as-a-service and MFA bypass: what identity teams should do


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 12387
Topic starter  

TL;DR: Authorities dismantled the Kratos phishing network after more than 1,800 cybercriminals used it for nearly 15,000 campaigns monthly, while researchers also showed its AitM mode could intercept session cookies and bypass MFA, according to SentinelOne and BKA. The lesson is that identity controls must account for session theft, not just password capture.

NHIMG editorial — based on content published by SentinelOne covering the Kratos phishing network takedown and related identity abuse patterns

By the numbers:

  • 1, ore than 1,800 cybercriminals utilized the platform to launch nearly 15,000 phishing campaigns monthly since late 2024.
  • Authorities seized over 200 servers to render Kratos’ global network entirely inoperable.

Questions worth separating out

Q: How should security teams defend against phishing kits that steal MFA tokens and cookies?

A: Security teams should defend by adding controls that evaluate the login transaction itself, not just the password or one-time code.

Q: Why does session-cookie theft create more risk than password theft alone?

A: A stolen session cookie can already satisfy the checks that MFA was meant to strengthen, so the attacker may not need to log in again.

Q: What do security teams get wrong about phishing-as-a-service?

A: They often treat it as an email problem when it is really an identity access problem.

Practitioner guidance

  • Harden session governance Shorten session lifetime, enforce token binding where possible, and test how quickly revoked credentials and cookies disappear from active applications.
  • Detect AitM phishing patterns Add detections for sign-in flows that proxy genuine login pages, unusual cookie reuse, and access from freshly authenticated sessions that jump geography or device context.
  • Rehearse mailbox compromise containment Create response steps for Business Email Compromise that include session invalidation, mailbox rule review, OAuth app checks, and secondary phishing suppression.

What's in the full analysis

SentinelOne's full analysis covers the operational detail this post intentionally leaves for the source:

  • The full reverse-engineering notes for the Kratos toolkit, including the two functional modes and how the AitM proxy works.
  • Campaign specifics on tax-themed lures, QR-code delivery, and the industries targeted in the February activity.
  • The law-enforcement angle around Operation Olympus Blade, including seizure scope and disruption mechanics.
  • The write-up on how the kit code outlives infrastructure takedowns and what that means for rebranding risk.

👉 Read SentinelOne's analysis of the Kratos phishing network takedown →

Phishing-as-a-service and MFA bypass: what identity teams should do?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11961
 

Phishing-as-a-service turns identity abuse into a repeatable supply chain: Kratos shows that the threat is no longer a single malicious email but a rented access factory. Once credential theft and AitM interception are productised, defenders face scale, reuse, and fast rebranding after disruption. The practitioner implication is that phishing defence must be measured as a programme against industrialised account compromise, not as isolated user awareness.

A few things that frame the scale:

  • 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.

A question worth separating out:

Q: Who is accountable when compromised cloud identity is used for business email compromise?

A: Accountability sits with the teams that govern identity scope, credential exposure, and service permissions across the cloud estate. IAM, security operations, and platform owners all have a role, because the abuse path usually depends on a permission decision made long before the incident. Regulatory and internal controls only work if those ownership boundaries are explicit.

👉 Read our full editorial: Kratos takedown shows phishing-as-a-service still scales via identity abuse



   
ReplyQuote
Share: