{
	"id": "9bcd3582-99f2-4d28-b952-1776be0e2a18",
	"created_at": "2026-04-06T00:18:55.103721Z",
	"updated_at": "2026-04-10T03:22:11.880389Z",
	"deleted_at": null,
	"sha1_hash": "0823afbabf9146e32a7aacd4c33d6fd935726321",
	"title": "IcedID: Analysis and Detection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1938097,
	"plain_text": "IcedID: Analysis and Detection\r\nBy Quentin Fois, Pavankumar Chaudhari\r\nPublished: 2021-07-08 · Archived: 2026-04-05 17:44:29 UTC\r\nIcedID, also known as BokBot, was first documented in 2017. While the denomination IcedID used to be only\r\nabout the final banking trojan payload, it now commonly refers to the full infection chain characteristic of this\r\nthreat. IcedID stood under the radar for a couple of years, and made the news again in 2019 for using\r\nsteganography to hide its payload. \r\nEver since IcedID loaders evolved and went through multiple steganography techniques. Some of the versions are\r\nknown as “Photoloader” or lately “Gziploader”. The functionalities of the underlying banking trojan themselves\r\nhave seen little evolutions over the years. \r\nThis blogpost will focus on 3 parts: \r\nDescription of an IcedID infection chain \r\nDetailed overview of a dropper document \r\nVMware IcedID threat coverage \r\nIcedID infection chain\r\nFigure 1 IcedID infection chain\r\nThe most commonly observed attack chain for IcedID can be split into three parts:\r\nInitial delivery: Malicious office document\r\n1\r\nst\r\n stage: Packed DLL\r\n2\r\nnd\r\n stage: Packed DLL + encrypted payload\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 1 of 11\n\nInitial delivery:\r\nThe entry point is an email with a malicious payload attached. Usually, the malicious payload is stored in a\r\npassword-protected ZIP, with the password written in the body of the email. This is done as an attempt to bypass\r\nautomated analysis which is commonly done by many email security products.\r\nOnce unlocked, the ZIP archive contains an office document with a malicious payload. Lately, researchers have\r\nreported on IcedID using Jscript dropper, (you can watch malware analysis here) but this is out of the scope of this\r\nblogpost.\r\nIn scenarios where malicious office documents were leveraged, we observed two types of payloads:\r\nVBA macro code, described later in this blogpost\r\nXL4\r\nUltimately, the sample will download the 1st stage DLL and execute it using rundll32.\r\nStage 1:\r\nThe first stage is a single DLL executed with the help of rundll32, and acts as a filter deciding whether the victim\r\nis worth compromising further or not. This stage has two core functionalities:\r\nFingerprinting the OS and sending the data to the CnC\r\nDownloading the next payload from the CnC and executing that payload\r\nBelow is a list of some of the data that the first stage payload will gather:\r\nHow long has the computer been up\r\nHow many processes are running\r\nOS version\r\nCPUID queried data\r\nRDTSC timing loop\r\nAccount information\r\nHardware info\r\nThis data is then transmitted to the CnC (Figure 2) which likely blacklisted some values in order to avoid\r\nuninteresting target or identified sandbox/analyst boxes. If nothing prevents it on the CnC side, the DLL then\r\ndownloads a blob of data that will ultimately become the 2nd stage files. This data is not downloaded as plaintext\r\nbut hidden via steganography techniques. At the time of the analysis the data was hidden behind a fake GZIP\r\nheader, and previously we also observed fake JPG images.\r\nFigure 2 System fingerprinting data hidden amongst cookie values\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 2 of 11\n\nStage 2:\r\nThe 2nd stage consists of two components:\r\nA DLL: a loader\r\nAn encrypted data blob: the banking trojan\r\nThe DLL is executed using the rundll32 executable. The path to the encrypted data blob, often named\r\n“license.dat” is provided via the command line (Figure 3).\r\nFigure 3 Stage 2 command line\r\nUpon execution, the DLL will parse its command line to find the path to the data blob, decrypt it and load it into\r\nmemory. The banking trojan is then live and running. A good description of the trojan functionalities can be read\r\nin this article.\r\nDelivery\r\nSample hash: 9a93fc9f3606055fad6f7a2a9b0a848555d9e8d29eb3e5419a6803c315e8cba4\r\nThis section is an in-depth analysis of a malicious word document found during our investigation.\r\nAs described earlier, a user would access this document after opening an encrypted zip attached to an email. Once\r\nthe document is opened the user is greeted with a banner asking to “Enable Content” in order to execute macros\r\n(Figure 4). A careless user clicking that button would trigger the execution of the malicious VBA macro code.\r\nFigure 4 Macro embedded document\r\nBelow (Figure 5) is an excerpt of the VBA macro code stored in the malicious document, extracted using oletools.\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 3 of 11\n\nFigure 5 VBA macro code snippet\r\nThe VBA macro looks simple and not obfuscated. However, the malware authors have used interesting tricks and\r\ntechniques to hide the malicious code. Indeed, dynamic execution of this code highlights that the macro drops an\r\nHTA file in the computer public folder. The HTA content is not stored in the VBA code itself but is hidden behind\r\nthe image giving the instructions, out of sight from victims and analysts, as shown in Figure 6. In previous\r\nversions, actors used to hide code within a UserForm as labels. This is not a new technique and has been observed\r\nin other campaigns.\r\nFigure 6 Hidden HTA code revealed as document text\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 4 of 11\n\nFigure 7 Code snippet fetching the HTA content\r\nFigure 7 above shows the functions dedicated to extract the HTA file content, by reading the\r\n“ActiveDocument.Range.text” attribute.\r\nIn a similar fashion, other data needed by the VBA macro is hidden in the document properties.\r\nFigure 8 Data hidden in the document properties.\r\nAs shown above, in Figure 8, the path of the dropped HTA file is stored in the “Title” property, and a portion of\r\nthe CLSID is hidden in the “Subject” property of the document. Below in Figure 9 is the code that fetches these\r\nproperties as well as drops the HTA file content on disk.\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 5 of 11\n\nFigure 9 Code snippet to fetch document properties, write hta file and execute hta using COM\r\nTo execute this HTA file, the attacker used an interesting COM technique which is also used for parent process ID\r\n(PPID) spoofing.\r\nIndeed the CLSID C08AFD90-F2A1-11D1-8455-00A0C91F3880 used in the code refers to the\r\nShellBrowserWindow object class and can be used to execute any process as if it was executed from explorer.exe.\r\nIn this case, mshta.exe is executed by winword.exe, but the parent process of mshta.exe will be explorer.exe.\r\nAdversaries use this technique in an attempt to defeat threat hunting activities or to bypass security products. This\r\nPPID Spoofing method is already explained in our previous blog post here. This blog post also provides guidance\r\nto hunt such anomalies.\r\nIn its raw form, the HTA code is obfuscated as shown below Figure 10:\r\nFigure 10 Obfuscated (top) and de-obfuscated (bottom) HTA payload\r\nDesobfucating the HTA content reveals that its only goal is to download a file from a remote server, and to write it\r\non disk in the public folder, under the name “structButtonMemory.jpg”. Despite the “.jpg” extension, this file is\r\nactually a DLL, and gets executed via rundll32.exe calling the “PluginInit” exported function as an entry point.\r\nThis DLL is the 1st stage DLL payload, also referred to as Gziploader.\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 6 of 11\n\nAs mentioned in the introduction overview, this 1st\r\n stage DLL will download a file purporting to be a gzip\r\ncompressed file. The first stage DLL will then extract two files from the fake gzip file: another DLL (the 2nd\r\nstage) and an encrypted data blob, which will be saved with a “.dat” extension. The second stage DLL file is a bot\r\nloader which is executed with rundll32.exe, with the file path to the .dat file being provided as a parameter. This\r\nprocess decodes the main bot in memory and performs additional malicious activities.\r\nVMware detection coverage\r\nVMware EDR Carbon Black will alert as soon as the dropper document gets executed thanks to multiple fine-tuned rules.\r\nAnomaly in winword.exe process\r\nExecuting HTA payload via PPID spoofing \r\nRundll32 payload execution\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 7 of 11\n\nVMware NDR and sandboxing capabilities protect the network from any stage of the infection.\r\nInitial document analysis\r\n1\r\nst\r\n stage DLL analysis\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 8 of 11\n\n2\r\nnd\r\n stage DLL and final payload analysis\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 9 of 11\n\nConclusion\r\nThrough this blogpost, we detailed the different steps commonly involved in an IcedID infection and did a deep\r\ndive into one of its initial infection document. IcedID is a three stages threat involving two DLL loaders executed\r\nvia rundll32.exe. While the last stage of the IcedID chain is a banking trojan, IcedID can also be used as a pivot\r\npoint to deliver other threats such as Ransomware or even serve as a foothold for further lateral propagation.\r\nLeveraging both the VMware EDR and NDR solutions provides visibility, detection, and prevention of threats like\r\nIcedID at every stage of the attack.\r\nIOCs:\r\nMalicious documents SHA256\r\n6aca19225d02447de93cbf12e6f74824371be995a17d88e264c79d15cb484b28\r\n100345684c677d50ff837959699aaef34e583fd11d812ccef80dbfe03c0db62a\r\nda6a91012518cd07ae61313fd108711b56f406068efb119f678a4946438c6800\r\ndb08770ab1946bc505cc5a5483767a194d7801d32f2ea6c78fd0c966d0c7bc75\r\n74d5e62a2f6c6bcf10dfcdbcc55407be8af9662b50f2e2a2c5b33bf5e800e7e6\r\nad28c42b8961132b71581e7a438c3eaa7c7008577ce8bd60de44d67414a244b9\r\n2cef187ef4a2aa3fc58ff8f67a5a5a0eb1d29fd8a7c1d7f21a8654f2bb074de3\r\nbf06b490e30ca9a8cc4de134f82a20af3299c107c457ef29ff1cff213d0bba1c\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 10 of 11\n\n348110a61e369a448b64fa3fb8009a48b7a54bcec3b1af4e3f532f4092d09a39\r\n0f229335c60fc3ce5b302ba16c2befbf8ff8f2f3938fdc9891e54b0841dc1daa\r\nSource: https://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nhttps://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blogs.vmware.com/security/2021/07/icedid-analysis-and-detection.html"
	],
	"report_names": [
		"icedid-analysis-and-detection.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434735,
	"ts_updated_at": 1775791331,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0823afbabf9146e32a7aacd4c33d6fd935726321.pdf",
		"text": "https://archive.orkl.eu/0823afbabf9146e32a7aacd4c33d6fd935726321.txt",
		"img": "https://archive.orkl.eu/0823afbabf9146e32a7aacd4c33d6fd935726321.jpg"
	}
}