Back 
Summary
Latrodectus is a downloader first discovered by Walmart back in October of 2023. The malware became very famous due to its similarities with the famous IcedID malware, not only in the code itself but also the infrastructure, as previously reported by Proofpoint and Team Cymru S2.
The malware is usually delivered via email spam campaigns conducted by two specific threat actors: TA577 and TA578. Among the several features it contains is the ability to download and execute additional payloads, collect and send system information to the C2, terminate processes, and more. In July of 2024 Latrodectus was also observed being delivered by a BRC4 badger.
During the Threat Labs hunting activities we discovered a new version of the Latrodectus payload, version 1.4. The malware updates include a different string deobfuscation approach, a new C2 endpoint, two new backdoor commands, and more.
In this blog, we will focus on the features added/updated in this new version.
JavaScript file analysis
The first payload of the infection chain is a JavaScript file obfuscated using a similar approach used by other Latrodectus campaigns. The obfuscation technique is employed by adding several comments into the file, making it more difficult to be analyzed as well as increasing the file size considerably.
The relevant code is present in between the junk comments and once removed from the file we can see the code that would be executed.
The malware searches for lines starting with the “/////” string, puts them into a buffer and executes them as a JS function. The executed function then downloads an MSI file from a remote server and executes/installs it.
MSI file analysis
Once executed/installed, the MSI file uses the rundll32.exe Windows tool to load a DLL named “nvidia.dll” and calls a function named “AnselEnableCheck” exported by this DLL. The malicious DLL is stored inside a CAB file named “disk1”, present in the MSI file itself:
Crypter analysis
As an attempt to obfuscate the main payload, the “nvidia.dll” file uses a crypter named Dave. This crypter has been around for a long time and was used in the past by other malware such as Emotet, BlackBasta, and previous versions of Latrodectus.
The crypter stores the payload to be executed either in a resource or in a section. In the analyzed sample, the payload is stored in a section named “V+N”.
The steps used to deobfuscate, load, and execute the final payload are rather simple. The malware moves a key into the stack and resolves the Windows API functions VirtualAlloc, LoadLibrary, and GetProcAddress.
It then allocates memory using the VirtualAlloc function and performs a multi-byte XOR operation against the data in the mentioned section using the previously set key and the result of the operation is the final payload. The next steps involve aligning the payload in memory and calling its main function.
Since the crypter first copies the original payload to the allocated memory before the other steps are performed, one could simply dump the content of the first allocated memory and obtain the final payload. A script to statically unpack/deobfuscate Latrodectus payloads using Dave crypter can be found here.
The final payload is a DLL and its DllMain function is called by the crypter code. The next step is the execution of the “AnselEnableCheck” exported function, which is responsible for the execution of the final payload.
When looking at the final payload we notice it has multiple exported functions, though since all of them have the same RVA it doesn’t matter which one is called.
Latrodectus DLL analysis
Since the general features of the main payload were already described in the past by other researchers, the following sections will focus on the updates employed by the new Latrodectus version.
String obfuscation
Unlike the previous versions that used an XOR operation to deobfuscate its strings, the updated version uses AES256 in CTR mode. The AES key is hardcoded in the deobfuscation function itself and the IV changes for each string to be decrypted. The key used in the analyzed samples is “d623b8ef6226cec3e24c55127de873e7839c776bb1a93b57b25fdbea0db68ea2”.
The deobfuscation function receives two parameters. The first one is a chunk of data and the second an output buffer. The chunk of data is used to store information used to decrypt the string and follows the format below:
- String length: 2 bytes
- IV: 16 bytes
- Encrypted string: Size specified in the first field
One thing to notice is that sometimes there will be extra bytes after the encrypted string content. The following image is an example of this data chunk:
Campaign ID
In the current malware version, the campaign ID generation function continues to use the same approach where an input string is hashed using the FNV algorithm. However, a new input string “Wiski” was used, resulting in the hash 0x24e7ce9e as the campaign ID.