Lockbit ransomware – How to recover your data
Update: Lockbit patched this bug… however, if you are hit by the version 2.0, you can still try it, it might just work!
Lockbit is a “Ransomware as a Service” which means you can buy a powerful ransomware, launch it in your target’s network and Lockbit will take care of the rest. They even have support teams to assist victims into the payment and recovery steps. So I was proud that I could recover the data from a file encrypted with the Lockbit ransomware.
It is important to know that they are using the double extorsion tactic, which means that they exfiltrate the data they encrypt and then threaten to publish this data of the ransom is not paid.
The context
I was recently working on a Lockbit ransomware incident and I was able to recover the data from encrypted VMDK and VHDX files (virtual machines hard drives). I am really proud because this allowed us to get the backups back and we will be able to restore everything!
Note: Your mileage may vary! Lockbit is evolving quickly. But I think it is worth a try! If unsure, write to me. I would be really curious to know if it works everywhere!
Everything started when I was reading the blog post “LockBit 2.0: How This RaaS Operates and How to Protect Against It” looking for IOCs for my investigation. In this post, we can read:
The LockBit group claimed that LockBit 2.0 is “the fastest encryption software all over the world” and provided a comparative table showing the encryption speed of various ransomware samples.
When I saw this, I immediately realized that the data might be only partially encrypted. Enough to effectively destroy most of the files, but allowing the ransomware to be more rapid. They are not the first to use this strategy. I had this realization because in cryptography, you can’t simply “have more speed”. So either they were using symmetric encryption (which means the key is in memory) because it’s faster, or they only partially encrypt files. The second option makes more sense because the first one would be a really bad design choice, and let’s admit: these groups are smart!
As soon I as realized this, I ran the “strings” command on an encrypted VHDX. And guess what? I could see a lot of known strings like “This program cannot be run in DOS mode”. This means that some part of the file is still intact and could maybe be restored!
The path to victory
Knowing this, I started looking for hints and ideas online to help me understand how we could get access to the intact data. This is when I found this video:
Youtube video: Recovery for vhdx file, encrypted with ransomware “lucky”
Even though this video is talking about the “lucky” ransomware, the idea is the same. What we need to understand from this video is that only the header of the VHDX file was encrypted (using Lockbit 2.0). This header is important because it holds information about the virtual drive (partitions, block locations, etc.) and without it, most software can’t read the data. So what they show in the video is how to essentially fake a corrupted but working VHDX file, allowing normal tools like 7-Zip to access the data. They do it by essentially replacing the first 2048 sectors of the drive with the data from an empty but working VHDX file using UFS Explorer Professional Recovery.
After this is done, you can save the “RAID” generated with the tool to a new VHDX file. This file won’t be readable with Hyper-V, but you’ll be able to open it with 7-Zip and get your data back.
I tried to use the same technique on a VMDK file, but it was not working. I believe this is because it was encrypted with Lockbit 3.0 which, I think, encrypts more data. Also, I think a VMDK file is less permissive than a VHDX file because it is more complex.
For the VMDK file, I could still see readable information but I could not see the magic bytes for a NTFS partition. I was looking for something similar to this:
For the VMDK file, I tried the “Scan for lost data” feature of the software and it worked! It could see all the files on the drive. It was not able to repair the partition so I was not able to rebuild a virtual drive, but using the paid version, I was able to extract all the files!
Note: the VHDX technique can be done without the paid version.
At the time of writing this post, I am not sure how Lockbit does this. Do they encrypt a percentage of every files, or do they encrypt the X first bytes of every files. My gut feeling (based on a few files I tested) tells me they are only encrypting the first bytes of every files. This could mean that any large file could be recovered, at least partially!
I do need more data to better understand how they operate, so please leave comments below or contact me if you have information!
Victory
The Lockbit ransomware is aggressive and I was hoping we could recover the data because they encrypted the backups.
To prove the technique was effective, I then proceeded to recover the data from 2 VHDX and 2 VMDK files to prove it was not a fluke. And it worked!
So next time I am working on a ransomware incident, I’ll remember to try the simple but effective “strings” command on the encrypted files!
Feel free to leave your comment down here for any questions or comments.
Donation
If you like my blog and my posts, please consider donating! Imagine this: each minute of reading a post takes about 1-2 hours to create!