A technical analysis of the leaked LockBit 3.0 builder


This is our analysis of the LockBit 3.0 builder that was leaked online on September 21, 2022. The executable called “keygen.exe” can be used to generate the RSA public and private keys that are embedded in the encryptor and decryptor, respectively. The builder embedded 4 resources used to create executables or DLL files according to the command line parameters. As in the case of Conti leaks, we’ll probably encounter LockBit-forked ransomware because of the builder’s availability.


Technical analysis

SHA256: A736269F5F3A9F2E11DD776E352E1801BC28BB699E47876784B8EF761E0062DB

The builder was compiled on September 13, 2022. The executable “keygen.exe” can be used to generate RSA public and private keys that are saved as pub.key and priv.key.

The RSA public/private key is Base64-encoded, as highlighted below:

Figure 1

The process retrieves the command-line string using GetCommandLineW:

Figure 2

The CommandLineToArgvW API is utilized to obtain an array of pointers to the command line arguments:

Figure 3

Running with the -type dec -privkey priv.key -config config.json -ofile LB3Decryptor.exe parameters

The malware compares the parameters with “-type enc” (encryptor) and “-type dec” (decryptor) to decide which executable to generate:

Figure 4

The builder opens the RSA private key file by calling the CreateFileW function (0x80000000 = GENERIC_READ, 0x1 = FILE_SHARE_READ, 0x3 = OPEN_EXISTING, 0x80 = FILE_ATTRIBUTE_NORMAL):

Figure 5

The process reads the above file content using the ReadFile API:

Figure 6

The RSA private key is Base64-decoded by the malicious process:

Figure 7

Figure 8

The executable parses the LockBit configuration file “config.json” that contains information such as the whitelisted folders/files/extensions, the processes and services to stop, and the ransom note content:

Figure 9

Figure 10

The malware implements a custom “hashing” function that computes a 4-byte value for each whitelisted directory/file/extension/host. An example of a function result is shown in figure 12.

Figure 11

Figure 12

The resulting buffer containing the hashes is Base64-encoded by the builder, as shown in the figure below.

Figure 13

Figure 14

Figure 15

The malicious executable can use two instructions to generate 2 random 4-byte values: RDRAND and RDSEED. Firstly, it checks if these instructions are supported by the processor and then generates the random bytes. An identical implementation was also used by DarkSide ransomware, which could mean that the two groups borrowed the code from the same place:

Figure 16

The random values are combined with two hard-coded values, which are modified using simple operations such as OR:

Figure 17

Figure 18

A buffer containing the RSA private key and the Base64-encoded string computed above is XOR-ed with the values generated using the 4-byte random values:

Figure 19

Figure 20

The encrypted data will be embedded in the final decryptor.

The malware determines the location of the resource with ID = 100 using FindResourceW (0xA = RT_RCDATA):

Figure 21

The resource is loaded into memory via a function call to LoadResource:

Figure 22

The builder has embedded 4 resources in the “.rsrc” section. We’ll give the details about the other resources in the following paragraphs:

Figure 23

The binary uses the undocumented RtlImageNtHeader function to retrieve the NT header of the resource:

Figure 24

The section name called “.xyz” is replaced with “.data” by the process:

Figure 25

The CheckSumMappedFile method is used to compute the checksum of the extracted resource. The value will populate the PE checksum field in the header:

Figure 26

The builder creates the decryptor file called “LB3Decryptor.exe” using CreateFileW:

Figure 27

The process writes the modified resource to the decryptor executable via a call to WriteFile:

Figure 28

Running with the -type enc -exe (-pass) -pubkey pub.key -config config.json -ofile LB3.exe parameters

We only highlight the differences between this case and the first one. The builder extracts the resource with ID = 101, and the encryptor will contain the RSA public key and the ransom note content. If it’s running with the “-pass” parameter, the ransomware avoids sandboxes and increases the difficulty of the dynamic analysis. SentinelOne also analyzed the LockBit 3.0 ransomware and mentioned the “-pass” parameter.

Running with the -type enc -dll (-pass) -pubkey pub.key -config config.json -ofile LB3_Rundll32.dll parameters

The builder extracts the resource with ID = 103, and the encryptor will be a DLL file with multiple export functions (see figure 29).

Figure 29

Running with the -type enc -ref -pubkey pub.key -config config.json -ofile LB3_ReflectiveDll_DllMain.dll parameters

The builder extracts the resource with ID = 106, and the encryptor will be a DLL file with a single export function. The execution flows of the two different DLLs are similar, as highlighted in the figure below.

Figure 30

According to our preliminary analysis of the LockBit 3.0 encryptor, the builder is legit and, unfortunately, can represent a gold mine for cybercriminals. Please do not use the builder for malicious purposes because you’ll be persecuted according to the law.

Article Link: A technical analysis of the leaked LockBit 3.0 builder – CYBER GEEKS