Kratos Is Gone; Its Buyers and Users Remain
On July 20, 2026, Germany’s Federal Criminal Police Office (BKA) and the Frankfurt public prosecutor’s cybercrime unit (ZIT), working with United States law enforcement, dismantled the infrastructure behind Kratos, a phishing kit sold as a subscription to more than 1,800 criminal customers. More than 200 servers were taken offline. The developer and technical administrator was arrested in Indonesia. Investigators counted victims in the hundreds of thousands across more than 30 countries since late 2024.
Kratos was built to capture the session itself, along with the password. Security firm ANY.RUN, which tracked Kratos across three kit generations, found the kit impersonating Microsoft 365 exclusively, with roughly a third of observed targeting linked to the United States and a strong concentration in Spain and Southern Europe. Once a victim entered credentials on a fake Microsoft login page, the kit copied the session cookie issued immediately after, the token that tells Microsoft 365 the login already happened. That cookie moves past multi-factor authentication (MFA) without needing to defeat it, because the system never asks for a second factor twice inside the same session.
How Kratos Worked
The attack chain followed a consistent pattern. A phishing email, often already past corporate filters, carried a lure through a legitimate service like SharePoint, OneDrive, or Microsoft Forms, redirecting to the Kratos page itself. A Cloudflare Turnstile challenge screened out automated scanners before showing an animated “loading” screen over a blurred document, then the fake Microsoft login form. Victims got three password attempts before redirect to a decoy.
ANY.RUN identified two operator-side modes inside the kit’s own admin panel: a PHP-based static credential harvester, and a Node.js reverse proxy the panel describes as functioning with anti-bot protection and an admin dashboard, the adversary-in-the-middle (AiTM) mode. In that mode, the victim logs into the real Microsoft system through the attacker’s proxy, and the proxy captures the legitimate session cookie Microsoft issues in return. A password reset leaves this access intact, because the session was built on a real credential Microsoft itself issued, not on the stolen password.
The kit evolved across three generations, each identifiable by a distinct asset fingerprint. The dominant generation pairs two files, barr.svg and lg.svg, appearing together in 1,397 of ANY.RUN’s analyzed sessions and almost never separately, giving analysts a detection method with 90% recall and a near-zero false-positive rate.
Remediation, and Where It Points
ANY.RUN’s guidance to defenders splits along a clear line. For a basic credential harvester, a password reset combined with an MFA check closes the exposure. For confirmed or likely AiTM activity, a reverse proxy, a spoofed Microsoft login domain, or session and cookie relaying, the guidance changes: revoke active sessions and refresh tokens, because a password reset alone may not remove an attacker who already holds a live session.
ANY.RUN names the business consequences of that second scenario directly: trusted-account abuse, where attackers impersonate an employee to make fraudulent requests appear credible; financial fraud through access to invoices and payment conversations; exposure of SharePoint and OneDrive data and third-party information; and a longer, costlier incident response, since session-level access can outlive a password change. Their guidance to CISOs pushes further still, measuring time to confident attribution, not only time to detection, because linking related activity is what reveals full scale and business exposure.
That last point identifies the gap precisely. Revoking a session tells an attacker’s proxy connection to drop. It does not tell a response team which invoices that account approved, which suppliers trusted its messages, or which SharePoint sites it could reach before revocation. ANY.RUN’s recommendations describe those consequences without answering how a team determines them quickly, because that answer sits outside session and identity telemetry entirely.
To close that gap, response teams need a live, pre-built map of what every account can reach, before the incident, not assembled during it. That is the premise behind trusted runtime truth: a continuously sourced operational picture of assets, dependencies, ownership, and blast radius.
Protecting High-Priority Accounts, Checking Affected Systems
Answering which accounts matter most during an active incident requires a standing map between identities and the systems, applications, and data they can access, built before the incident, not assembled during it.
Two things need to already exist for that map to hold up under time pressure.
First, business criticality has to be attached to the account itself, not just to the server or application it logs into. An account tied to financial approval workflows or customer data carries different risk than a standard user account, even when both are compromised through the same campaign.
Second, the dependency chain outward from that identity needs documentation ahead of time: which applications, service accounts, and shared resources it touches, and what depends on those in turn. Without this, a team responding to a Kratos-style alert traces what one specific account can reach, account by account, while the session remains active.
Where ViVID’s Service Map Fits
A CMDB with service mapping becomes relevant in the response, not in the phishing itself, but at a specific point in that response. Once identity and session telemetry has confirmed which specific application or server a compromised account touched, Virima’s ViVID service mapping takes over from there. ViVID connects configuration items (CIs), servers, applications, network devices, and databases, into a visual map of what depends on what, sourced from discovery data.
Given a confirmed touchpoint, that map shows the downstream servers, dependent applications, and shared infrastructure connected to it, turning “what else does this affect” into a lookup rather than a live trace through documentation built after the fact.
The identity layer answers which account was compromised and what it logged into. The CMDB layer answers what is connected to that confirmed point once it is named. The two are sequential, not the same map, and the second cannot substitute for the first.
Kratos Is Gone; Its Buyers Are Not
Kratos’s takedown removed its servers and its administrator. The 1,800 customers who bought the kit remain, along with the technique itself, which researchers have linked to earlier products sold under different names. ANY.RUN’s data shows the kit shares hosting infrastructure with other AiTM phishing kits, including Tycoon, Sneaky2FA, and EvilProxy, distinct code, same underlying technique, available at subscription prices.
Session theft at the identity layer will keep happening. What determines the cost each time is how fast a response team can trace a confirmed compromise outward through the infrastructure it touches. That depends on documentation built long before the account is compromised.
To see how Virima helps IT and security teams map blast radius and maintain live dependency documentation, schedule a demo.
Frequently Asked Questions
How does a session cookie bypass MFA after a phishing attack?
Once a victim authenticates on a real Microsoft 365 login, through an AiTM proxy, Microsoft issues a session cookie confirming the login is complete. MFA already ran. The attacker captures that cookie and uses it directly, so no second factor is ever requested again during that session.
Why doesn’t a password reset remove an attacker’s access after an AiTM phishing attack?
In an AiTM attack, the attacker holds a session cookie Microsoft issued during a legitimate login, not the password itself. Resetting the password does not invalidate active sessions. Defenders must explicitly revoke active sessions and refresh tokens to cut off access.
What should IT teams do immediately when a Kratos-style phishing attack is confirmed?
Revoke active sessions and refresh tokens for the compromised account, do not stop at a password reset. Then trace which applications, shared resources, and downstream systems that account had access to. That second step requires pre-built dependency documentation; it cannot be reliably reconstructed during an active incident.
How does a CMDB help contain the blast radius of a compromised account?
A CMDB with service mapping shows which servers, applications, and shared infrastructure connect to a confirmed compromise point. Once the identity layer confirms which system was touched, the CMDB turns “what else is affected” into a lookup rather than a live investigation. The map must already exist, it cannot be built during an incident without slowing response significantly.
How does Virima’s ViVID service mapping support phishing incident response?
ViVID builds a visual dependency map of configuration items, servers, applications, network devices, databases, sourced from discovery data. When a specific compromised touchpoint is confirmed, ViVID shows every downstream system connected to it. This gives response teams a pre-built blast radius view rather than manual infrastructure tracing under time pressure.
