Nitrogen ransomware was derived from the previously leaked Conti 2 builder code, and is similar to Nitrogen ransomware, but a coding mistake in the ESXi malware causes it to encrypt all the files with the wrong public key, irrevocably corrupting them. This means that even the threat actor is incapable of decrypting them, and that victims that are without viable backups have no ability to recover their ESXi encrypted servers. Paying a ransom will not assist these victims, as the decryption key/ tool will not work.
Proper public/private key encryption progresses via the following common operations:
The malware is run on a server full of files.
For each file, the malware randomly generates a private Curve25519 key and its corresponding public key.
The malware exchanges the private key with its master public key, producing a shared secret.
The shared secret is used as a ChaCha8 key to encrypt the file contents.
The malware saves the file public key to the file footer.
Proper public/private decryption progresses via the following operations:
A decryption executable is run on a previously encrypted server full of files.
The decryption tool contains the master private Curve25519 key that goes with the master public key that was used for encryption.
For each file, the decryption tool exchanges the master private key with the file public key that was saved to the footer, which produces the same shared secret that was used for encryption.
The shared secret can then be used as a ChaCha8 key to decrypt the file contents.
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 is 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 then the public key derived subsequently based on the private key. The resulting corrupted public key wasn't generated based on a private key, it was generated by mistakenly overwriting a few bytes of another public key. The final outcome is that no one actually knows the private key that goes with the corrupted public key. Files that were encrypted with the corrupted public key can not be decrypted by any means, including by paying a ransomware. The threat actor themselves will be unable to decrypt the files in a test.
Organizations impacted by Nitrogent Ransomware encryption must be extremely careful when analyzing their recovery options. Any ESXi encrypted files that are without viable backups, must be analyzed in conjunction with the corresponding malware that encrypted them to ascertain their status.