Nitrogen Ransomware Bug

Nitrogen ransomware was derived from the previously leaked Conti 2 builder code and is similar to other Conti-based ransomware, but a coding mistake in its ESXi malware causes it to encrypt files with the wrong public key, irreversibly corrupting them. In practice, this means even the threat actor can’t decrypt affected files. If victims don’t have viable backups, they have no way to recover ESXi-encrypted servers. Paying a ransom won’t help in these cases, because any decryption key or tool the attacker provides won’t work.

Public/private key encryption typically follows these operations:

    1. The malware is run on a server full of files.
    2. For each file, the malware randomly generates a private Curve25519 key and its corresponding public key.
    3. The malware performs a key exchange between the file’s private key and the malware’s master public key, producing a shared secret.
    4. The shared secret is used as a ChaCha8 key to encrypt the file contents.
    5. The malware saves the file public key to the file footer.

Public/private decryption typically follows these operations:

    1. A decryption executable is run on a previously encrypted server full of files.
    2. The decryption tool contains the master private Curve25519 key that corresponds to the master public key used for encryption.
    3. For each file, the decryption tool performs a key exchange between the master private key and the file public key saved in the footer, producing the same shared secret used for encryption.
    4. The shared secret is then used as a ChaCha8 key to decrypt the file contents.
    5. The file is decrypted.

The Nitrogen ESXi Bug

Within the Nitrogen ESXi malware, the public key is stored as a stack variable at offset rsp+0x20 (shown below).

However, after the public key is loaded, another variable is stored at rsp+0x1c. It’s a QWORD, so it takes up the 8 bytes from rsp+0x1c to rsp+0x24. That means 4 bytes of the public key are overwritten. This appears to be a clear mistake by the malware developer.

This is what the public key looks like in memory before the instruction at `0x401890` is executed

And this is what it looks like after it’s executed:

Note the 4 bytes that have been replaced with 0x00s.

Because of this bug, the corrupted public key is used in the key exchange to encrypt each file. Normally, when a public/private Curve25519 keypair is generated, the private key is generated first, and the public key is derived from it. Here, the corrupted public key was not derived from any private key. It’s a malformed key produced by accidentally overwriting part of an otherwise valid public key. The outcome is that no one actually has the private key corresponding to the corrupted public key, so files encrypted using it can’t be decrypted by any means, including by paying a ransom. The threat actor themselves will be unable to decrypt affected files, even in a controlled test.

Organizations impacted by Nitrogen ransomware must be extremely careful when evaluating recovery options. Any ESXi-encrypted files without viable backups should be analyzed alongside the specific malware sample used for encryption to confirm their status and avoid relying on decryption that will never work.

Learn more about current ransomware attack vectors here.

 

Similar Blog Posts
Business | January 12, 2026
Business | November 19, 2025
Business | October 3, 2025
Stay up to date on the latest tips and news
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam’s Privacy Policy
You're all set!
Watch your inbox for our weekly blog updates.
OK