{ "id": "efc32f00-ee02-46a4-8f05-b2f83896da19", "created_at": "2026-04-06T00:16:04.528647Z", "updated_at": "2026-04-10T03:37:23.876661Z", "deleted_at": null, "sha1_hash": "6bc1fa48cfea51ddbdbbc39ce99bda61cb09306c", "title": "Let’s set ice on fire: Hunting and detecting IcedID infections", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 54630, "plain_text": "Let’s set ice on fire: Hunting and detecting IcedID infections\r\nBy Deutsche Telekom AG\r\nPublished: 2021-05-17 · Archived: 2026-04-05 13:16:25 UTC\r\nWith the fall of the infamous Emotet botnet earlier this year, there are several cybercrime gangs competing to fill\r\nout the void that it left behind. One of these malware families that positions itself as a replacement is IcedID.\r\nLearn how to hunt for IcedID samples and detect local infections.\r\nIcedID - also known as BokBot - emerged in late 2017. First, it served as a banking Trojan, which was common\r\nfor this time. However, banking Trojans already faced several difficulties like two-factor authentication (2FA)\r\nintroduced by many banks. Consequently, the IcedID developers transformed it into a downloader and it became\r\npart of the Malware-as-a-Service ecosystem (MaaS).\r\nAs of 2021, more and more ransomware operators use the service provided by IcedID’s operators. Telekom\r\nSecurity as well as others observed ransomware deployment after IcedID infections. This is in line with the\r\ngeneral trend towards human-operated ransomware operations.\r\nIn this blog post, I will present ways how to hunt for IcedID samples and detect local IcedID infections. This\r\nallows on one side blue teamers to proactively find latent infections that could turn into ransomware deployment\r\nand on the other side incident responders to quickly find a patient zero during an investigation. In addition to this\r\nblog post, I recommend to read this technical analysis of IcedID core and a recent technical analysis of the initial\r\nIcedID GZIP loader. All scripts, YARA signatures and, additional IoCs mentioned in this blog post can be found in\r\nour Github repository.\r\nOur Incident Response Service at Deutsche Telekom Security GmbH can quickly investigate and remediate\r\nongoing IcedID-related intrusions. Please contact security-info@t-systems.com for more information.\r\nIcedID infection chain overview\r\nIcedID infection chain is quite complex when compared to other common malware families. The initial infection\r\nvector is email. Over the last months, several threat actors delivered spam that led to IcedID infections. This\r\nincludes the Qakbot affiliate “TR” and TA551 / Shatak. Attachment types are as of now malicious Word / Excel\r\ndocuments or zipped JavaScript files.\r\nFigure 1 Example maldoc delivering IcedID requesting the user to activate macros\r\nIn the case of a malicious document, the infection chain goes on as follows. After the user has enabled the macro\r\nin the maldoc, the initial IcedID GZIP loader is fetched. This is a binary code component deployed as DLL. It is\r\nrun using a command line similar to “rundll32.exe DLL_FILENAME,DllRegisterServer”. This DLL with internal\r\nname “loader_dll_64.dll” conducts an initial reconnaissance and fingerprints the target system. It sends this data to\r\nits command and control server (CC) and the CC may respond with a fake GZIP payload.\r\nhttps://www.telekom.com/en/blog/group/article/let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240\r\nPage 1 of 4\n\nThe GZIP loader decrypts this payload, which contains information on how to run the payload (e.g. command line\r\nto execute), another loader with internal name “sadl_64.dll”, and another encrypted payload currently with\r\nfilename “license.dat”, which is the IcedID core module with internal name “fixed_loader64.dll”. The DLL with\r\ninternal name “sadl_64.dll” is run with, for instance, with rundll32 using a similar command line to “rundll32.exe\r\nDLL_FILENAME,update /i:\"FOLDER_NAME\\license.dat\"”, where in our case DLL_FILENAME was\r\n“Haimaw2.dll” and FOLDER_NAME was “GlacePlay”.\r\nIt decrypts the encrypted IcedID core module license.dat, loads it, and executes it. Noteworthy is that the core\r\n“fixed_loader64.dll” does not comprise configuration parameters like domain names of CC servers. This\r\ninformation is stored in the core loader “sadl_64.dll” and loaded by the core “fixed_loader64.dll” upon execution.\r\nFigure 2 Decrypted configuration from \"sadl_64.dll\" decrypted by IcedID core\r\nHunting for IcedID samples\r\nProactively tracking adversaries helps us to follow their recent changes of their tooling and to improve their\r\ndetection. As I’ve described in the last section, there are several stages involved in IcedID’s complex infection\r\nchain. Hence, there are several (binary) tools that are worth to hunt for.\r\nEven though the developers of IcedID chose to encrypt strings (as described here), there are still many plain text\r\nstrings allowing high confidence detection. This includes the internal project names.\r\nFigure 3 Plain text string of the internal project name \"sadl_64.dll\"\r\nIn our Github repository, you can find several YARA rules to detect all binary code stages of IcedID:\r\nIcedID GZIP loader (“loader_dll_64.dll”)\r\nIcedID core module loader (“sadl_64.dll”)\r\nIcedID core module (“fixed_loader64.dll”)\r\nNote that the string encryption was slightly changed in recent versions. The following screenshot shows the\r\ndecompiled string decryption function. An encrypted string is prepended with its size, conceptually similar to\r\nPascal-type strings. However, the first two WORDs have to be XORed in order to get the string size.\r\nSubsequently, the string is decrypted character after character in a for loop. In each round of the loop, first, a new\r\nkey is generated based on a custom random function using x64 assembly ROR and ROL operations. Next, the\r\ncharacter is XORed with the round’s new key.\r\nFigure 4 Decompiled string decryption function\r\nDetecting IcedID infections\r\nApart from using YARA rules to perform, for instance, memory scans, another way to detect IcedID infections\r\nreliably is searching for the registry keys it creates. The names of these registry keys are account-specific since\r\nthey are derived from the bot ID, which is derived from the current user’s SID.\r\nhttps://www.telekom.com/en/blog/group/article/let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240\r\nPage 2 of 4\n\nI implemented the bot ID computation and the derivation of the registry keys names in Python. They are also\r\nprovided in our Github repository.\r\nComputing the Bot ID\r\nOne of the first things that IcedID’s core module does is computing a bot ID. This bot ID is used heavily across\r\nthe code base, e.g. it is also send to the CC server as a way to identify bots and as we later will see to derive\r\naccount-specific registry key names.\r\nIn a nutshell, the function “compute_bot_id” (see next screenshot) derives the bot ID from the currently logged-in\r\naccount’s SID (security identifier, e.g. “S-1-5-21-1984500107-304187221-49949575”). If the bot is not able to\r\nacquire this SID, it defaults to the MachineGuid. In the following, I assume that the bot can acquire the account’s\r\nSID. It hashes the SID string using the FNV hash (as described here). The resulting hash value is XORed with a\r\nconstant. The function returns a DWORD value.\r\nLater, this DWORD value is negated using the x64 assembly instruction “not”. For instance, the SID “S-1-5-21-\r\n1984500107-304187221-49949575” yields the bot ID 0x9c80033f and the negated bot ID 0x637ffcc0. Curiously,\r\nboth bot IDs are used across the code base. However, the negated bot ID has the lion’s share of the usages.\r\nFigure 5 Decompiled function for computing the bot ID\r\nDeriving Machine-Specific Registry Key Names\r\nIcedID’s core stores configuration information (e.g. domain names) in account-specific registry keys. All of them\r\nare subkeys of “Software\\\\Classes\\\\CLSID\\\\”. The registry key names are derived from hard-coded GUIDs and the\r\naccount-specific bot ID. Hence, they are also account-specific.\r\nOnce we know how to derive the registry keys, we can reliably detect IcedID infections for an account. Blue\r\nteamers can use this knowledge to proactively scan for infections and incident responders to find a patient zero\r\nduring an IcedID-related investigation.\r\nRecent samples derived their registry key names from the following hard-coded GUIDs:\r\n{0ccac395-7d1d-4641-913a-7558812ddea2}\r\n{d65f4087-1de4-4175-bbc8-f27a1d070723}\r\n{e3f38493-f850-4c6e-a48e-1b5c1f4dd35f}\r\nTo derive a registry key name from one of the hard-coded GUIDs, IcedID computes a simple hash of the GUID.\r\nEach character is rotated to the right by 13/0xD. This results in a DWORD value. This is then XORed with the\r\nnegated bot ID. Next, it hashes the hardcoded GUID as well as the above DWORD value using the MD5 hash\r\nsum. This results in a value of 16 bytes. Finally, it formats these 16 bytes as a GUID.\r\nFor instance, for the above SID and bot IDs, we can derive the registry key name “{404FE54D-A5F1-3480-D7E1-\r\n2463C1FC62FD}” from the input “{0ccac395-7d1d-4641-913a-7558812ddea2}“.\r\nFigure 6 Decompiled function of registry key derivation\r\nhttps://www.telekom.com/en/blog/group/article/let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240\r\nPage 3 of 4\n\nConclusion\r\nIcedID is one of the uptrending malware families that tries to fill the void that Emotet left behind. Initially a\r\nbanking Trojan, it soon became a downloader. Recently, more and more ransomware deployments are associated\r\nwith initial IcedID infections. It’s rather complex infection chain increases analysis difficulty and ensures that an\r\neasy IoC extraction with off-the-shelf sandbox systems is not possible.\r\nIn this blog post, I’ve given a quick overview of IcedID current infection chain, focusing on the binary payloads\r\nand showed how to detect IcedID infections based on its use of the registry. In a nutshell, each bot computes a bot\r\nID based on the current user’s SID. This is utilized to as a seed to derive a handful of account-specific registry key\r\nnames, where it stores configuration parameters like CC domains. The blog post’s companion YARA rules, Python\r\nscripts, and additional IoCs can be found in our repository on Github. \r\nAppendix: IoCs\r\nIoC Description\r\nfc148647bf11e143f44e89ba3b229aca GZIP loader dump\r\nacc57b939ac8bb9bd4bf18f76e779977 GZIP loader\r\n92fdfe61cf977a7e5bed5ceeabdf895f Core loader dump\r\n11965662e146d97d3fa3288e119aefb2 IcedID core unpacked\r\nameripermanentno[.]website IcedID core CC server\r\nodichaly[.]space IcedID core CC server\r\nFurther information:\r\nIcedID (Malware Family) – Malpedia\r\nTechnical Analysis of IcedID\r\nSource: https://www.telekom.com/en/blog/group/article/let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240\r\nhttps://www.telekom.com/en/blog/group/article/let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.telekom.com/en/blog/group/article/let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240" ], "report_names": [ "let-s-set-ice-on-fire-hunting-and-detecting-icedid-infections-627240" ], "threat_actors": [ { "id": "26a04131-2b8c-4e5d-8f38-5c58b86f5e7f", "created_at": "2022-10-25T15:50:23.579601Z", "updated_at": "2026-04-10T02:00:05.360509Z", "deleted_at": null, "main_name": "TA551", "aliases": [ "TA551", "GOLD CABIN", "Shathak" ], "source_name": "MITRE:TA551", "tools": [ "QakBot", "IcedID", "Valak", "Ursnif" ], "source_id": "MITRE", "reports": null }, { "id": "40b623c7-b621-48db-b55b-dd4f6746fbc6", "created_at": "2024-06-19T02:03:08.017681Z", "updated_at": "2026-04-10T02:00:03.665818Z", "deleted_at": null, "main_name": "GOLD CABIN", "aliases": [ "Shathak", "TA551 " ], "source_name": "Secureworks:GOLD CABIN", "tools": [], "source_id": "Secureworks", "reports": null }, { "id": "90f216f2-4897-46fc-bb76-3acae9d112ca", "created_at": "2023-01-06T13:46:39.248936Z", "updated_at": "2026-04-10T02:00:03.260122Z", "deleted_at": null, "main_name": "GOLD CABIN", "aliases": [ "Shakthak", "TA551", "ATK236", "G0127", "Monster Libra" ], "source_name": "MISPGALAXY:GOLD CABIN", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "04e34cab-3ee4-4f06-a6f6-5cdd7eccfd68", "created_at": "2022-10-25T16:07:24.578896Z", "updated_at": "2026-04-10T02:00:05.039955Z", "deleted_at": null, "main_name": "TA551", "aliases": [ "G0127", "Gold Cabin", "Monster Libra", "Shathak", "TA551" ], "source_name": "ETDA:TA551", "tools": [ "BokBot", "CRM", "Gozi", "Gozi CRM", "IceID", "IcedID", "Papras", "Snifula", "Ursnif", "Valak", "Valek" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434564, "ts_updated_at": 1775792243, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/6bc1fa48cfea51ddbdbbc39ce99bda61cb09306c.pdf", "text": "https://archive.orkl.eu/6bc1fa48cfea51ddbdbbc39ce99bda61cb09306c.txt", "img": "https://archive.orkl.eu/6bc1fa48cfea51ddbdbbc39ce99bda61cb09306c.jpg" } }