LockBit ransomware borrows tricks to keep up with REvil and Maze

Ransomware operators are always on the lookout for a way to take their ransomware to the next level. That’s particularly true of the gang behind LockBit. Following the lead of the Maze and REvil ransomware crime rings, LockBit’s operators are now threatening to leak the data of their victims in order to extort payment. And the ransomware itself also includes a number of technical improvements that show LockBit’s developers are climbing the ransomware learning curve—and have developed an interesting technique to circumvent Windows’ User Account Control (UAC).

Because of recent dynamics in the ransomware world, we suspect that this privilege-escalation technique will pop up in other ransomware families in the future. We’ve seen a surge in “imposter” ransomware that are essentially rebranded variants of already-existing ransomware. Not a single day goes by where a new brand of ransomware does not come out. It has become surprisingly easy to clone ransomware and release it, with small modifications, under a different umbrella.

The Ransomware Learning Curve

Before we jump into the synopsis of LockBit, let’s take a moment to look at how ransomware is developed, in general. Many families follow a common timeline when it comes to the techniques and procedures ransomware developers implement at each stage. This appears to stem from the learning curve involved in creating ransomware, and the iteration of the malware as the developer builds his or her related knowledge of the malware craft.

Each ransomware seems to have an “infancy phase,” where the developer implements TTPs hastily just so the “product” can come out and start gaining its reputation. In this phase, the simplest ideas are implemented first, strings are usually plain text, the encryption is implemented in a way that only a single-thread is used, and LanguageID checks are in place to avoid encrypting computers in CIS countries. and avoid attracting unwanted attention from CIS law enforcement agencies.

After about 2 months into the ransomware operation, the developer starts implementing more sophisticated elements. They may introduce multi-threading, establish a presence in underground forums, obfuscate or encrypt strings in the binary, and there is usually a skip list/kill list for services and processes.

Around 4 months into the ransomware’s life, we start seeing things get more serious. The business model may now switch to Ransomware as a Service (RaaS), putting an Affiliate program in place. Oftentimes, binaries are cryptographically signed with valid, stolen certificates. There is a possibility that the ransomware developer starts implementing UAC bypasses at this stage. This appears to be the stage the LockBit group is entering.

Advertising the goods

As with most ransomware, LockBit maintains a forum topic on a well-known underground web board to promote their product. Ransomware operators maintain a forum presence mainly to advertise the ransomware, discuss customer inquiries and bugs, and to advertise an affiliate program through which other criminals can lease components of the ransomware code to build their own ransomware and infrastructure.

In January, LockBit’s operators created a new thread in the web board’s marketplace forum, announcing the “LockBit Cryptolocker Affiliate Program” and advertising the capabilities of their malware. The post claims that the new version had been in development since September of 2019, and emphasizes the performance of the encryptor and its lower use of system resources to prevent its detection.

LockBit’s post indicates that “we do not work in the CIS,” meaning that the ransomware will not target victims in Russia and other Commonwealth of Independent States countries. This comes as no surprise—as we have seen previously, CIS authorities don’t bother investigating these groups unless they are operating against targets in their area of jurisdiction.

That does not mean that the LockBit group won’t do business with other CIS-based gangs. In fact, they won’t work with English-speaking developers without a Russian-speaking “guarantor” to vouch for them.

Escalating the extortion

In this most recent evolution of LockBit, the malware now drops a ransom note that threatens to leak data the malware has stolen from victims: “!!! We also download huge amount of your private data, including finance information, clients personal info, network diagrams, passwords and so on. Don’t forget about GDPR.”

If the threat were to be carried out, it might result in real-world sanctions against the ransomware victims from regulators or privacy authorities—for example, for violating the European Union’s General Data Privacy Rules (GDPR) that make companies responsible for securing sensitive customer data in their possession.

An increasing number of ransomware gangs use extortion that threatens the release of private data, which might include sensitive customer information, trade secrets, or embarrassing correspondence to incentivize victims to pay the ransom, even if they have backups that prevented data loss. The data leak threat has become a signature of the REvil and Maze ransomware gangs; the Maze group has gone as far as to publicly publish chunks of data from victims who fail to pay by the deadline, taking down the dumps when they are finally paid.

Picking through LockBit’s code

From a first glance at the recent LockBit sample with a reverse-engineering tool, we can tell that the program was written primarily in C++ with some additions made using Assembler. For example, a few anti-debug techniques employ the fs:30h function call to manually check the PEB (Process Environment Block) for the BeingDebugged flag, instead of using IsDebuggerPresent().

The first thing the ransomware does at execution is to check whether the sample was executed with any parameters added from the command line. Usually, this is done to check for whether the sample is being executed in a sandbox environment. Contemporary malware often requires that the command to run the malware use specific parameters to prevent the malware from being analyzed by an automated sandbox, which often execute samples without parameters. But the LockBit sample we examined doesn’t do that—it won’t execute if there is any parameter entered from the command line. If there are no arguments in the command that executes it, Lockbit hides its console output, where the malware prints debug messages, and proceeds to do its job.

This could be intended to detect if the sample was executed in a sandbox environment. But it’s possible that either the malware author made a mistake in the implementation of the check (and wanted to check the other way around), or that this behavior is just a placeholder, and future versions will introduce different logic.

Hiding strings

LockBit’s author also used several techniques to make it more difficult to reconstruct the code behind it. The Portable Executable (PE) binary shows signs of being heavily optimized, as well as some efforts by the group to cover their coding tracks—or at least get rid of some of the low-hanging fruit that reverse engineering tools look for, such as unencrypted text strings.

These string variables get decrypted on the fly with a 1-byte XOR key unique to each string: the first hex byte of every variable.

Almost all the functions contain a small routine that loops around and is in charge of decrypting hidden strings. In this case, we can see that how the original MSSQLServerADHelper100 service name gets de-obfuscated: the malware leverages a one-byte “0A” XOR key to decrypt the plaintext service name.

Check your privilege

To ensure that it can do the most damage possible, LockBit has a procedure to check whether its process has Administrator privileges. And if it doesn’t, it uses a technique that is growing in popularity among malware developers: a Windows User Account Control (UAC) bypass.

Leveraging OpenProcessToken, it queries the current process via a TOKEN_QUERY access mask. After that, it calls CreateWellKnownSid to create a user security identifier (SID) that matches the administrator group (WinBuiltinAdministratorsSid), so now the malware has a reference it can use for comparisons. Finally, it checks whether the current process privileges are sufficient for Administrator rights, with a call to CheckTokenMembership.

If the current process does not have Admin privileges, the ransomware tries to sidestep Windows UAC with a bypass. In order for that to succeed, a Windows COM object needs to auto-elevate to Admin-level access first.

To make this possible, LockBit calls a procedure called supMasqueradeProcess upon process initialization. Using supMasqueradeProcess allows LockBit to conceal its process’ information by injecting into a process running in a trusted directory. And what better target is there for that than explorer.exe?

The source code for the masquerade procedure can be found in a Github repository.

With the use of IDA Pro’s COM helper tool, we see two CLSIDs—globally unique identifiers that identify COM class object—that LockBit’s code references. CLSIDs, represented as 128-bit hexadecimal numbers within a pair of curly braces, are stored in the Registry path HKEY_LOCAL_MACHINE\Software\Classes\CLSID.

Looking up these reveals that the two CSLIDS belong to IColorDataProxy and ICMLuaUtil—both undocumented COM interfaces that are prone to UAC bypass.

Masquerading as explorer.exe, LockBit calls CoInitializeEx to initialize the COM library, with COINIT_MULTITHREADED and COINIT_DISABLE_OLE1DDE flags to set the concurrency model. The hex values here (CLSIDs) are then moved and aligned into the stack segment register, and the next function call (lockbit.413980) will further use them.

Lockbit.413980 hosts the COM elevation moniker, which allows applications that are running under user account control (UAC) to activate COM classes (via the following format: Elevation:Administrator!new:{guid} ) with elevated privileges.

The malware adds the 2 previously seen CLSIDs to the moniker and executes them.

Now, the privilege has been successfully elevated with the UAC bypass and the control flow is passed back to the ransomware. We also notice two events and a registry key change during the execution:

Kill or skip

LockBit enumerates the currently running processes and started services via the API calls CreateToolhelp32Snapshot, Process32First, Process32Next and finally OpenProcess, and compares the names against an internal service and process list. If one process matches with one on the list, LockBit will attempt to terminate it via TerminateProcess.

The procedure to kill a service is a bit different. The malware will first connect to the Service Control Manager via OpenSCManagerA. It then attempts to check whether a service from the list exists via OpenServiceA. If the targeted service is present, it then tries to determine its state by calling to QueryServiceStatusEx. Based on the status returned, it will call ControlService with the parameter SERVICE_CONTROL_STOP (0x00000001) on the specific service to stop it. But before that, another function (0x40F310) will cycle through all dependent services in conjunction with the target service, so dependencies are stopped too. The malware will initiate calls to EnumDependentServicesA to achieve this.

The services that the malware tries to stop include anti-virus software (to avoid detection) and backup solution services. (Sophos is not affected by this attempt.) Other services are stopped because they might lock files on the disk, and might make it more difficult for the ransomware to easily acquire handles to files—stopping them improves LockBit’s effectiveness.

Some of the services of note that the ransomware attempts to stop, in the order they are coded into the ransomware, are:

In addition to the list of services to kill, LockBit also carries a list of things not to encrypt, including certain folders, specific files and files with certain extensions that are important to the operating system—since disabling the operating system would make it difficult for the victim to receive and act upon the ransom note. These are stored in obfuscated lists within the code (shown below), A function within LockBit uses the FindFirstFileExW and FindNextFileW API calls to read through the file names and folder names on the targeted disk, and then a simple lstrcmpiW function is called to compare the hardcoded list with those names.

Accelerating file encryption

Recently, we have seen ransomware groups taking more advanced concepts and applying it to their craft. One of these advanced concepts applied in LockBit is the use of Input/Output Completion Ports (IOCPs).

IOCPs are a model for creating a queue to efficient threads to process multiple asynchronous I/O requests. They allow processes to handle many concurrent asynchronous I/O more quickly and efficiently without having to create new threads each time they get an I/O request.

That capability makes them well-suited to ransomware. The sole purpose of ransomware is to encrypt as many delicate files as possible, rendering the user’s data useless. REvil (Sodinokibi) ransomware also uses IOCPs to achieve higher encryption performance.

LockBit’s aim was to be much faster than any other multi-threaded locker. The group behind the ransomware claims to have used the following methods to boost the performance of their file encryption:

• Open files with the FILE_FLAG_NO_BUFFERING flag, write by sector size
• Transfer work with files to Native API
• Use asynchronous file I/O
• Use I/O port completion
• Pass control to the kernel yourself, google KiFastSystemCall

Once a file is marked for encryption—meaning, it did not match entries on the skip-list—a LockBit routine checks whether the file already has a .lockbit extension. If it does not, it encrypts the file and appends the .lockbit extension to the end of the filename.

Lockbit relies on LoadLibraryA and GetProcAddress to load bcrypt.dll and import the BCryptGenRandom function. If the malware successfully imports that DLL, it uses BCRYPT_USE_SYSTEM_PREFERRED_RNG which means use the system-preferred random number generator algorithm. If the malware was unsuccessful calling bcrypt.dll, it invokes CryptAcquireContextW and CryptGenRandom to invoke the Microsoft Base Cryptographic Provider v1.0 and generates 32 bytes of random data to use as a seed.

Also, at this stage, the hardcoded ransom note, Restore-My-Files.txt, gets de-obfuscated and the ransomware drops the .txt file in every directory that contains at least one encrypted file.

Victim ID

LockBit creates 2 registry keys with key blobs as values under the following registry hive: HKEY_CURRENT_USER\Software\LockBit

The two registry keys are:

LockBit\full
LockBit\Public

These registry keys correlate with the Victim ID, file markers, and the unique TOR URL ID that LockBit builds for each system it takes down.

Let’s take the unique TOR URL from the ransom note:

In this example, the 16 byte long unique ID is at the end of the URL, http://lockbitks2tvnmwk[.]onion/?A0C155001DD0CB01AE0692717A2DB14A :

• The first 8 bytes used here (A0C155001DD0CB01)is the first 8 bytes of the file marker that is present in every encrypted file’s end .

  

• The last 8 bytes (AE0692717A2DB14A) is the first 8 bytes of the Public registry key.

The file marker (0x10 long) is divided into 2 sections:

A0C155001DD0CB01

The first 8 bytes of the file marker and the first 8 bytes of the TOR unique URL ID.

D4EA7A79A0835006

The second 8 bytes are same for all encrypted files in a given run

Also, the value of the full registry key (0x500 long, starting as 1A443C7179498278B40DC082FCF8DE26… in this example) is also present in every encrypted file, just before the file marker.

Share enumeration

For a successful ransomware hit and run, the goal is to encrypt as many files as possible. So naturally, LockBit scans for network shares and other attached drives with the help of the following API calls.

First, the malware enumerates the available drive letters with a call to GetLogicalDrives, then it cycles through the found drives and uses a call to GetDriveTypeW to determine whether the drive letters it finds are network shares by comparing the result with 0x4 (DRIVE_REMOTE).

Once it finds a networked drive, it calls WNetGetConnectionW to get the name of the share, then recursively enumerates all the folders and files on the share using the WNetOpenEnumW, WNetEnumResourceW API calls.

The ransomware can also enter network shares that might require user credentials. LockBit uses the WNetAddConnection2W API call with parameters lpUserName = 0 and lpPassword = 0, which (counterintuitively) transmits the username and password of the current, logged in user to connect to the given share. Then it can enumerate the share using the NetShareEnum API call.

Don’t quit just yet

I an attempt to ensure that LockBit would not be kept from finishing its job by a system shutdown, the developers of this ransomware implemented a small routine that uses a call to ShutdownBlockReasonCreate.

The developers didn’t try to conceal the ransomware as the cause of the shutdown block: the ransomware sets the message for blocking shutdown as LockBit Ransom. Computer users would also see the message LockBit Ransom under the process’ name.

SetProcessShutdownParameters is also called to set the shutdown order level of the ransomware’s process to 0, the lowest level, so that the ransomware’s parent process will be active as long as it can, before a shutdown terminates the process.

If the system is shut down, the malware also has capability to persist after a reboot. LockBit creates a registry key to restart itself under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\, called XO1XADpO01.

Stop me if you’ve heard this before

LockBit prevents multiple ransomware instances on a single system by way of a hardcoded mutex: Global\{BEF590BE-11A6-442A-A85B-656C1081E04C}. Before LockBit starts encrypting, the ransomware checks that the mutex does not already exist by calling OpenMutexA, and calls ExitProcess if it does.

As soon as the ransomware is mapped into memory and the encryption process finishes, the sample will execute the following command to maintain a stealthy operation:

• exe /C ping 1.1.1.1 -n 22 > Nul & \”%s\” (earlier version of LockBit)
• exe /C ping 127.0.0.7 -n 3 > Nul & fsutil file setZeroData offset=0 length=524288 “%s” & Del /f /q “%s” (recent version of LockBit)

The ping command at the front is used because the sample can’t delete itself, due to the fact that it is locked. Once ping terminates, the command can delete the executable.

We clearly see an evolution to the applied technique here: in the earlier versions, the sample was missing a Del procedure at the end, so the ransomware would not delete itself.

In the recent version, the crooks had decided to use fsutil to basically zero out the initial binary to perhaps throw off forensic analysis efforts. After the file is zeroed out, the now null-file is deleted also, making double-sure the malware is not forensically recoverable.

Language matters

As we noted earlier, LockBit’s developers wanted to avoid having their ransomware hit victims in Commonwealth of Independent States (CIS) countries. The mechanism used by the ransomware to achieve this calls GetUserDefaultLangID and looks for specific language identifier constants in the region format setting for the current user. If the current user’s language setting matches any of the values below, the ransomware exits and does not start the encryption routine.

Changing the wallpaper

To get the affected user’s attention, the malware (as is typical) creates and displays a ransom note wallpaper. A set of API calls are involved in this process, listed below.

The created wallpaper gets stored under %APPDATA%\Local\Temp\A7D8.tmp.bmp.

In the meantime, the malware also sets a few registry keys so that the wallpaper is not tiled, and the image is stretched out to fill the screen:

HKEY_CURRENT_USER\Control Panel\Desktop

• TileWallpaper=0 – (No tile)
• WallpaperStyle=2 – (Stretch and fill)

Stack Exchange for crooks

LockBit leverages a very similar service-list to MedusaLocker ransomware. It comes as no surprise that crooks copy these lists, so they don’t have to reinvent the wheel.

The unique Registry run key and ransom note filename that was written by LockBit—XO1XADpO01 and Restore-My-Files.txt — were also seen being used by Phobos, and by a Phobos imposter ransomware. This would suggest that there is a connection between these families, but without further evidence that is hard to justify.

The future for LockBit

A recent Twitter post demonstrates what the future looks like for LockBit. In a recent LockBit attack, the MBR was overwritten with roughly 2000 bytes; The infected machine would not boot up unless a password is supplied. The hash of this sample is currently not known.

The e-mail used for extortion ondrugs@firemail.cc was also seen with STOP ransomware—an uncanny connection. The group behind might be related.

There is also speculation that application Diskcryptor was combined with the ransomware to add this extra lockdown layer. The MAMBA ransomware was also using this technique, leveraging Diskcryptor to lock the victim machine. DiskCryptor is currently being detected as AppC/DCrpt-Gen by Sophos Anti-Virus.

A list of the indicators of compromise (IoCs) for this post have been published to the SophosLabs Github.

Acknowledgments

The author would like to acknowledge the public contributions of @demonslay335 and @hfiref0x.