Nitrogen's ESXi encryptor is broken, which means the ransom buys nothing

Coveware reports that the ESXi build of Nitrogen ransomware encrypts every file with a corrupted public key, one that was never derived from any private key ^[14][2][10]. That turns a negotiation into a dead end: for a victim whose ESXi hosts were encrypted and whose backups are not viable, there is no decryptor to buy, because no one, including the threat actor, holds the private half of the key ^[3][4][5].

The mechanics decide whether this is a temporary condition or a permanent one. As designed, the malware generates a random Curve25519 private key and matching public key for each file, exchanges the private key with its master public key to produce a shared secret, uses that shared secret as a ChaCha8 key to encrypt the contents, and writes the file public key into the footer ^[6]. Decryption runs the same exchange in reverse: the decryption tool carries the master private key, combines it with the file public key from the footer to reproduce the shared secret, and decrypts ^[7]. That design is sound. Nitrogen itself was derived from the leaked Conti 2 builder code ^[1].

The defect is in how the ESXi build handles memory. According to Coveware's analysis, the public key is held as a stack variable at rsp+0x20, and after it is loaded the malware stores a QWORD at rsp+0x1c ^[8]. Eight bytes starting at 0x1c run through 0x24, so they land on the first four bytes of the key ^[15]. After the instruction at 0x401890 executes, those four bytes are zeroes ^[9]. The mangled value is then used in the key exchange for every file, and because it was produced by overwriting bytes rather than by deriving from a private key, no private key for it exists ^[2][10]. Coveware's conclusion is blunt: files encrypted with the corrupted key cannot be decrypted by any means, including by paying, and the actor will fail a test decryption of them ^[11][12].

The practical effect on day one of an incident is a reordering, not just a new data point. The standard sequence of getting a proof-of-life decryption, pricing the downtime, and weighing the ransom against restore time collapses on the ESXi side, because the test decryption is the diligence and it will not work ^[12]. Coveware's own guidance is that organizations must be extremely careful in analyzing recovery options, and that any ESXi encrypted files without viable backups have to be examined together with the malware sample that encrypted them to establish their status ^[13]. That pairing is the work: matching the binary that ran on a given host to the files on that host, rather than treating a Nitrogen note as one uniform event.

Two things worth tracking. Coveware scopes the mistake to the ESXi malware and does not extend the finding to other builds, so a Windows-side decryptor claim is a separate question that still needs its own test ^[14]. And the fix is trivial for the developer, so the population of unrecoverable files is bounded by whichever version ran, which puts a premium on sample retention and hashing before a rebuild wipes the evidence ^[13]. One caution on the source: this is a single vendor writeup, and it is loosely proofed, misspelling the malware as "Nitrogent" in its closing advice ^[17].