LockBit vulnerability

Ransomware vuln found and lost
(for a year)

Ukatemi Technologies

10/12/2022

Recent news informed us about LockBit developers who paid bounty to report weaknesses in the ransomware, related to VMDK and VHDX files:

“The bug was that it was possible to decrypt any vmdk or vhdx file for free, since the beginning of these files begins with zeros.” [Darkfeed]

We came across this exact vulnerability during an incident response job – about a year ago. Thanks to the understanding of it, we successfully recovered multiple virtual server disk files from a LockBit ransom event. Of course, we have not shared this information with the developers of the ransomware. We have not shared it publicly at all – more on that later.

It is important to clarify that the VHDX file format description is publicly available and we worked based on that. The incident revealed that the actual version of the ransomware only encrypted the first 4 KB of the file. When we discovered that precious files were affected, but only their first 4 KB were encrypted, we took a look on the definition of the format which can be found here.

The first 1 MB of the file contains 5 times 64 KB blocks and the bytes from 320 Kb to 1 MB are reserved. The first block contains:

• Signature (8 bytes): MUST be 0x7668647866696C65, which is a UTF-8 string representing “vhdxfile“.
• Creator (512 bytes): Contains a UTF-16 string that can be null terminated. This field is optional; the implementation fills it in during the creation of the VHDX file to identify, uniquely, the creator of the VHDX file.

The implementation MUST NOT use this field as a mechanism to influence implementation behavior; it exists for diagnostic purposes only. So the file header is not constant zeroes, but completely reproducible or replaceable.

An example for valid VHDX header which can be used to restore files encrypted with the old LockBit ransomware can be downloaded from here.

In case you have this problem, for a fast fix you can use the popular Linux utility “dd” to write over the header of your ransomware paralyzed file, so  dd if=valid_disk_file of=your_encrypted_disk_file bs=1 count=4096  – if we are correct (feel free to test this statement and reach us in case it doesn’t hold). This will only overwrite the first 4 kilobytes that were encrypted by the “old” LockBit.

KEY TAKEAWAYS

1. During the incident response, many cyber security experts work with the premise that most file formats have a very important header part in the first bytes of the file. This does not apply to many modern file formats (like VHDX), though, it is always worth to cross-check.
2. Thorough incident responders should always check the tactics of the attackers, and related technical documentation.
3. In-house IT teams are not always prepared for such tricky situations. That is alright, their job first and foremost is to understand their company’s core business and lay down a solid security basis for that. But in the meantime, ransomware is on the rise, it’s worth having a trusted partner with demonstrated expertise in this niche area of IT security.
4. If you have no experience in ransomware defense, the best strategy is to be cautious and regularly make backups! Seriously, do it now.

PUBLIC OR NOT?

Vulnerabilities in a ransomware are valuable pieces of information. The reason we have not published this one, was to prevent ransomware developers from fixing it. We only sent the information to trusted professional groups so that they can use it for defense purposes. Based on recent news, with acting responsibly, we managed to keep information from the bad guys for a year. Of course, there is no way of telling how much money was saved this way for users all around the world, but we would like to think than it is more than the ransomware developers paid for the bug.

Colleagues involved in the investigation of the incident [nicks]: boldi, ladig, tkh4ck, pepe, szigethy