LockBit 3.0 Ransomware Analysis

LockBit 3.0 is a new version of the infamous LockBit ransomware, also known as LockBit Black. This ransomware has been observed to reuse code from other ransomware strains such as DarkSide and BlackMatter. While performing incident response for an organization that was hit by LockBit, I compiled a list of actions that LockBit takes to increase its effectiveness. Below you can find the most interesting parts that I encountered while performing analysis on this ransomware.

We kickoff this post by unpacking and decrypting LockBit’s code to better understand its behavior.

Unpacking and Decryption

LockBit 3.0 uses a unique mechanism for its unpacking and decryption process. It uses a password to decrypt itself, specifically an RC4 KSA password. This password is used to decrypt the first stage of the unpacking process. The unpacking process involves several layers, starting with some source and then RC4. Eventually, it resolves Windows API functions and executes them.
The initial run of Lockbit 3.0 Ransomware is facilitated by an “access token”, as follows: <Ransomware.exe> -k LocalServiceNetworkRestricted -pass db66023ab2abcb9957fb01ed50cdfa6a. This method of code protection encrypts the Lockbit 3.0 Ransomware code, aiding in its evasion of malware detection mechanisms. For the successful execution of the Ransomware, a parameter (-pass) is required. This key serves to decrypt the source code of LockBit 3.0, enabling its execution on the targeted device.

Static and Dynamic Analysis

When opening the executable file of LockBit with IDA, we can see the following execution flow:

• The first two instructions are NOP, which basically tell the processor to do nothing for one cycle of operation. In the context of malware analysis, NOPs are often found in what’s called a “NOP sled” or “NOP slide”. This is a sequence of NOP instructions meant to lead the execution flow towards a specific payload or exploit in the code.
• The first function call is done to sub_41B000. This subroutine is responsible for the decryption of LockBit’s code using the decryption key supplied from the execution parameters.

This subroutine starts with a loop, then calls sub_41B2E4, which then calls sub_41B2D4. Within this subroutine, we see something interesting, the fs segment register. This register is a data structure, also known as Thread Information Block, which holds information about the running thread. This might be the place where the access token is parsed from the command line.

Executing the ransomware shows us what happens after LockBit’s code gets decrypted. Using the IDA debugger, we launch the ransomware using the decryption token supplied as a value for the -pass parameter: -pass db66023ab2abcb9957fb01ed50cdfa6a.

Shortly after we start the execution, the entire code of the malware is decrypted, enabling us to explore its features. We also notice that LockBit downloads an .ico file which will be used as a source to change the icon of each file of the system. Moreover, a background image will also be downloaded, informing the user that the computer was infected and pointing to a readme file with the instructions on how to pay the ransom:

We can validate this action by having a look in the Process Monitor utility of Windows:

The Lockbit 3.0 ransomware sample appears to contain only a few functions and Windows APIs when viewed in the Imports tab of the IDA disassembly tool. However, this is not the case. In reality, the developers of Lockbit 3.0 ransomware are obscuring the function calls and Windows APIs. They employ Stack String Obfuscation and simple XOR Encryption techniques to hide these aspects, thereby enhancing the evasiveness of the Windows APIs (import tables). This can be seen when debugging the malware at the stub from this address: 0x4011E4.

Lockbit 3.0 Ransomware operates by loading all of the Windows APIs during execution, thus increasing its stealth. To reveal the concealed API calls, we can either execute the sample under a debugger or use HashDB in IDA to resolve the APIs.

Upon decryption or unpacking of the ransomware code using the -pass parameter, the Win32 APIs are dynamically resolved. This is carried out by the function sub_407C5C, which takes an obfuscated string as input and XORs it with the key 0x4506DFCA. This process is undertaken to decrypt the name of the Win32 API to be resolved.

Evading Detection

The developers of Lockbit 3.0 Ransomware aim to disable the default security product on the targeted device. This is achieved by modifying certain registry keys to turn off all Windows Event Log Messages. Specifically, the registry keys under the following path are altered: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels<Log Name>

Following this modification, the ‘Enabled’ key is set to 0, and a new Security Descriptor — O:BAG:SYD:(A;;0x1;;;SY)(A;;0x5;;;BA)(A;;0x1;;;LA) is added, which further tampers with the Event Logs.

In order to deactivate Windows Defender, the ransomware duplicates the access token of the Trusted Installer Service. This service has the necessary permissions to stop Windows Defender. By using this duplicated access token, it can successfully halt and eliminate services connected with Windows Defender.

To stop and control services, LockBit makes use of the TerminateProcess, ControlServiceand DeleteServicefunctions of the Windows API.

Other Observations

LockBit 3.0 includes a piece of code that is derived from BlackMatter/Darkside. The execution process will be stopped if the identified language is either Russian (0x419), Ukrainian (0x22), or Belarusian (0x23).
LockBit 3.0 also takes steps to obstruct the recovery of encrypted files from shadow copies. It does this by terminating and removing the Volume Shadow Copy Service (VSS). Following this, it uses the Windows Management Instrumentation (WMI) interface to delete the shadow copies of the disks.

Countermeasures and Precautions

• Regularly create and maintain offline backups of data. This will prevent severe interruptions to the organization and the loss of irrecoverable data.
• Implement network segmentation to hinder the propagation of ransomware. It controls traffic between different subnetworks and limits adversaries’ lateral movement.
• Implement multi-factor authentication for all services, particularly for those like webmail, virtual private networks, and accounts that can access critical systems.
• Always keep operating systems and software updated.
• Remove any unnecessary access to administrative shares, particularly ADMIN$ and C$.
• Block access to Remote Desktop Protocol (RDP) from public networks. If remote access is required, it should be accessible only through a secure VPN connection (with multi-factor authentication) to the corporate network, or through a zero-trust remote access gateway.
• Upgrade to SMBv3 (or the most current version), along with SMB signing. Remove dependencies through these upgrades and reconfigurations.
• Block all versions of SMB externally by blocking TCP port 445 and associated protocols on User Datagram Protocol ports 137–138 and TCP port 139.
• Implement application directory allowlisting on all assets, ensuring only authorized software can run and all unauthorized software is blocked from executing.
• Apply the principle of least privilege to all systems and services, restricting users to only the access they need for their roles. Threat actors often target privileged accounts to help disseminate ransomware across networks.
• Limit the usage of PowerShell through Group Policy to specific users as needed. Generally, only network managers or Windows OS administrators should have PowerShell access. Keep PowerShell updated and enable enhanced logging. Threat actors often use PowerShell to deploy ransomware and conceal their malicious activities. Althoughit has been reported that LockBit affiliates use Bat Armor to bypass those policies, it is still useful to have such strict policies in place in the context of other malwares as well.