By Ronen Ahdut, Cyber Threat Intelligence Leader

LockBit was introduced in 2019 and operates in a Ransomware-as-a-Service (RaaS) model. And it’s running the most prolific and successful operations to date.

In September 2022, a developer who worked with the group leaked a “builder” – a collection of executables and DLLs that can be configured and are responsible for creating both the encryption executable and the decryptor for the encrypted files.

Unlike Conti’s leaked source code, a builder offers limited options in terms of valuable information for defenders and attackers alike. But it can still be used by both sides to better understand it, and potentially create a copycat version of it.

The recent attack

On September 21, 2022 an unknown person claimed that his team has managed to hack into LockBit servers and found a LockBit3 (LockBit Black) builder:

This relates to a now-deleted post by VX-Underground that mentioned that they were contacted on September 10^th by an individual named “Proton” who shared a similar builder with them. The tweet mentioned that the LockBit group had confirmed the leak and noted it was done by an ex-programmer who was unhappy with the group:

Due to the lack of “buzz” that “proton” was expecting, we believe that “Ali Qushji” (the second leak) is the same individual under a different username.

Both leaked versions were later published on GitHub:

Leaked builder analysis

While the files from both leaks have a different checksum, their content is the same:

“Build folder” – An empty folder, once “Build.bat” will be executed, the folder will contain all the extracted files.

“Build.bat” – Stores all commands to successfully build necessary executables, DLLs, and private\public keys.

“Builder.exe” – Will be used by “build.bat” to create both the encryption and decryption executables, using the provided keys.

“Config.json” – A configuration file that stores the properties that will be used by the encryption executable (ransom note, kill\whitelist processes, and services, etc.)

“Keygen.exe” – Responsible for the creation of the private and public keys, these will be used in the encryption and decryption process.

Build.bat

The batch file uses “keygen” to build the private and public keys.

Using “builder,” the decryptor is created via the private key, and the configuration file.

Next will be the encryption executable which is created using the public key and the configuration file.

Following this, the batch file will create a password-protected executable, DLLs to be used by “Rundll32” (both password protected, and not protected), and a DLL to be used as “Reflectivedll” (DLL injection used in memory and not on disk).

Config.json

As seen above, the config file is responsible for the options that will be used in the encryption process, it allows attackers to modify their build according to their current target, including modification to the regular ransom note left by “LockBit,” top highlights that we wanted to note in the config file:

Using the config file, an operator can choose either a stealthy approach or go “Guns blazing.”

The following are the default parameters for some of the options seen in the configuration file:

This allows us to better understand LockBit’s operation upon execution, all system-related files, extensions, and folders are whitelisted to avoid any system crash, an option to whitelist an entire host is also available, as well as Tor browser that will be used for communications with the attackers.

On the other hand, all backup-related processes and services are killed, as well as Microsoft applications like Outlook, PowerPoint, Word, etc.

“impers_account” will use the given credentials for login attempts.

The note can also be edited:

Once all commands were executed successfully, the previously empty “Build” folder will now contain the following:

As previously seen in the first publicly available LockBit3 sample, attackers have an option to use a password-protected encryptor:

Image from Infinitum labs analysis

“LB3_pass, LB3_Rundll32_pass” are both password-protected versions of the same files on the folder.

Text files associated with the password-protected files are also present:

And while they serve as a guide for how to use the newly available pass-protected files, they also uncover the option to encrypt specific files and folders based on the attacker’s request (physical and network shares alike). This could be used, for example, in a sensitive situation like the encryption of a healthcare provider – attackers can exclude any critical\life saving paths.

Encryption and Decryption

Once executed, the encryptor will be used as defined in the Configuration file. Once the process is complete, files will have their extension changed and will be inaccessible to the user:

The ransom note will be dropped on the desktop as well as all folders, note that we have altered the note contents:

The decryptor is a simple, GUI executable that is used to decrypt all encrypted files:

Note that not all files were successfully decrypted on the first try, but all remaining files were decrypted on the second try:

The decryption process was FAST.

LockBitSupp’s official response

A group member called “LockBitSupp” has addressed the issue on an underground forum, confirming that a developer has leaked the builder, text is translated from Russian:

“In essence, the coder of this particular locker was tired of coding, worried about the situation on the planet, regularly drank sedative pills, had mental problems, paranoia and constant stress, which will only intensify now, probably because of this he did not work enough and could not cope with assigned tasks.

Due to low activity and online during the development process, I refused to pay him and offered payment through a guarantor with post-payment after the work was completed, so that I would be calmer that he would complete the tasks in a shorter time, and that I would not throw him money and I will pay for his work, he refused, citing the fact that registration is closed on the xss, and he does not trust the guarantor of the expo.

Later, he calmed down, agreed to my conditions, but 3 hours passed, and he wrote ‘in general, I thought carefully, and I’m leaving’ and forever lost his temper. Then some interesting builder appeared on the network, a proud coder committed an insidious revenge for not wanting to work through a guarantor, time will tell whether he did the right thing or not, God be his judge.

The situation, of course, is not pleasant, but this will not affect the work of the affiliate program in any way, on the contrary, it only motivates to hire new coders and code new products.  Are there coding gods here? Send me a private message if you need a job.  Decryption keys are generated on the server and there cannot be any payments from this locker came and continue to come daily.”

This has also been followed by the following statement:

Our take

Unlike Conti’s leaked source code, LockBit had “only” suffered from a leak of a builder.

While the situation is indeed unpleasant for the group (they are also being mocked by other threat actors for paying $50,000 for bug bounty, but not paying a developer), the fact that no source has been leaked allows LockBit to adapt to the situation.

A new update should be seen soon according to LockBitSupp.

As the build does have some value for defenders, it can also be used by threat actors who wish to use the builder in their operations, as we have demonstrated with an altered ransom note.

LockBit has previously shared their panel. This is used by affiliates to create builds based on preferences suited for their target:

Options are generally similar to the builder. BUT – the panel is updated and relates to LockBit directly, any update that will be implemented by the group will take place in the panel.

The leaked builder cannot be updated and defenders can analyze it and place defense mechanisms related directly to the TTP’s shown in the builder.

While it is not an easy task for LockBit group, all options could be having the same names. But the TTP’s will be completely different, thus evading any defense mechanisms set following the builder’s leak.

As unpleasant as it may be for the group, we believe that this will not impair any ongoing or future operations. This will likely create a small setback following the leaked TTP’s and prompt an expected update.

XDR rises to the challenge

Cynet 360 AutoXDR™ was effective against LockBit both in simulated environments, as well as real-life scenarios.

Interested in learning how we can help?

Meet Cynet’s MDR team, CyOps. We monitor our customers’ environments 24/7 and will contact you in cases where indicators of this vulnerability are detected in your environment.

The team is available to our customers for any issues, questions, and to provide additional information around the clock.

If you have questions about this leak, you can contact us directly at:

CyOps Mailbox – [email protected]

Israel: +972 72-3369736

UK: +44 2032 909051

US : +1 (347) 474-0048

Stay safe!