{
	"id": "74576944-ce42-4e08-854b-d5d05803a283",
	"created_at": "2026-04-06T00:10:13.836635Z",
	"updated_at": "2026-04-10T03:21:06.340501Z",
	"deleted_at": null,
	"sha1_hash": "0f62a0705408703ed12072c7e64b52aad2ffe6dd",
	"title": "Lockbit leak, research opportunities on tools leaked from TAs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1725528,
	"plain_text": "Lockbit leak, research opportunities on tools leaked from TAs\r\nBy Eduardo Ovalle\r\nPublished: 2023-08-25 · Archived: 2026-04-05 16:51:10 UTC\r\nLockbit is one of the most prevalent ransomware strains. It comes with an affiliate ransomware-as-a-service\r\n(RaaS) program offering up to 80% of the ransom demand to participants, and includes a bug bounty program for\r\nthose who detect and report vulnerabilities that allow files to be decrypted without paying the ransom. According\r\nto the Lockbit owners, the namesake cybercriminal group, there have been bounty payments of up to 50 thousand\r\ndollars. In addition to these features, Lockbit has offered a searchable portal to query leaked information from\r\ncompanies targeted by this ransomware family, and even offered payment to those who get tattooed with a Lockbit\r\nlogo on their body.\r\nLockbit v3, also known as Lockbit Black, was detected for the first time in June 2022 and represents a challenge\r\nfor analysts and automated analysis systems. Among the most challenging characteristics, we can highlight the\r\nfollowing:\r\nIt supports the usage of encrypted executables with randomly generated passwords. This prevents\r\nexecution and hinders automatic analysis unless the appropriate password is provided at the command line.\r\nThe payload includes strong protection techniques against reverse-engineering analysis.\r\nIt includes many undocumented kernel-level Windows functions.\r\nIn September of 2022, multiple security news professionals wrote about and confirmed the leakage of a builder for\r\nLockbit 3. This tool allowed anyone to create their own customized version of the ransomware. Two different\r\nusers published the files needed to create different flavors of this ransomware:\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 1 of 13\n\nLockbit builder uploaded to GitHub\r\nAccording to our analysis, two different variants were spotted by the X’s (previously known as Twitter) users\r\n@protonleaks and @ali_qushji. Our timestamp analysis confirmed that the binary, builder.exe, was slightly\r\ndifferent in both leaks. The version from protonleaks registers the compilation date 2022/09/09. Meanwhile, the\r\nversion from ali_qushji was compiled on 2022/09/13. A similar difference in compilation time was identified in\r\nthe malware’s template binaries (embedded and incomplete versions of the malware used to build the final version\r\nready for distribution).\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 2 of 13\n\nALI_QUSHJI leak builder\r\nPROTONLEAKS leak builder\r\nWho abused these builders and how?\r\nImmediately after the builder leak, during an incident response by our GERT team, we managed to find an\r\nintrusion that leveraged the encryption of critical systems with a variant of Lockbit 3 ransomware. Our protection\r\nsystem confirmed and detected the threat as “Trojan.Win32.Inject.aokvy”.\r\nThe intrusion included TTPs similar to those highlighted in the report by Kaspersky Threat Intelligence team from\r\nAugust 2022 about the eight main ransomware groups behind ransomware attacks, including tactics for\r\nreconnaissance, enumeration, collection and deployment.\r\nAlthough this variant was confirmed as Lockbit, the ransom demand procedure was quite different from the one\r\nknown to be implemented by this threat actor. The attacker behind this incident decided to use a different ransom\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 3 of 13\n\nnote with a headline related to a previously unknown group, called NATIONAL HAZARD AGENCY.\r\nOriginal Lockbit ransom note\r\nManaged incident ransom note\r\nThe ransom note used in this case directly described the amount to be paid to obtain the keys, and directed\r\ncommunications to a Tox service and email, unlike the Lockbit group, which uses its own communication and\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 4 of 13\n\nnegotiation platform.\r\nAccording to other analysts’ publications, different groups appeared using the exfiltrated builders, but with their\r\nown notes and communication channels:\r\nGetLucky ransom note, Source: AnyRun\r\nGERT’s approach to analyzing the builder and payload\r\nWhile many threat actors took advantage of the leak to propose new ransomware groups, Kaspersky’s GERT team\r\ndecided to analyze the builder to understand its construction methodology and define additional analysis\r\nopportunities.\r\nThe analysis of the builder addressed some of the challenges posed by the ransomware payload:\r\nThe builder contains no protection mechanisms as it will be used by the actors and should not be\r\nexposed: no anti-debugging (at least in the builder itself), no anti-reversing, no code obfuscation, sample\r\ntemplates embedded as resource (decrypter, EXE, DLL, reflective DLL).\r\nWe learned how the configuration parameters are embedded within the payload without requiring\r\nreverse engineering of the final binary.\r\nThe builder presents different configuration parameters that are compulsorily embedded in the malware.\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 5 of 13\n\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 6 of 13\n\nEmbedded resources\r\nThe encrypter and decrypter templates are embedded into the builder’s resource section:\r\n100: LockBit 3.0 Decryptor (EXE)\r\n101: LockBit 3.0 Encryptor (EXE)\r\n103: LockBit 3.0 Encryptor (DLL)\r\n106: LockBit 3.0 Encryptor (Reflective DLL)\r\nAn approach was proposed – based on the methodology of constructing the configuration parameters and how\r\nthey were added to the selected payload – to figure out:\r\nHow parameter configuration parsing is performed\r\nHow data transformation is applied\r\nHow the configuration is encrypted and then stored within the final binary\r\nThe payload-embedded configuration\r\nThe reverse-engineering analysis identified that the configuration is embedded in a section named .pdata, which is\r\nfirst encrypted using an XOR function with a key derived from a random seed and then compressed to embed it in\r\nthe payload.\r\nIf the sample is configured to be encrypted using a password, the configuration will be similarly embedded in the\r\nbinary first and then the sample will be encrypted with a unique key.\r\n.pdata – this section contains the embedded configuration\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 7 of 13\n\nEmbedded data (encrypted and compressed)\r\nThe creation of the XOR key, used to decrypt the content embedded in the section, depends on two random keys\r\nalong with other fixed values embedded in the binary source code.\r\nDecryption and subsequent decompression results in a set of sample configuration parameters, some of them with\r\neasily identifiable encryption mechanisms.\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 8 of 13\n\nDecrypted section\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 9 of 13\n\nDecompressed section\r\nThe next step is to interpret the fields and apply the required decryption to each of them to transform them into\r\nintelligible values.\r\nThe builder uses a custom hashing function that produces a 4-byte value for each of the values entered in the\r\nconfiguration parameters white_folders, white_files, white_extens and white_hosts. Other fields are stored with\r\nBase64 and ROR13.\r\nFinally, interpreting the meaning of the fields in the config.json file and the relationship between the fields allows\r\nus to confirm that:\r\nMost configuration fields are easy to interpret based on their name and content.\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 10 of 13\n\nSome fields accept values only from a list of values.\r\nMany fields with string values are stored using ROR13 before being loaded into the payload configuration.\r\nSome fields accept multiple list values, using the “;” separator.\r\nCredentials must be stored in the format \u003cuser\u003e:\u003cpassword\u003e.\r\nConfig.json – what the fields mean\r\nBased on these results, we defined a sample analysis procedure and applied it to multiple samples to determine the\r\ntype of actors, objectives and construction preferences of the payloads.\r\nStatistics of samples reported in our intelligence platforms\r\nThe objective of this analysis is to understand the parameters applied by different actors to build the malware as\r\nconfigured in samples detected in the wild.\r\nDuring our research, 396 distinct samples were analyzed. According to the timestamps, mostly samples created by\r\nthe leaked builders were detected, but other unknown builders dated June and July 2022 were also identified.\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 11 of 13\n\nGeneral statistics of the embedded configuration:\r\nMany of the detected parameters correspond to the default configuration of the builder, only some\r\ncontain minor changes. This indicates the samples were likely developed for urgent needs or possibly by\r\nlazy actors.\r\nThe most recurrent encryption targets are local disks and network shares, avoiding hidden folders.\r\nThe samples generally run a single instance and enable the following parameters:\r\nkill service\r\nkill process\r\nkill defender\r\ndelete logs\r\nself-destruct\r\nMost of the samples identified do not enable the system shutdown option.\r\nNetwork deployment by PSEXEC is configured in 90% of the samples, while deployment by GPO is\r\nconfigured in 72%.\r\nVery few samples enable communication to C2.\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 12 of 13\n\nDetailed statistics\r\nThe C2 communication configuration showed it was rarely used and included three test domains. No suspicious or\r\nmalicious domains were identified in the analyzed samples, showing there’s no interest for establishing C2\r\ncommunications using the leaked payloads.\r\nMoreover, inside the configuration, the impersonation data list (credentials registered within the payload\r\nconfiguration) records general data with a default brute-force list. But it was possible to detect other binaries with\r\nspecific data that allow identifying the organizations or individuals attacked.\r\nIt is important to keep in mind that Lockbit payloads and other ransomware actors integrate this type of\r\ninformation inside samples, and the handling of such samples must be done properly to avoid information leaks.\r\nFinally, some statistics relate to the usage of leaked builders by actors other than the “original” Lockbit. We found\r\nthat 77 samples make no reference to a “Lockbit” string (case-insensitive) in the ransom note, which is quite\r\nunexpected according to LB TTP.\r\nThe modified ransom note without reference to Lockbit or with a different contact address (mail/URL) reveals\r\nprobable misuse of the builder by actors other than the “original” Lockbit.\r\nSource: https://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nhttps://securelist.com/lockbit-ransomware-builder-analysis/110370/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://securelist.com/lockbit-ransomware-builder-analysis/110370/"
	],
	"report_names": [
		"110370"
	],
	"threat_actors": [],
	"ts_created_at": 1775434213,
	"ts_updated_at": 1775791266,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0f62a0705408703ed12072c7e64b52aad2ffe6dd.pdf",
		"text": "https://archive.orkl.eu/0f62a0705408703ed12072c7e64b52aad2ffe6dd.txt",
		"img": "https://archive.orkl.eu/0f62a0705408703ed12072c7e64b52aad2ffe6dd.jpg"
	}
}