{
	"id": "6a8f7fea-18fd-46da-a157-f821e0208625",
	"created_at": "2026-04-06T00:08:21.14306Z",
	"updated_at": "2026-04-10T13:11:32.895097Z",
	"deleted_at": null,
	"sha1_hash": "f5260d45e5d37dd10c104ce214ce54bb4c05c0d7",
	"title": "LockBit 3.0 Ransomware Unlocked",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4125079,
	"plain_text": "LockBit 3.0 Ransomware Unlocked\r\nBy Dana Behling\r\nPublished: 2022-10-15 · Archived: 2026-04-05 18:17:10 UTC\r\nBehavioral Summary \r\nLockBit 3.0 seems to love the spotlight. Also known as LockBit Black, this ransomware family announced itself\r\nin July 2022 stating that it would now offer the data of its nonpaying victims online in a freely available easy-to-use searchable form. Then in July, it introduced a bug bounty program to find defects in its ransomware. The\r\ngroup even offered money to people willing to get the LockBit logo tattooed on their bodies. Regardless of the\r\npublic spotlight LockBit continues its rise to the top of the ransomware ecosystem and, according to The Record,\r\nis currently the most prevalent ransomware strain.  \r\nLockBit 3.0 is a challenge for security researchers because each instance of the malware requires a unique\r\npassword to run without which analysis is extremely difficult or impossible. Additionally, the malware is heavily\r\nprotected against analysis and makes use of a substantial number of undocumented kernel level Windows\r\nfunctions. \r\nHowever, in September 2022 Twitter user @3xp0rtblog announced that the builder for the ransomware was leaked\r\nby @ali_qushji and available for download from GitHub.  \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 1 of 21\n\nFigure 1: LockBit 3.0 Builder Leaked on Twitter \r\nThis leaked source allows for complete and unhindered analysis, but unfortunately also means that many new\r\ngroups are emerging, using the same or modified versions of LockBit 3.0 originating from this builder. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 2 of 21\n\nFigure 2: LockBit 3.0 Builder \r\nThe builder, once extracted, contains the files shown in Figure 2, with the Build directory empty.  Running the\r\nBuild.bat file, which includes the contents shown in Figure 3, automates the build process and populates the Build\r\ndirectory with a unique instance of the ransomware. The resulting files are shown in Figure 4. \r\nBuild.bat \r\nFigure 3: Content of Build.bat \r\nThe commands that make up Build.bat, clear the Build directory, and then call keygen to generate the public and\r\nprivate encryption keys. The next lines that start with “builder”, generate the different variations of the LockBit\r\n3.0 ransomware by supplying the builder with different command line options. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 3 of 21\n\nFigure 4: LockBit 3.0 File Listing after Build \r\nDescription of Generated Files \r\nDECRYPTION_ID.txt – Text file containing a 16-character victim ID made from the first eight hex bytes\r\nof the public key that is used to uniquely identify a victim \r\nLB3.exe – Compiled ransomware, which doesn’t require a password \r\nLB3Decryptor.exe – Decryptor for the ransomware, which works with all the variations here \r\nLB3_pass.exe – Same as LB3.exe however requires a password to run.  The password and instructions are\r\nfound in Password_exe.txt in this directory \r\nLB3_RelectiveDLL_DLLMain.dll – Version of the ransomware that is meant to be reflectively loaded and\r\nexecuted in memory \r\nLB3_Rundll32.dll – DLL version of ransomware, which doesn’t require a password. \r\nLB3_Rundll32_pass.dll – DLL version of ransomware, which requires the password found in the\r\nPassword_dll.txt file \r\nPassword_dll.txt – Contains password and instructions for using LB3_Rundll32_pass.dll \r\nPassword_exe.txt – Contains password and instructions for using LB3_pass.exe \r\npriv.key – A private encryption key unique to this build that is used to encrypt victim files \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 4 of 21\n\npub.key – A public encryption key unique to this build that is used generate various strings that tie this\r\ninstance of the ransomware to a victim.\r\nkeygen.exe \r\nThe first executable called in Build.bat is keygen.exe. It generates a unique public-private key pair for each build\r\nas well as the decryption ID. Keygen appears to rely heavily on MIRACL, which according to its own description\r\nis, “…a C software library that is widely regarded by developers as the gold standard open-source SDK for elliptic\r\ncurve cryptography.” The generated keys are base64 encoded and saved to files priv.key and pub.key.  Then the\r\nunencoded first eight bytes of the public key are converted to their hex values and saved to the\r\nDECRYPTION_ID.txt file, which acts as a unique victim identification number. \r\nbuilder.exe  \r\nAs shown earlier in Figure 4, the builder.exe file creates two executables, three dynamic link libraries, and two\r\ntext files.  In order to complete this, it requires the existing config.json (Figure 2), and the priv.key/pub.key files\r\ngenerated in the previous step by keygen.exe and shown in Figure 4.  The builder.exe file itself also holds\r\nessentials. In its resource section are four executable template files.  Each of these are used to construct the DLL\r\nand EXE encryptors as well as the program used for decryption. \r\nFigure 5: Builder.exe Resources \r\nDescription of each resource by its ID: \r\n100 – decryptor template file \r\n101 – executable template file \r\n103 – DLL template file \r\n106 – DLL template file that enables reflective loading\r\nThe configuration file, config.json, contains options commonly associated with ransomware including targeted\r\nfolders, files to avoid, and processes that should be killed. As shown in Figure 6, it also contains settings options\r\nto tune the behavior of the ransomware, those shown below were found by default in the builder.  \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 5 of 21\n\nFigure 6: Configuration Options \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 6 of 21\n\nThis builder configuration allows the resultant ransomware to be tuned for a specific target environment. In\r\naddition to these configurations there are options for  \r\nHosts, files, folders and file extension to exclude \r\nProcess and services to stop and remove \r\nList of command and control domains, URLs, or IPs \r\nList of usernames and passwords to try on affected systems\r\nSince this ransomware is highly configurable there are many different code paths possible. For the sake of\r\nsimplicity, the analysis here will focus on running the ransomware in the default case, without command line\r\nconfiguration options. However, to explain full functionality these options will be mentioned in relevant code\r\nsections. \r\nInside the LockBit Black Box \r\nThe initial set of code, decompiled for readability, within the program is shown in Figure 7. This code shows that\r\nthe executable contains a substantial amount of unused GUI related code listed after a call to exit the process,\r\nhighlighted as kernel32.ExitProcess(). All the ransom functionality occurs in the three functions that occur\r\nimmediately before the call to ExitProcess. The main function contains the largest part of the ransomware\r\nfunctionality. The implementation of unused code is not new to malware development, but it is also not very\r\ncommon. A technique like this helps obscure the true purpose of the malware from researchers, and can help make\r\nmalware seem legitimate. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 7 of 21\n\nFigure 7: Entry Function \r\nTypical applications call DLL functions directly, or perform simple calls to get the process address of functions\r\nfrom the DLL file. The LockBit builder has a different and more obscure method to discover and use external\r\nfunctions. The function we’ve named “prepare_address_table_lookups”, shown in Figure 7, contains a table of\r\nhashes pre-generated from a set of function calls. Each entry in this set includes the lowercase library and function\r\nnames separated by a dot (i.e. ntdll.findfirstfileexw). LockBit 3.0 manually finds the DLLs it needs in the\r\nWindows System32 folder, and then manually loads each function, laboriously hashing and matching each\r\nfunctions library and name combination to create the address table. Once the table of hashed libraries and\r\nfunctions is created, the malware is careful to release and clear all memory to inhibit analysis. It should be noted\r\nthat this is only a subset of the functions called, as more functions are retrieved and called from the Windows\r\nkernel during runtime. \r\nAs shown in Figure 7, the “check_priv_elevate_if_needed” function does what the name implies. Privilege\r\nescalation is achieved by duplicating access tokens to gain membership in privileged groups. To understand this it\r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 8 of 21\n\nis helpful to have a high-level understanding of Windows privileges. In life Windows privilege is roughly\r\nequivalent to a large ring of keys that provide access to otherwise restricted areas. In Windows these keys are\r\ncalled access tokens and each access token can contain one or more privilege constants. Each privilege constant\r\ndefines a specific action or set of actions that can be restricted in the operating system.  For example, one privilege\r\nconstant almost everyone has is called SeShutdownPrivilege, which allows a local user to shutdown the operating\r\nsystem. Without this privilege constant in the access token, Windows would not allow the shutdown. Just like in\r\nreal life where a physical key ring can hold numerous keys, numerous privilege constants can belong to single\r\naccess token.   \r\nEssential for understanding is that processes and services started by the user or on the user’s behalf are endowed\r\nwith or inherit their privileges from the user.  However, not all processes and services on a system belong to the\r\nuser, some belong to the operating system. These operating system processes and services will by necessity have\r\ndifferent privileges. Simply put, LockBit 3.0 duplicates an access token from a system process to use in a user\r\nprocess to allow functionality that would otherwise be prohibited. \r\nTo duplicate tokens LockBit 3.0 does several things. Initially it will check if it already has sufficient privilege by\r\nspecifically checking for membership in the Domain Admin group. If this is not found, it attempts to grant itself a\r\npredetermined list of fifteen privilege constants, most of which were not successful in testing when run as an\r\nunprivileged user. After this, if it still does not have the required privilege, LockBit 3.0 locates the operating\r\nsystem process explorer.exe and calls ZwOpenProcessToken directly to read the access token for explorer.exe.\r\nThen it calls NtDuplicateToken passing in the newly acquired token handle to request read and write access to the\r\nextended attributes of the copy. \r\nFigure 8: Duplicate the explorer.exe Process Token \r\nIn this case the Explorer process was targeted directly. However, as the program runs, each time certain processes\r\nare encountered the token privileges are checked and, if additional privileges are found, the token is duplicated.\r\nThere is a noted emphasis on gaining a token with privileged domain access. \r\nOne of the first things that the malware in the main function does is check for, and create, a synchronization\r\nmutex. If the mutex is present the process will exit, ensuring that only one instance of the ransomware runs at a\r\ntime. The mutex is made by first taking the MD5 hash of the supplied public key found in the pub.key file. The\r\nresulting MD5 hash is string formatted with “{%08X-%04X-%04X-%02X%02X-%02X%02X %02X %02X\r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 9 of 21\n\n%02X %02X}”.  Next, the MD4 hash of this formatted string is calculated, and the result is passed to the format\r\nstring “Global\\%.8x%.8x%.8x%.8x”. For example, a finished mutex value would be similar to\r\nGlobal\\ea4ee28880136cbc44dff4ad5a53561f. \r\nNext LockBit 3.0 checks that the operating system started normally. If Windows started in safe mode the\r\nransomware does not run most of its functionality, but instead sets a registry key to run on the next normal boot. \r\nWith the mutex in place and the boot type satisfied, the main purpose of the executable is started in a multi-threaded manner. Each thread takes on the characteristic of its tasking. Some run continuously for the life of the\r\nprocess, and others run once only temporarily to perform a specific task. \r\nStop Services: Windows Defender \r\nThe first thread removes Windows Security Services. This is achieved by taking advantage of the Trusted Installer\r\nservice. The Trusted Installer, usually known by its display name “Windows Modules Installer”, is normally used\r\nfor downloading and installing Windows updates and optional components. If the Trusted Installer is not already\r\nrunning it is started, and then its access token handle is duplicated to allow the current thread to have access to\r\nmost other running services. With this token LockBit 3.0 enumerates the running services and any service\r\nmatching one of those predefined in config.json is stopped and deleted. Once complete, the thread exits and does\r\nnot start again. \r\nFigure 9: Notification Windows Security Center stopped \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 10 of 21\n\nFigure 10: Error attempting to restart Windows Security Center \r\nDuring testing a small taskbar notification briefly appeared to inform the user that the Windows Security Center\r\nservice stopped. However, because the service was not only stopped but also deleted, the Windows notification\r\ncould not be used to restart the service. \r\nService  Description \r\nSecurityHealthService \r\nProvides current information about the protection status of the endpoint, includes\r\nmonitoring of Windows and other vendor’s tools \r\nwscsvc  Windows Security Center Service \r\nSense  Windows Defender Advanced Threat Protection Service \r\nsppsvc  Microsoft’s Software Protection Service – Licensing \r\nWdBoot  Windows Defender ELAM (Early Launch Antimalware) Driver \r\nWdFilter  Windows Defender Mini-Filter Driver \r\nWdNisDrv  Windows Defender Antivirus Network Inspection System Driver \r\nWdNisSvc  Windows Defender Network Inspection Service \r\nWinDefend  Windows Defender Service \r\nTable 1: Services Stopped and Deleted \r\nIt is important to consider that the Windows Security Service was targeted here because these services were listed\r\nin the default config.json file. It is highly likely that other services would be stopped if listed by threat actors using\r\nthis builder. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 11 of 21\n\nFigure 11: Services stopped and deleted \r\nOnce the services are removed the malware will launch several additional threads. The screenshot in Figure 12\r\nshows the threads with the longest runtime. The first priority is to launch the thread that handles files in the\r\nWindows Recycle Bin, followed by threads to monitor for and terminate the SQL process. Then there is a thread\r\ndedicated to writing ransom notes to directories. The last threads initiated are those to encrypt files. There are\r\nthree threads devoted to this in the screenshot below, but the number of threads is dynamic and will increase or\r\ndecrease depending on the available system resources, and the number and type of items queued for encryption. \r\nFor example, network resources identified for encryption are handled separately from those on the local system. \r\nFigure 12: Some of the LockBit 3.0 Threads \r\nRecycle Bin Thread \r\nAs shown above, there is a special thread dedicated to handling files found in the recycle bin. The files in the\r\nrecycle bin are not encrypted; instead, the content of each file is replaced with randomly generated bytes in\r\n0x10000 byte blocks, and then they are deleted. For this reason, all files in the recycle bin are not recoverable,\r\neven with the decryptor. \r\nMonitor and Terminate SQL Process \r\nA separate thread runs continuously, watching for and stopping any SQL process. It does this by getting a list of\r\nservices every two seconds.  Each service name is passed to the function isSQL(), which looks for any occurrence\r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 12 of 21\n\nof the case insensitive string SQL.  If the name contains this sequence, it is terminated. Unlike many of the other\r\nthreads, this thread runs for the life of the process ensuring that SQL will not run for more than two seconds while\r\nLockBit 3.0 performs ransom activity. \r\nFigure 13: Terminate SQL Service \r\nDelete Shadow Copies \r\nThere is a thread dedicated to the removal of Volume Shadow Copies. A shadow copy is a snapshot of a volume\r\nthat duplicates all the data that is held on the volume at one well-defined instant in time. This is completed by\r\nmaking a call to the IWbemProvider COM object and starting an in-process server to allow queries to the\r\nWindows Management Interface. Using this it executes the WMI query “SELECT * FROM\r\nWin32_ShadowCopy”, and then deletes each of the returned Shadow Copies. \r\nWrite Ransom Notes \r\nThe ransom note thread retrieves and decrypts the embedded ransom note that was defined in config.json. The\r\nnote is written to every directory not marked for exclusion. Its file name is made up of nine alphanumeric\r\ncharacters followed by “.README.txt” (ie xEC9do6g6.README.txt). The unique value prefixing the\r\n“.README.txt” is the base64 encoding of the first 6 bytes of the MD5 hash of the previously generated mutex\r\nGUID. Due to this method, all ransom notes left on the system are all given the same name but are unique to that\r\nsystem. \r\nEncryption \r\nFiles are encrypted using the Salsa-20 algorithm. During the encryption threads, memory containing the private\r\nkey is protected with heavy use of RtlEncryptMemory and RtlDecyptMemory, which makes the private key\r\navailable unencrypted in memory only for the time it is necessary. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 13 of 21\n\nDomain Controller Discovery \r\nAnother thread attempts to logon to the infected system with the usernames and passwords found in the\r\nconfiguration. The usernames and passwords found in the config.json file by default are those associated with\r\nadministration accounts. If any login is successful, the token membership is evaluated for membership in a\r\ndomain admin group and if so, copied. Then another thread looks for and enumerates available domain\r\ncontrollers, getting each of their names, and attempting a remote login with the successful username and\r\npassword. \r\nConnected Drives and Shared Network Resources \r\nOther threads check for connected drives and network resources while giving special attention to those where\r\noperating systems are installed. In all cases these newly discovered paths are passed to a function that spawns\r\nadditional encryption threads. \r\nNetwork Traffic \r\nCommand and control traffic occurs over TLS 1.2 to the addresses listed in the config.json file. Unfortunately, the\r\nvariables and their values are AES encrypted under this TLS layer, and the order is shuffled for each request.\r\nHowever, the overall format of the POST request is consistent as shown in Figure 14. Consistently observed was a\r\nPOST request followed by “/?” and a long string of URL style variable=value pairs separated with an ampersand,\r\nfollowed by the HTTP/1.1 fields.  The User-Agent string is randomized, so should not be included in signatures,\r\nbut the Connection, Accept-Encoding, Content-Type and Cache-Control, fields are constant.  The basic format of\r\nthe data section was also consistent, but the length varied slightly.   \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 14 of 21\n\nFigure 14: Initial POST Request \r\nAlthough decrypting the intercepted network traffic would be close to impossible without the encryption key, the\r\nbelow example provides a general understanding of the information transmitted. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 15 of 21\n\nFigure 15: JSON Formatted Exfil Data \r\nPost Encryption \r\nPost encryption, the desktop background is changed to black with white text similar to the example in Figure 14. \r\nAdditionally, the icons of encrypted files are changed to the LockBit “B” icon shown in the upper left corner of\r\nFigure 16. \r\nFigure 16: Ransom Desktop and LockBit Icon \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 16 of 21\n\nDecryptor \r\nAs the decryptor was generated with the builder, we tested its operation and use. When run, a window displays as\r\nshown below, and the user must click the large button on the right that is labeled, “Decrypt All Encrypted Files”. \r\nOnce clicked the counter for All Decrypted Files ticks up as files are decrypted. As shown here, the application\r\nnever closed, but by CPU usage had ceased processing files, signaling that it had completed.  \r\nThere was a difference of 64 files at the end of processing. To account for these 64 files, the file system was\r\nscanned for any LockBit named files, but no matching files were found. The Recycle Bin files could account for\r\nsome of the 64, but the 10 files removed from the recycle bin still left us many short of 64. These missing files\r\naside, the Recycle Bin was not restored, and all the volume shadow copies were still erased. For all general files\r\nthe decryptor did work, files were appropriately restored, and the Lockbit desktop background was removed. No\r\nconclusive tests were run to verify the number of encrypted or decrypted files with the number reported by this\r\ntool. \r\n \r\nFigure 17: LockBit 3.0 Decryptor \r\nMITRE ATT\u0026CK TIDs \r\nTactic  ID  Name  Description \r\nExecution\r\nTA0002 \r\nT1559.001 \r\nComponent Object\r\nModel \r\nUsed for deleting volume shadow copies \r\nT1106  Native API  Copious use of Windows Native API calls \r\nT1047  WMI  Used for deleting volume shadow copies \r\nPersistence\r\nTA0003 \r\nT1547.001  Registry Run Keys \r\nIf started in safe mode, sets registry to start\r\non next normal boot. \r\nPrivilege\r\nEscalation \r\nT1134.001  Token Impersonation  Starts processes with known token with the\r\npurpose of duplicating tokens. \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 17 of 21\n\nTA0004 \r\nDefense Evasion\r\nTA0005 \r\nT1562.001  Disable or Modify Tool \r\nStops and deletes Windows Security\r\nServices \r\nT1562.002 \r\nDisable Windows Event\r\nLogging \r\nStops and deletes service responsible for\r\nevent logging \r\nT1562.004  Disable system firewall \r\nStops and deletes service for Windows\r\nFirewall. \r\nT1562.009  Safe Mode Boot  Changes behavior if booted in safe mode. \r\nT1078.001  Default Accounts \r\nAttempts to login with default admin\r\ncredentials \r\nDiscovery\r\nTA0007 \r\nT1083 \r\nFile and Directory\r\nDiscovery \r\nTraverses mounted disks and file system \r\nT1135 \r\nNetwork Share\r\nDiscovery \r\nTraverses all shared network resources \r\nT1120 \r\nPeripheral Device\r\nDiscovery \r\nLocates removable storage devices  \r\nT1057  Process Discovery  Looks for specific processes to stop \r\nT1018 \r\nRemote System\r\nDiscovery \r\nLocates domain controller and DNS server \r\nT1082 \r\nSystem Information\r\nDiscovery \r\nGets specific information about the\r\noperating system \r\nLateral\r\nMovement \r\nTA0008 \r\nT1021.002 \r\nWindows Admin\r\nShares \r\nUser of valid accounts to interact with\r\nremote network shares \r\nCommand and\r\nControl \r\nTA0011 \r\nT1071.001  Web Protocols  Uses HTTP to communicate with C2 \r\nT1573  Encrypted channel  TLS 1.2 \r\nExfiltration \r\nTA0010 \r\nT1041 \r\nExfiltration Over C2\r\nChannel \r\nSends basic system information in POST\r\nrequest  \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 18 of 21\n\nImpact\r\nTA0040 \r\nT1485  Data Destruction  Recycle bin and shadow copies are deleted \r\nT1486 \r\nData Encrypted for\r\nImpact \r\nRansomware \r\nT1491.001  Internal Defacement  Desktop changed \r\nIndicators of Compromise (IOCs)\r\nIOC  Description \r\nc2bc344f6dde0573ea9acdfb6698bf4c  MD5 Builder File \r\nd6ae7dc2462c8c35c4a074b0a62f07cfef873c77  SHA1 Builder File \r\na736269f5f3a9f2e11dd776e352e1801bc28bb699e47876784b8ef761e0062db  SHA256 Builder File \r\n71c3b2f765b04d0b7ea0328f6ce0c4e2  MD5 keygen File \r\nbf8ecb6519f16a4838ceb0a49097bcc3ef30f3c4  SHA1 keygen file \r\nea6d4dedd8c85e4a6bb60408a0dc1d56def1f4ad4f069c730dc5431b1c23da37  SHA256 keygen file \r\n4d388f95a81f810195f6a8dfe86be755  MD5 Resource 100 \r\ncb6fdb25a15b7797890fadc2b823984f93da5368  SHA1 Resource 100 \r\ncc3d006c2b963b6b34a90886f758b7b1c3575f263977a72f7c0d1922b7feab92  SHA256 Resource 100 \r\n87308ec0a44e79100db9dbec588260ec  MD5 Resource 101 \r\n939ff7e5eeaccb0c2f4ee080a8e403e532b6317a  SHA1 Resource 101 \r\n03b8472df4beb797f7674c5bc30c5ab74e8e889729d644eb3e6841b0f488ea95  SHA256 Resource 101 \r\n4655a7ac60ed48df9b57648db2f567ef  MD5 Resource 103 \r\n02ea524429ba2aefac63fed27e924ab3659f8c00  SHA1 Resource 103 \r\na0db5cff42d0ee0de4d31cff5656ed1acaa6b0afab07d19f9f296d2f72595a56  SHA256 Resource 103 \r\n23a30838502f5fadc97e81f5000c4190  MD5 Resource 106 \r\n9c1142122370c9b28b13aa147c6e126b3be50845  SHA1 Resource 106 \r\nae993930cb5d97caa5a95b714bb04ac817bcacbbf8f7655ec43e8d54074e0bd7  SHA256 Resource 106 \r\nYara Rules \r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 19 of 21\n\nimport \"pe\"\r\nrule LockBit_3_dll\r\n{\r\n meta:\r\n author = \"VMware TAU\" //bdana\r\n date = \"2022-Oct-12\"\r\n description = \"Identifies LockBit 3.0 DLL encryptor by exported function names.\"\r\n rule_version = “1”\r\n yara_version = \"4.2.3\"\r\n exemplar_hash = “c2529655c36f1274b6aaa72911c0f4db7f46ef3a71f4b676c4500e180595cac6”\r\n condition:\r\n pe.exports(\"del\") and\r\n pe.exports(\"gdel\") and\r\n pe.exports(\"gdll\") and\r\n pe.exports(\"gmod\") and\r\n pe.exports(\"pmod\") and\r\n pe.exports(\"sdll\") and\r\n pe.exports(\"wdll\")\r\n}\r\nrule LockBit_3_exe\r\n{\r\n meta:\r\n author = \"VMware TAU\" //bdana\r\n date = \"2022-Oct-12\"\r\n description = \"Identifies LockBit 3.0 exe encryptor section names, and artifact section names\r\n rule_version = “1”\r\n yara_version = \"4.2.3\"\r\n exemplar_hash = “5202e3fb98daa835cb807cc8ed44c356f5212649e6e1019c5481358f32b9a8a7”\r\n strings:\r\n $text = \".text\" ascii wide\r\n $itext = \".itext\" ascii wide\r\n $data = \".data\" ascii wide\r\n $rdata = \".rdata\" ascii wide\r\n $idata = \".idata\" ascii wide\r\n $xyz = \".xyz\" ascii wide\r\n $reloc = \".reloc\" ascii wide\r\n $bss = \".bss\" ascii wide\r\n condition:\r\n #text \u003e 2 and\r\n #itext \u003e 1 and\r\n #data \u003e 1 and\r\n #rdata \u003e 2 and\r\n #idata \u003e 3 and\r\n $reloc and\r\n $bss and $xyz and not\r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 20 of 21\n\nfor any i in (0..pe.number_of_sections-1) : (\r\npe.sections[i].name == \".xyz\" or\r\n pe.sections[i].name == \".bss\"\r\n )\r\n}\r\nSource: https://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nhttps://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html\r\nPage 21 of 21",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blogs.vmware.com/security/2022/10/lockbit-3-0-also-known-as-lockbit-black.html"
	],
	"report_names": [
		"lockbit-3-0-also-known-as-lockbit-black.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434101,
	"ts_updated_at": 1775826692,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f5260d45e5d37dd10c104ce214ce54bb4c05c0d7.pdf",
		"text": "https://archive.orkl.eu/f5260d45e5d37dd10c104ce214ce54bb4c05c0d7.txt",
		"img": "https://archive.orkl.eu/f5260d45e5d37dd10c104ce214ce54bb4c05c0d7.jpg"
	}
}