Lockbit is one of the most prevalent ransomware strains. It comes with an affiliate ransomware-as-a-service (RaaS) program offering up to 80% of the ransom demand to participants, and includes a bug bounty program for those who detect and report vulnerabilities that allow files to be decrypted without paying the ransom. According to the Lockbit owners, the namesake cybercriminal group, there have been bounty payments of up to 50 thousand dollars. In addition to these features, Lockbit has offered a searchable portal to query leaked information from companies targeted by this ransomware family, and even offered payment to those who get tattooed with a Lockbit logo on their body.
Lockbit v3, also known as Lockbit Black, was detected for the first time in June 2022 and represents a challenge for analysts and automated analysis systems. Among the most challenging characteristics, we can highlight the following:
- It supports the usage of encrypted executables with randomly generated passwords. This prevents execution and hinders automatic analysis unless the appropriate password is provided at the command line.
- The payload includes strong protection techniques against reverse-engineering analysis.
- It includes many undocumented kernel-level Windows functions.
In September of 2022, multiple security news professionals wrote about and confirmed the leakage of a builder for Lockbit 3. This tool allowed anyone to create their own customized version of the ransomware. Two different users published the files needed to create different flavors of this ransomware:
Lockbit builder uploaded to GitHub
According to our analysis, two different variants were spotted by the X’s (previously known as Twitter) users @protonleaks and @ali_qushji. Our timestamp analysis confirmed that the binary, builder.exe, was slightly different in both leaks. The version from protonleaks registers the compilation date 2022/09/09. Meanwhile, the version from ali_qushji was compiled on 2022/09/13. A similar difference in compilation time was identified in the malware’s template binaries (embedded and incomplete versions of the malware used to build the final version ready for distribution).
ALI_QUSHJI leak builder
PROTONLEAKS leak builder
Who abused these builders and how?
Immediately after the builder leak, during an incident response by our GERT team, we managed to find an intrusion that leveraged the encryption of critical systems with a variant of Lockbit 3 ransomware. Our protection system confirmed and detected the threat as “Trojan.Win32.Inject.aokvy”.
The intrusion included TTPs similar to those highlighted in the report by Kaspersky Threat Intelligence team from August 2022 about the eight main ransomware groups behind ransomware attacks, including tactics for reconnaissance, enumeration, collection and deployment.
Although this variant was confirmed as Lockbit, the ransom demand procedure was quite different from the one known to be implemented by this threat actor. The attacker behind this incident decided to use a different ransom note with a headline related to a previously unknown group, called NATIONAL HAZARD AGENCY.
Original Lockbit ransom note
Managed incident ransom note
The ransom note used in this case directly described the amount to be paid to obtain the keys, and directed communications to a Tox service and email, unlike the Lockbit group, which uses its own communication and negotiation platform.
According to other analysts’ publications, different groups appeared using the exfiltrated builders, but with their own notes and communication channels:
BL00DY RANSOMWARE GANG (Source: https://twitter.com/malwrhunterteam/status/1574260677597925376)
GetLucky ransom note, Source: AnyRun
GERT’s approach to analyzing the builder and payload
While many threat actors took advantage of the leak to propose new ransomware groups, Kaspersky’s GERT team decided to analyze the builder to understand its construction methodology and define additional analysis opportunities.
The analysis of the builder addressed some of the challenges posed by the ransomware payload:
- The builder contains no protection mechanisms as it will be used by the actors and should not be exposed: no anti-debugging (at least in the builder itself), no anti-reversing, no code obfuscation, sample templates embedded as resource (decrypter, EXE, DLL, reflective DLL).
- We learned how the configuration parameters are embedded within the payload without requiring reverse engineering of the final binary.
The builder presents different configuration parameters that are compulsorily embedded in the malware.
Embedded resources
The encrypter and decrypter templates are embedded into the builder’s resource section:
- 100: LockBit 3.0 Decryptor (EXE)
- 101: LockBit 3.0 Encryptor (EXE)
- 103: LockBit 3.0 Encryptor (DLL)
- 106: LockBit 3.0 Encryptor (Reflective DLL)
An approach was proposed – based on the methodology of constructing the configuration parameters and how they were added to the selected payload – to figure out:
- How parameter configuration parsing is performed
- How data transformation is applied
- How the configuration is encrypted and then stored within the final binary
The payload-embedded configuration
The reverse-engineering analysis identified that the configuration is embedded in a section named .pdata, which is first encrypted using an XOR function with a key derived from a random seed and then compressed to embed it in the payload.
If the sample is configured to be encrypted using a password, the configuration will be similarly embedded in the binary first and then the sample will be encrypted with a unique key.
.pdata – this section contains the embedded configuration
Embedded data (encrypted and compressed)
The creation of the XOR key, used to decrypt the content embedded in the section, depends on two random keys along with other fixed values embedded in the binary source code.
Decryption and subsequent decompression results in a set of sample configuration parameters, some of them with easily identifiable encryption mechanisms.
Decrypted section
Decompressed section
The next step is to interpret the fields and apply the required decryption to each of them to transform them into intelligible values.
The builder uses a custom hashing function that produces a 4-byte value for each of the values entered in the configuration parameters white_folders, white_files, white_extens and white_hosts. Other fields are stored with Base64 and ROR13.
Finally, interpreting the meaning of the fields in the config.json file and the relationship between the fields allows us to confirm that:
- Most configuration fields are easy to interpret based on their name and content.
- Some fields accept values only from a list of values.
- Many fields with string values are stored using ROR13 before being loaded into the payload configuration.
- Some fields accept multiple list values, using the “;” separator.
- Credentials must be stored in the format :.
Config.json – what the fields mean
Based on these results, we defined a sample analysis procedure and applied it to multiple samples to determine the type of actors, objectives and construction preferences of the payloads.
Statistics of samples reported in our intelligence platforms
The objective of this analysis is to understand the parameters applied by different actors to build the malware as configured in samples detected in the wild.
During our research, 396 distinct samples were analyzed. According to the timestamps, mostly samples created by the leaked builders were detected, but other unknown builders dated June and July 2022 were also identified.
General statistics of the embedded configuration:
- Many of the detected parameters correspond to the default configuration of the builder, only some contain minor changes. This indicates the samples were likely developed for urgent needs or possibly by lazy actors.
- The most recurrent encryption targets are local disks and network shares, avoiding hidden folders.
- The samples generally run a single instance and enable the following parameters:
- kill service
- kill process
- kill defender
- delete logs
- self-destruct
- Most of the samples identified do not enable the system shutdown option.
- Network deployment by PSEXEC is configured in 90% of the samples, while deployment by GPO is configured in 72%.
- Very few samples enable communication to C2.
Detailed statistics
The C2 communication configuration showed it was rarely used and included three test domains. No suspicious or malicious domains were identified in the analyzed samples, showing there’s no interest for establishing C2 communications using the leaked payloads.
Moreover, inside the configuration, the impersonation data list (credentials registered within the payload configuration) records general data with a default brute-force list. But it was possible to detect other binaries with specific data that allow identifying the organizations or individuals attacked.
It is important to keep in mind that Lockbit payloads and other ransomware actors integrate this type of information inside samples, and the handling of such samples must be done properly to avoid information leaks.
Finally, some statistics relate to the usage of leaked builders by actors other than the “original” Lockbit. We found that 77 samples make no reference to a “Lockbit” string (case-insensitive) in the ransom note, which is quite unexpected according to LB TTP.
The modified ransom note without reference to Lockbit or with a different contact address (mail/URL) reveals probable misuse of the builder by actors other than the “original” Lockbit.
Source:: Securelist