LockBit 2.0 Ransomware Becomes LockFile Ransomware with a Never-Before-Seen Encryption Method

Threat actors are constantly improving their attack mechanisms to gain an advantage over cybersecurity defenses. Sometimes this involves new malware; other times this means making iterative adjustments to previously successful malware to exploit new vulnerabilities or use new attack techniques to evade and breach underprepared network environments.

We have seen ransomware evolve in this way previously, perhaps most famously with Petya and NotPetya. Ransomware is one of the top threats to businesses, with DarkSide, WastedLocker, and many others leaving their mark on the international business landscape.

In this post we provide analysis on an emerging ransomware variant called LockFile which evolved from Lockbit 2.0 and has breached security defenses using new attack techniques.

LockFile’s Unique Encryption

Most ransomware operates in a similar way. It generates an encryption key and uses it to encrypt the entire binary of the file, corrupting all data.

Lockfile works differently. Rather than encrypting the entire file, it intermittently encrypts 16 bytes at a time. For textual data, this means that part of the file will remain readable. For files where the structure is important (such as a pdf), it will corrupt the file and make it unusable.

Additionally, LockFile ransomware does not encrypt certain file extensions (for example .exe and .dll), a common behavior amongst a variety of ransomware. The purpose of this encryption technique is to allow the operating system to still function for the victim, albeit only by using corrupted data, ensuring the infected organization pays the ransom.

One aspect of LockFile that makes it different from other ransomware is that it does not attack image files (jpeg, bmp, giff, jpg). This is a curious approach. Does LockFile do this to preserve a victim's animal pictures, or is this simply coincidental?

What is the Strategy Behind Encrypting Only Part of the File?

To understand the thinking behind encrypting only part of the file rather than the entire thing, think of a file like an enormous puzzle. When you encrypt the file, you scramble the puzzle image to the point where you can’t recognize the original. At that point no one could be tricked into thinking that this is a legitimate puzzle.

But what if a large portion of the puzzle remained untouched? Without careful examination, you might not notice. As such, it may well be that only part of these files are encrypted by design to obfuscate the threat. When a full file is encrypted, it is quite easy to determine that the file has been tampered with. However, using intermittent encryption may be a new tactic to avoid detection.

Old Dog, New Tricks

So, who is behind this new ransomware?

Some speculate that the Conti ransomware gang is responsible based on the email address in the ransom note (contact@contipauper.com).

But a close examination of the note reveals a striking similarity to the note used in LockBit 2.0.

Although the ransom note is nearly identical (the font, colors, and formatting are the same) LockBit 2.0 uses 32bit files while all the LockFile samples we found were 64bit. The 64bit payload Lockfile narrows the target range of potential victims since 64bit won’t work on machines with older operating systems or 32bit operating systems.

This is interesting because threat actors typically prefer to keep a wider scope, not limiting their targets to specific OS architectures. Perhaps Lockfile’s developers had performance aspects in mind during the development process which led them to this decision?

LockBit 2.0 and LockFile: What are the Differences?

There are three more noticeable ‘features’ which differentiate LockBit 2.0 and LockFile:

1. LockBit 2.0 did not use the unique intermittent encryption we saw in LockFile.
2. LockBit 2.0 used wmic.exe only for deleting shadow copies, while in LockFile we saw their extensive use to terminate any process related to virtualization or databases the machine is connected to.
3. LockBit 2.0 encrypted victim’s images, whereas LockFile did not do image encryption.

Mitigating the Threat

According to sources familiar with the threat infection chain, the latest version of the ransomware is using two very new attack vectors:

• ProxyShell – Microsoft Exchange servers remote code execution vulnerability
• PetitPotam NTLM relay attack – new technique used to perform an NTLM relay attack

To mitigate the ProxyShell vulnerabilities, one must simply patch the exchange servers. (CVE-2021-31207, 2021-33473, 2021-34523, 2021-31206)

Mitigating the PetitPotam requires more than just downloading a patch – it necessitates following a guide Microsoft released, which first informs a user about whether they are affected and includes details on how to configure one’s domain controllers to mitigate this attack vector.

How Deep Instinct Stopped LockFile

Threat actors will continue to find flaws and create sophisticated ways to attack your environment. The onus is on all of us to stay one step ahead.

When it comes to preventing LockFile ransomware, Deep Instinct is the answer. We detect it pre-execution without any updates or modifications to our product and stop it in its tracks.

If you’d like to learn more about our ransomware prevention capabilities – including our industry best $3M no-ransomware guarantee – we'd be delighted to give you a demo.

IOCs:

Lockfile’s SHA256 Referred to in this Blog Post: