Truth in Malvertising?

Splunk SURGe recently released a whitepaper, blog, and video that outline the encryption speeds of 10 different ransomware families. Early in our research, during the literature review phase, we came across another group that conducted a similar study on ransomware encryption speeds. Who was this group you ask? Well, it was actually one of the ransomware crews themselves. LockBit released the findings on their website (not linking here as it’s one of those naughty .onion sites), with a view of convincing would-be ransomware affiliates to join the LockBit crew, as they were the fastest and therefore the best. We knew that after completing our own research, we’d have to come back to test the veracity of LockBit’s findings.

Read on to see how that went!

Tell Me More About This LockBit Report

LockBit released its report in February of 2021. They tested encryption speeds across 36 different ransomware variants, including two of their own: LockBit 1.0 and LockBit 2.0. LockBit 1.0 was already considered one of, if not the fastest ransomware variants in existence, so why the need to create LockBit 2.0? And did they actually create a faster version?

^{Fig. 1. Screenshot of LockBit’s comparison of ransomware encryption speeds.}

The results show LockBit 2.0 was indeed faster than LockBit 1.0 and both were found to be much faster than any of the other ransomware variants. According to this data, LockBit 2.0 was two times faster than the nearest non-LockBit variant, Cuba. LockBit included the ransomware samples on their website with this call to action: “If you have any doubts concerning this table, you can easily check the provided information downloading the samples, which have been used for testing.”

We wanted to test Lockbit 3.0 (mentioned in this blog), but despite hours of Googling, pleading on Twitter, and sending messages to secret 🐿️ Keybase and Slack groups… we couldn't find a single sample of it!

Did we have any doubt that LockBit was fast? No. Did we have any doubts about their overall findings? Yes. Our original research found that Babuk’s encryption speed was much closer to LockBit’s than what LockBit had reported. After finding this discrepancy, we knew that a full-blown test regime was needed to weed out any other differences.

LockBit’s Tests

The table from LockBit was the only reference we had to replicate this experiment. LockBit provided the following details:

• Ransomware Name
• Date of sample
• Encryption speed in MB/s
• Time to encrypt 100GB
• Time to encrypt 10TB
• Self-spreading?
• Sample size
• Total number of files encrypted

One area that we would have liked to see in more detail was the actual dataset that LockBit used to encrypt. That would help us understand some of their findings a bit better, such as the time to encrypt 100GB and 10TB. Did they use varied file types and file sizes, or did they use thousands of copies of the same file to test encryption?

LockBit provided the operating system, CPU, and memory specifications they used in their tests. For the hard drive, they mention SSD, but nothing about the IOPS or the throughput of the underlying disks. This blog gives a high-level overview of both IOPS and throughput and how they affect application performance. We did find in our original research that disk speed is just as important as CPU speed and the number of CPUs when it comes to overall encryption performance.

A top and bottom summary of LockBit’s test results:

• 1st Place - LockBit 2.0
• 2nd Place - LockBit 1.0
• 3rd Place - Cuba
• Last Place - Avos

Our Tests

We used the same approach in these tests that we did in our prior research project. We created an environment that would be identical across each variant that we tested. A modified version of Splunk Attack Range was used to build the systems in Amazon Web Services (AWS). The specifications of the “victim” system were:

• Windows Server 2016
• AWS EC2 Instance Type- c5.2xlarge
• CPU Count and Type: 8 x Intel Xeon 3.4GHz
• RAM: 16GB
• Disk: GP3 (16000 IOPS/1000MB/s Throughput)
• 98,561 test files spread across 100 directories (various file types and sizes)

These were the closest specifications we could find in AWS to replicate LockBit’s tests. The disk speed was the highest we could configure, but that was consistent across all variants. And as mentioned earlier, we used our “victim” dataset that contained numerous file types and sizes to try and replicate a real-world filesystem.

We tested each variant individually to avoid any contamination from other variants that may spread laterally during the experiment. Each variant was launched manually, as some don’t play nicely when launched via PowerShell (I’m looking at you, Babuk). We performed a manual observation via RDP to confirm the completion of each test run.

In our lab we also set up a Windows 2019 server to act as the Domain Controller. It did not have any shared drives, but there were no firewall rules on the system or AWS preventing access between it and the initial “victim” system.

And the Winner is...

Before I tell you, just know that our results were close, but not the same as what LockBit found. And know that you can always trust us over a ransomware crew that had a bias going into their tests.

Having said that, LockBit was the fastest again in our tests. But not LockBit 2.0.LockBit 1.0 was actually faster than its newer counterpart. Not by much, but still faster.

Total encryption time:

• LockBit 1.0: 2 minutes 20 seconds
• LockBit 2.0: 2 minutes 30 seconds

However, LockBit 2.0 is much more efficient than 1.0, using only half the number of CPU threads, and hitting the disk 27 fewer times. So it does look like LockBit made a number of improvements between those two versions, but not in the realm of overall speed.

LockBit 2.0 still came in right behind 1.0, right? Wrong. The following variant just pipped LockBit 2.0 to come in second place!

• PwndLocker: 2 minutes and 28 seconds

A brief summary of our results:

• 1st Place: LockBit 1.0
• 2nd Place: PwndLocker
• 3rd Place: LockBit 2.0
• Last Place: Avos

PwndLocker, LockBit 1.0, and LockBit 2.0 perform similar partial encryption methods, which help speed up encryption.

LockBit 2.0 only encrypts the first 4KB of a file, leaving the remainder untouched. This is still enough to render most files unusable after encryption.

^{Fig. 2. Screenshot of sample .txt file encrypted by LockBit 2.0 (the first 4KB, in red, was encrypted and the start of the rest, in green, was untouched).}

PwndLocker leaves the first 128B unencrypted, proceeds to only encrypt the next 64KB, and leaves the remainder untouched.

^{Fig. 3. Screenshot of a sample .txt file encrypted by PwndLocker (first 128B unencrypted in green and then encryption of the start of the next 64KB in red).}

And our fastest variant, LockBit 1.0, encrypts 256KB of every file very quickly by utilizing a high number of CPU threads along with high disk access rates.

The fastest variants tend to utilize partial encryption methods, more CPU threads, or a combination of the two.

Poor old Avos managed to come last in LockBit’s test as well as ours. Not many of the other results line up between the two sets of tests, though. We’ve added a detailed table of our test results showing encryption statistics at the end of this blog.

Here is the table comparing our test results to those of LockBit.

Our lead hypothesis on why the findings don’t line up is that different file types and sizes were used between the two sets of tests. If we knew what dataset LockBit used, we would have more insight into their test results.

Takeaways

After running this experiment, here are some key takeaways and recommendations:

• Assume that once the ransomware crew gets to the point of encrypting your systems that it’s too late.
• While LockBit is fast, it isn’t the only ransomware variant capable of extremely fast speeds. Other variants are also making use of partial encryption techniques to speed up their operations.
• Protect your organization before ransomware is run. Get the basics right (patching, offline backups) along with things that should also now be considered basic cyber hygiene practises (multi-factor authentication, network segmentation, centralized logging).

Conclusion

It was interesting to run the same samples in our tests that LockBit used in their own tests. While the fastest and slowest samples were closely aligned between the tests, the other results were very different. The total time it took to encrypt our test filesystem was still quite fast even in the slowest tests, however, which reiterates our recommendation to look left of boom when prioritizing your network defenses.

Happy Hunting!

Appendix

Encryption statistics for our tests:

SHA256 File hash values for samples tested:

Authors and Contributors: As always, security at Splunk is a family business. Credit to authors and collaborators: Shannon Davis, Ryan Kovar

^{Main/top photo by Artem Beliaikin from Pexels}