{
	"id": "7d4284c4-a924-4e24-8175-80ba6f2def30",
	"created_at": "2026-04-06T00:14:21.404074Z",
	"updated_at": "2026-04-10T03:35:59.525306Z",
	"deleted_at": null,
	"sha1_hash": "c0952230200720fc0601d9c2a480deb8e340adca",
	"title": "Using the LockBit builder to generate targeted ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 587146,
	"plain_text": "Using the LockBit builder to generate targeted ransomware\r\nBy Eduardo Ovalle\r\nPublished: 2024-04-15 · Archived: 2026-04-05 21:53:01 UTC\r\nThe previous Kaspersky research focused on a detailed analysis of the LockBit 3.0 builder leaked in 2022. Since\r\nthen, attackers have been able to generate customized versions of the threat according to their needs. This opens\r\nup numerous possibilities for malicious actors to make their attacks more effective, since it is possible to configure\r\nnetwork spread options and defense-killing functionality. It becomes even more dangerous if the attacker has valid\r\nprivileged credentials in the target infrastructure.\r\nIn a recent incident response engagement, we faced this exact scenario: the adversary was able to get the\r\nadministrator credential in plain text. They generated a custom version of the ransomware, which used the\r\naforementioned account credential to spread across the network and perform malicious activities, such as killing\r\nWindows Defender and erasing Windows Event Logs in order to encrypt the data and cover its tracks.\r\nIn this article, we revisit the LockBit 3.0 builder files and delve into the adversary’s steps to maximize impact on\r\nthe network. In addition, we provide a list of preventive activities that can help network administrators to avoid\r\nthis kind of threat.\r\nRevisiting the LockBit 3.0 builder files\r\nThe LockBit 3.0 builder has significantly simplified creating customized ransomware. The image below shows the\r\nfiles that constitute it. As we can see, keygen.exe generates public and private keys used for encryption and\r\ndecryption. After that, builder.exe generates the variant according to the options set in the config.json file.\r\nLockBit builder files\r\nThis whole process is automated with the Build.bat script, which does the following:\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 1 of 12\n\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\nIF exist Build (ERASE /F /Q Build\\*.*) ELSE (mkdir Build)\r\nkeygen -path Build -pubkey pub.key -privkey priv.key\r\nbuilder -type dec -privkey Build\\priv.key -config config.json -ofile Build\\LB3Decryptor.exe\r\nbuilder -type enc -exe -pubkey Build\\pub.key -config config.json -ofile Build\\LB3.exe\r\nbuilder -type enc -exe -pass -pubkey Build\\pub.key -config config.json -ofile Build\\LB3_pass.exe\r\nbuilder -type enc -dll -pubkey Build\\pub.key -config config.json -ofile Build\\LB3_Rundll32.dll\r\nbuilder -type enc -dll -pass -pubkey Build\\pub.key -config config.json -ofile\r\nBuild\\LB3_Rundll32_pass.dll\r\nbuilder -type enc -ref -pubkey Build\\pub.key -config config.json -ofile\r\nBuild\\LB3_ReflectiveDll_DllMain.dll\r\nThe config.json file allows enabling impersonation features (impersonation) and defining accounts to\r\nimpersonate (impers_accounts). In the example below, the administrator account was used for impersonation.\r\nThe configuration also allows enabling the encryption of network shares (network_shares), killing Windows\r\nDefender (kill_defender), and spreading across the network via PsExec (psexec_netspread). After a successful\r\ninfection, the malicious sample can delete Windows Event Logs (delete_eventlogs) to cover its tracks.\r\nCustom configuration\r\nBesides this, the builder allows the attacker to choose which files, in which directories, and in which systems they\r\ndo not want to encrypt. If the attacker knows their way around the target infrastructure, they can generate malware\r\ntailored to the specific configuration of the target’s network architecture, such as important files, administrative\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 2 of 12\n\naccounts, and critical systems. The images below show the process of generating customized ransomware\r\naccording to the above configuration, and the resulting files. As we can see, LB3.exe is the main file. This is the\r\nartifact that will be delivered to the victim. The builder also generates LB3Decryptor.exe for recovering the files,\r\nas well as several different variants of the main file. For example, LB3_pass.exe is a password-protected version\r\nof the ransomware, while the reflective DLL can be used to bypass the standard operating system loader and inject\r\nmalware directly into memory. The TXT files contain instructions on how to execute the password-protected files.\r\nCreation of a customized LockBit version\r\nGenerated LockBit files\r\nWhen we executed this custom build on a virtual machine, it performed its malicious activities and generated\r\ncustom ransom note files. In real-life scenarios, the note will include details on how the victim should contact the\r\nattackers to obtain a decryptor. It is worth noting that negotiating with the attackers and paying ransom should not\r\nbe an option. Besides the ethical issues involved, there is doubt whether a tool for recovering the files will ever be\r\nprovided.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 3 of 12\n\nCustom ransom note\r\nHowever, as we generated the ransomware sample and a corresponding decryptor ourselves in a controlled lab\r\nenvironment, we were able to test if the latter actually worked. We tried to decrypt our encrypted files and found\r\nout that if the decryptor for the sample was available, it was indeed able to recover the files, as shown in the image\r\nbelow.\r\nLB3Decryptor execution\r\nThat said, we must once again underscore that even a correctly working decryptor is no guarantee that the\r\nattackers will play fair.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 4 of 12\n\nThe recent LockBit takedown and custom LockBit builds\r\nIn February 2024, the international law enforcement task force Operation Cronos gained visibility into LockBit’s\r\noperations after taking the group down. The collaborative action involved law enforcement agencies from 10\r\ncountries, which seized the infrastructure and took control of the LockBit administration environment. However, a\r\nfew days after the operation, the ransomware group announced that they were back in action.\r\nThe takedown operation allowed LEAs to seize the group’s infrastructure, obtain private decryption keys and\r\nprepare a decryption toolset based on a known-victim ID list obtained by the authorities. The\r\ncheck_decryption_id utility checks if the ransom ID enabled for the victim is on the list of known decryption\r\nkeys:\r\ncheck_decryption_id.exe execution\r\nThe check_decrypt tool assesses decryptability: while there is a possibility that the files will be recovered, the\r\noutcome of the process depends on multiple conditions, and this tool just checks which of these conditions are met\r\nin the systems being analyzed. A CSV file is created, listing files that can be decrypted and providing an email\r\naddress to reach out to for further instructions on restoring the files:\r\ncheck_decrypt.exe execution\r\nThis toolset caught our attention because we had investigated several cases relating to the LockBit threat. We\r\nnormally recommend that our customers save their encrypted critical files and wait for an opportunity to decrypt\r\nthem with the help of threat researches or artifacts seized by the authorities, which is merely a matter of time. We\r\nran victim IDs and encrypted files analyzed by our team through the decryption tool, but most of them showed the\r\nsame result:\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 5 of 12\n\nTesting the tool on a victim ID obtained by our team\r\nThe check_decrypt also confirmed that it was not possible to decrypt the files by using the database of known\r\nkeys:\r\nTesting the check_decrypt.exe tool on encrypted files\r\nOur analysis and previous research confirmed that files encrypted with a payload generated with the help of the\r\nleaked LockBit builder could not be decrypted with existing decryption tools, essentially because the independent\r\ngroups behind these attacks did not share their private keys with the RaaS operator.\r\nGeography of the leaked LockBit builder-based attacks\r\nCustom LockBit builds created with the leaked builder were involved in a number of incidents all over the world.\r\nThese attacks were most likely unrelated and executed by independent actors. The leaked builder apparently has\r\nbeen used by LockBit ransomware competitors to target companies in the Commonwealth of Independent States,\r\nviolating the group’s number one rule to avoid compromising CIS nationals. This triggered a discussion on the\r\ndark web, where LockBit operators tried to explain that they had nothing to do with these attacks.\r\nIn our incident response practice, we have come across ransomware samples created with the help of the leaked\r\nbuilder in incidents in Russia, Italy, Guinea-Bissau, and Chile. Although the builder provides a number of\r\ncustomization options, as we have shown above, most of the attacks used the default or slightly modified\r\nconfiguration. However, one incident stood out.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 6 of 12\n\nA real-life incident response case involving a custom LockBit build\r\nIn a recent incident response engagement, we faced a ransomware scenario involving a LockBit sample built with\r\nthe leaked builder and featuring impersonation and network spread capabilities we had not seen before. The\r\nattacker was able to exploit an internet-facing server that exposed multiple sensitive ports. Somehow, they were\r\nable to obtain the administrator password – we believe that it may have been stored in plain text inside a file, or\r\nthat the attacker may have used social engineering. Then, the adversary generated custom ransomware using the\r\nprivileged account they had access to. Our team was able to obtain the relevant fields present in the config.json\r\nfile that the attacker used:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n\"impersonation\": true,\r\n\"impers_accounts\": \"Administrator:************\",\r\n\"local_disks\": true,\r\n\"network_shares\": true,\r\n\"running_one\": false,\r\n\"kill_defender\": true,\r\n\"psexec_netspread\": true,\r\n\"delete_eventlogs\": true,\r\nAs we can see, the custom version has the ability to impersonate the administrator account, affect network shares,\r\nand spread easily across the network via PsExec.\r\nMoreover, it is configured to run more than once on each host. One of the first steps that the executable does when\r\nstarted is check for, and create, a unique mutex based on a hash sum of the ransomware public key in the format:\r\n“Global\\%.8x%.8x%.8x%.8x%.8x”. If the running_one flag is set to true in the configuration and the mutex is\r\nalready present in the operating system, the process will exit.\r\nIn our case, the configuration allowed concurrent executions of several ransomware instances on the same host.\r\nThis behavior, combined with the use of configuration flags for automatic network propagation with high-privileged domain credentials, led to an uncontrolled avalanche effect: each host that got infected then started\r\ntrying to infect other hosts on the network, including those already infected. From an incident response point of\r\nview, this means finding evidence, if available, of different origins for the same threat. See below the evidence\r\nfound on one host of remote service creation by PsExec with authentication completed from multiple infected\r\nhosts.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 7 of 12\n\nRemote service creation by PsExec\r\nAlthough this evidence was present in the infected systems, most of the logs had been deleted by the ransomware\r\nimmediately after the initial infection. Because of that, it was not possible to determine how the attacker was able\r\nto gain access to the server and to the administrator password. The remote service creation logs remained because\r\nwhen the malware was performing lateral movement on the network, it generated new logs, which it did not\r\ndelete, and which were helpful in detecting its spread across the infrastructure.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 8 of 12\n\nEvent logs cleared\r\nBy analyzing some of the traces that were not erased on the initial affected server, we identified compressed Gzip\r\ndata in a memory stream. The data was encoded in Base64. After decoding and decompression, we found evidence\r\nof the use of Cobalt Strike. We were able to identify the C2 server used by the attacker to communicate with the\r\naffected machine and promptly sent this indicator to the customer for blacklisting.\r\nWe also spotted the use of the SessionGopher script. This tool uses WMI to extract saved session information for\r\nremote desktop access tools, such as WinSCP, PuTTY, FileZilla, and Microsoft Remote Desktop. This is\r\naccomplished by querying HKEY_USERS for PuTTY, WinSCP, and Remote Desktop saved sessions. In\r\nThorough mode, the script can identify .ppk, .rdp, and .sdtid files in order to extract private keys and session\r\ninformation. It can be run remotely by using the -iL option followed by the list of computers. The -AllDomain\r\nflag allows running it against all AD-joined computers. As shown in the image below, the script can easily extract\r\nsaved passwords for remote connections. The results can be exported to a CSV file for later use.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 9 of 12\n\nPassword extraction using SessionGopher\r\nAlthough SessionGopher is designed for collecting stored credentials, it was not the tool used by the attackers for\r\ninitial credential dumping. Instead, they employed SessionGopher to collect additional credentials and services in\r\nthe infrastructure at a later stage.\r\nOnce we identified the C2 domains and some other IP addresses related to the attacker and extracted details about\r\nthe impersonated accounts and tools implemented for automatic deployment, the customer changed all affected\r\nusers’ credentials and configured security controls to avoid PsExec execution, thus stopping the infection.\r\nMonitoring network and user account activities allowed us to identify the infected systems and isolate them for\r\nanalysis and recovery.\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 10 of 12\n\nThis case shows an interesting combination of techniques used to gain and maintain access to the target network,\r\nas well as encrypt important data and impair defenses. Below are the TTPs identified for this scenario.\r\nTactic Technique ID\r\nImpact Data Encrypted for Impact T1486\r\nDefense Evasion, Persistence, Privilege Escalation, Initial\r\nAccess\r\nValid Accounts T1078.002\r\nCredential Access\r\nCredentials from Password\r\nStores\r\nT1555\r\nLateral Movement Remote Services T0886\r\nDiscovery Network Service Discovery T1046\r\nDefense evasion Clear Windows Event Logs T1070.001\r\nDefense evasion Impair Defenses T1562\r\nPreventive actions against ransomware attacks\r\nRansomware attacks can be devastating, especially if the attackers manage to get hold of high-privileged\r\ncredentials. Measures for mitigating the risk of such an attack may vary depending on the technology used by the\r\ncompany. However, there are certain infrastructure-agnostic techniques:\r\nUsing a robust, properly-configured antimalware solution, such as Kaspersky Endpoint Security\r\nImplementing Managed Detection and Response (MDR) to proactively seek out threats\r\nDisabling unused services and ports to minimize the attack surface\r\nKeeping all systems and software up to date\r\nConducting regular penetration tests and vulnerability scanning to identify vulnerabilities and promptly\r\napply appropriate countermeasures\r\nAdopting regular cybersecurity training, so that employees are aware of cyberthreats and ways to avoid\r\nthem\r\nMaking backups frequently and testing them\r\nConclusion\r\nOur examination of the LockBit 3.0 builder files shows the alarming simplicity with which attackers can craft\r\ncustomized ransomware, as evidenced by a recent incident where adversaries exploited administrator credentials\r\nto deploy a tailored ransomware variant. This underscores the need for robust security measures capable of\r\nmitigating this kind of threat effectively, as well as adoption of a cybersecurity culture among employees.\r\nKaspersky products detect the threat with the following verdicts:\r\nTrojan-Ransom.Win32.Lockbit.gen\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 11 of 12\n\nTrojan.Multi.Crypmod.gen\r\nTrojan-Ransom.Win32.Generic\r\nAnd the SessionGopher script, as:\r\nHackTool.PowerShell.Agent.l\r\nHackTool.PowerShell.Agent.ad\r\nSource: https://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nhttps://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://securelist.com/lockbit-3-0-based-custom-targeted-ransomware/112375/"
	],
	"report_names": [
		"112375"
	],
	"threat_actors": [
		{
			"id": "0fc739cf-0b82-48bf-9f7d-398a200b59b5",
			"created_at": "2022-10-25T16:07:23.797925Z",
			"updated_at": "2026-04-10T02:00:04.752608Z",
			"deleted_at": null,
			"main_name": "LockBit Gang",
			"aliases": [
				"Bitwise Spider",
				"Operation Cronos"
			],
			"source_name": "ETDA:LockBit Gang",
			"tools": [
				"3AM",
				"ABCD Ransomware",
				"CrackMapExec",
				"EmPyre",
				"EmpireProject",
				"LockBit",
				"LockBit Black",
				"Mimikatz",
				"PowerShell Empire",
				"PsExec",
				"Syrphid"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "bc289ba8-bc61-474c-8462-a3f7179d97bb",
			"created_at": "2022-10-25T16:07:24.450609Z",
			"updated_at": "2026-04-10T02:00:04.996582Z",
			"deleted_at": null,
			"main_name": "Avalanche",
			"aliases": [],
			"source_name": "ETDA:Avalanche",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434461,
	"ts_updated_at": 1775792159,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c0952230200720fc0601d9c2a480deb8e340adca.pdf",
		"text": "https://archive.orkl.eu/c0952230200720fc0601d9c2a480deb8e340adca.txt",
		"img": "https://archive.orkl.eu/c0952230200720fc0601d9c2a480deb8e340adca.jpg"
	}
}