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:
0x7668647866696C65, which is a UTF-8 string representing “
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.
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]:
Copyright 2023 Ukatemi Technologies Plc.