← All field notes
ransomwareALPHVBlackCatESXiactive directoryfor responders

ALPHV/BlackCat: from a stolen identity to domain-wide, hypervisor-wide ransomware

ALPHV (BlackCat, Noberus) runs a Rust encryptor that hits Windows and VMware ESXi/Linux, exfiltrates first, and extorts three ways. The trap: resetting AD does not touch the hypervisors, so the VMs still encrypt.

ALPHV, also tracked as BlackCat and Noberus, is one of the more capable ransomware operations still active. What makes it worth studying is not a single clever exploit. It is that the crew built a Rust encryptor that runs on Windows and on VMware ESXi/Linux, and they wrap the encryption in triple extortion. If your incident playbook treats this as a Windows problem, you will reset the wrong things and still lose the datacenter.

How it works

Initial access is unglamorous and effective: exploit a public-facing application (T1190) and reuse valid accounts (T1078). No dropper needed when a working login is on offer. From there the operators escalate by bypassing User Account Control (T1548.002) and manipulating access tokens (T1134) to reach an elevated context, then work toward Domain Admin.

Before anything is encrypted, they disable endpoint tooling (T1562.001) and steal data. The ExMatter-style exfiltration archives sensitive shares and pushes them out to attacker storage. Only then do they distribute the encryptor, and they do it with legitimate remote-management tooling and PsExec (T1569.002) rather than exotic malware, because those tools are already trusted in your environment. Recovery is inhibited on the way out (T1490), and the encryption itself is the impact event (T1486).

Why it goes org-wide, including the ESXi blind spot

The Rust encryptor is the multiplier. A single cross-platform binary detonates against Windows servers and against ESXi hosts, where it encrypts virtual disks directly on the hypervisor. One host encrypts every VM it runs, so a handful of ESXi detonations can take out an entire virtual estate in minutes.

Here is the part responders miss under pressure. ESXi hosts and vCenter authenticate outside the Windows identity plane. They have their own local accounts, their own management network, and in most shops they are not domain-joined. So when the incident kicks off and the instinct is to reset AD, rotate Domain Admin, and roll krbtgt, none of that touches the hypervisors. The operator’s path to vCenter does not run through Kerberos, so cutting Kerberos does not cut it. You can do a textbook AD containment and watch the encryptor detonate on ESXi anyway because you never addressed the plane it was actually staged on.

How to detect

The pre-stage has a signature. Watch for endpoint protection being disabled on servers at the same time a fresh binary is pushed by remote-management tooling or PsExec, and watch for that distribution reaching the vCenter/ESXi admin network for the first time. Any one of those looks like administration. Together, with a new cross-platform executable, they are imminent ransomware. Correlate the elevated session back to a host that was itself reached from a public-facing app, and you have the chain.

For the theft, the authoritative signal is egress: proxy and DLP records of large, often asymmetric-encrypted uploads to unfamiliar storage. That is your exfiltration scope, and in triple extortion it is the real exposure.

Contain and shut it down

Containment is two fronts, run in parallel, before detonation.

First, cut the Windows/AD foothold: isolate the involved hosts, reset the compromised accounts, roll krbtgt, revoke the elevated sessions, and remove the staged payload.

Second, and separately, isolate and harden the hypervisor plane: enable ESXi lockdown mode, cut management-network access to vCenter and the hosts, and rotate the ESXi and vCenter local credentials. This is the step an AD-only response skips, and it is the one that actually denies the encryptor its highest-value target. Treat ESXi/vCenter as its own identity domain, because it is one.

Durably, close the loop on every link: patch and require MFA on the public-facing entry, make EDR tamper-proof so it cannot be switched off, tier admins and alert on UAC and token-manipulation escalation, and segment the ESXi/vCenter plane behind its own credentials and MFA off the Windows domain.

On impact, remember that triple extortion decouples the breach from the encryption. The data was taken before the encryptor was staged. Even if you avert every detonation, obligations follow the scoped stolen data by type and jurisdiction, and you should plan for leak-site and DDoS/customer-harassment pressure independent of any ransom decision. Paying does not discharge notification duties or guarantee deletion.

Practice it

We built this as an Active Directory scenario in GraphLattice Range: the identity foothold, the escalation, the ExMatter-style theft, and the moment where the encryptor is staged against both Windows and ESXi. The exercise forces the two-front containment call and makes the hypervisor blind spot obvious before it costs you the datacenter.