{ "id": "bb55060b-fe93-478c-9436-360d802d8c1c", "created_at": "2026-04-06T00:19:45.571586Z", "updated_at": "2026-04-10T03:33:30.394948Z", "deleted_at": null, "sha1_hash": "8d7f997f73053d297b0037bf1abd5118b63b434d", "title": "Latrodectus Rapid Evolution Continues With Latest New Payload Features", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 892643, "plain_text": "Latrodectus Rapid Evolution Continues With Latest New Payload\r\nFeatures\r\nBy Leandro Fróes\r\nPublished: 2024-08-29 · Archived: 2026-04-05 15:03:36 UTC\r\nSummary\r\nLatrodectus is a downloader first discovered by Walmart back in October of 2023. The malware became very\r\nfamous due to its similarities with the famous IcedID malware, not only in the code itself but also the\r\ninfrastructure, as previously reported by Proofpoint and Team Cymru S2. \r\nThe malware is usually delivered via email spam campaigns conducted by two specific threat actors: TA577 and\r\nTA578. Among the several features it contains is the ability to download and execute additional payloads, collect\r\nand send system information to the C2, terminate processes, and more. In July of 2024 Latrodectus was also\r\nobserved being delivered by a BRC4 badger.\r\nDuring the Threat Labs hunting activities we discovered a new version of the Latrodectus payload, version 1.4.\r\nThe malware updates include a different string deobfuscation approach, a new C2 endpoint, two new backdoor\r\ncommands, and more.\r\nIn this blog, we will focus on the features added/updated in this new version.\r\nJavaScript file analysis\r\nThe first payload of the infection chain is a JavaScript file obfuscated using a similar approach used by other\r\nLatrodectus campaigns. The obfuscation technique is employed by adding several comments into the file, making\r\nit more difficult to be analyzed as well as increasing the file size considerably.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 1 of 21\n\nThe relevant code is present in between the junk comments and once removed from the file we can see the code\r\nthat would be executed.\r\nThe malware searches for lines starting with the “/////” string, puts them into a buffer and executes them as a JS\r\nfunction. The executed function then downloads an MSI file from a remote server and executes/installs it.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 2 of 21\n\nMSI file analysis\r\nOnce executed/installed, the MSI file uses the rundll32.exe Windows tool to load a DLL named “nvidia.dll” and\r\ncalls a function named “AnselEnableCheck” exported by this DLL. The malicious DLL is stored inside a CAB file\r\nnamed “disk1”, present in the MSI file itself:\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 3 of 21\n\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 4 of 21\n\nCrypter analysis\r\nAs an attempt to obfuscate the main payload, the “nvidia.dll” file uses a crypter named Dave. This crypter has\r\nbeen around for a long time and was used in the past by other malware such as Emotet, BlackBasta, and previous\r\nversions of Latrodectus.\r\nThe crypter stores the payload to be executed either in a resource or in a section. In the analyzed sample, the\r\npayload is stored in a section named “V+N”.\r\nThe steps used to deobfuscate, load, and execute the final payload are rather simple. The malware moves a key\r\ninto the stack and resolves the Windows API functions VirtualAlloc, LoadLibrary, and GetProcAddress.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 5 of 21\n\nIt then allocates memory using the VirtualAlloc function and performs a multi-byte XOR operation against the\r\ndata in the mentioned section using the previously set key and the result of the operation is the final payload. The\r\nnext steps involve aligning the payload in memory and calling its main function.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 6 of 21\n\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 7 of 21\n\nSince the crypter first copies the original payload to the allocated memory before the other steps are performed,\r\none could simply dump the content of the first allocated memory and obtain the final payload. A script to statically\r\nunpack/deobfuscate Latrodectus payloads using Dave crypter can be found here.\r\nThe final payload is a DLL and its DllMain function is called by the crypter code. The next step is the execution of\r\nthe “AnselEnableCheck” exported function, which is responsible for the execution of the final payload. \r\nWhen looking at the final payload we notice it has multiple exported functions, though since all of them have the\r\nsame RVA it doesn’t matter which one is called.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 8 of 21\n\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 9 of 21\n\nLatrodectus DLL analysis\r\nSince the general features of the main payload were already described in the past by other researchers, the\r\nfollowing sections will focus on the updates employed by the new Latrodectus version.\r\nString obfuscation\r\nUnlike the previous versions that used an XOR operation to deobfuscate its strings, the updated version uses\r\nAES256 in CTR mode. The AES key is hardcoded in the deobfuscation function itself and the IV changes for each\r\nstring to be decrypted. The key used in the analyzed samples is\r\n“d623b8ef6226cec3e24c55127de873e7839c776bb1a93b57b25fdbea0db68ea2”.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 10 of 21\n\nThe deobfuscation function receives two parameters. The first one is a chunk of data and the second an output\r\nbuffer. The chunk of data is used to store information used to decrypt the string and follows the format below:\r\nString length: 2 bytes\r\nIV: 16 bytes\r\nEncrypted string: Size specified in the first field\r\nOne thing to notice is that sometimes there will be extra bytes after the encrypted string content. The following\r\nimage is an example of this data chunk:\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 11 of 21\n\nCampaign ID\r\nIn the current malware version, the campaign ID generation function continues to use the same approach where an\r\ninput string is hashed using the FNV algorithm. However, a new input string “Wiski” was used, resulting in the\r\nhash 0x24e7ce9e as the campaign ID.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 12 of 21\n\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 13 of 21\n\nC2 communication\r\nFor its initial communication with the C2 server, Latrodectus collects a lot of information from the infected\r\nsystem such as the username, OS version and the MAC address. The information is formatted using a specific\r\npattern, encrypted using the RC4 algorithm, encoded using base64 and sent to the C2.\r\nThe RC4 keys found in the analyzed samples were\r\n“2sDbsEUXvhgLOO4Irt8AF6el3jJ0M1MowXyao00Nn6ZUjtjXwb” and\r\n“kcyBA7IbADOhw5ztcv09vmF8GYmR38eu7OGdfD7pyRelTPKH1G”. \r\nDuring the data formatting we are able to flag the version number 1.4 being set.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 14 of 21\n\nThe information is sent in the HTTP body via an HTTP POST request. The endpoint used in the new variants is\r\n“/test” instead of “/live” as observed in previous versions. Although a very weak indicator the usage of this\r\nspecific endpoint might indicate that this is a test version of the malware.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 15 of 21\n\nCommands\r\nIn version 1.4 Latrodectus has introduced two new commands to its payload: command ID 22 and 25.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 16 of 21\n\nCommand 0x16\r\nIn this command the malware downloads a shellcode from the specified server and executes it via a new thread.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 17 of 21\n\nThe difference between this command and command 14 is that a function that performs base64 encoding is passed\r\nas a parameter to the shellcode itself. The address of the base64 function is stored in a mapped file view named\r\n“12345”.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 18 of 21\n\nCommand 0x19\r\nIn this command, the malware receives a file name and a remote location to download the file from. The file name\r\nis then appended to %AppData%, the file is downloaded and its content written to the mentioned path.\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 19 of 21\n\nConsidering these additions, below is a table of the updated commands supported by the malware:\r\nCommand ID Description\r\n2 Collect a list of desktop file names\r\n3 Collect info about the running processes\r\n4 Collect system information\r\n12 Download and execute a regular executable\r\n13 Download and execute a DLL via rundll32\r\n14 Download and execute a shellcode\r\n15 Self update\r\n17 Terminate itself\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 20 of 21\n\nCommand ID Description\r\n18 Download and execute the IcedID payload\r\n19 Increase sleep timeout\r\n20 Reset request counter\r\n21 Download and execute the stealer module\r\n22 Download and execute a shellcode passing the base64 encoding function as a parameter\r\n25 Download a file to %AppData% directory\r\nNetskope Detection\r\nNetskope Threat Protection\r\nGen:Variant.Ulise.493872\r\nTrojan.Generic.36724146\r\nNetskope Advanced Threat Protection provides proactive coverage against this threat.\r\nWin64.Trojan.ShellCoExec\r\nConclusions\r\nLatrodectus has been evolving pretty fast, adding new features to its payload. The understanding of the updates\r\napplied to its payload allow defenders to keep automated pipelines properly set as well as use the information for\r\nfurther hunting for new variants. Netskope Threat Labs will continue to track how the Latrodectus evolves and its\r\nTTP.\r\nIOCs\r\nAll the IOCs and scripts related to this malware can be found in our GitHub repository.\r\nSource: https://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nhttps://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features\r\nPage 21 of 21\n\n https://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features \nThe difference between this command and command 14 is that a function that performs base64 encoding is passed\nas a parameter to the shellcode itself. The address of the base64 function is stored in a mapped file view named\n“12345”. \n Page 18 of 21", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.netskope.com/blog/latrodectus-rapid-evolution-continues-with-latest-new-payload-features" ], "report_names": [ "latrodectus-rapid-evolution-continues-with-latest-new-payload-features" ], "threat_actors": [ { "id": "62585174-b1f8-47b1-9165-19b594160b01", "created_at": "2023-01-06T13:46:39.369991Z", "updated_at": "2026-04-10T02:00:03.304964Z", "deleted_at": null, "main_name": "TA578", "aliases": [], "source_name": "MISPGALAXY:TA578", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "52eb5fb6-706b-49c0-9ba5-43bea03940d0", "created_at": "2024-11-01T02:00:52.694476Z", "updated_at": "2026-04-10T02:00:05.410572Z", "deleted_at": null, "main_name": "TA578", "aliases": [ "TA578" ], "source_name": "MITRE:TA578", "tools": [ "Latrodectus", "IcedID" ], "source_id": "MITRE", "reports": null }, { "id": "b4f83fef-38ee-4228-9d27-dde8afece1cb", "created_at": "2023-02-15T02:01:49.569611Z", "updated_at": "2026-04-10T02:00:03.351659Z", "deleted_at": null, "main_name": "TA577", "aliases": [ "Hive0118" ], "source_name": "MISPGALAXY:TA577", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "22d450bb-fc7a-42af-9430-08887f0abf9f", "created_at": "2024-11-01T02:00:52.560354Z", "updated_at": "2026-04-10T02:00:05.276856Z", "deleted_at": null, "main_name": "TA577", "aliases": [ "TA577" ], "source_name": "MITRE:TA577", "tools": [ "Pikabot", "QakBot", "Latrodectus" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434785, "ts_updated_at": 1775792010, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8d7f997f73053d297b0037bf1abd5118b63b434d.pdf", "text": "https://archive.orkl.eu/8d7f997f73053d297b0037bf1abd5118b63b434d.txt", "img": "https://archive.orkl.eu/8d7f997f73053d297b0037bf1abd5118b63b434d.jpg" } }