{
	"id": "6428ef8d-3a0f-48d8-9702-a756e45c91be",
	"created_at": "2026-04-06T00:19:33.407549Z",
	"updated_at": "2026-04-10T03:21:49.577429Z",
	"deleted_at": null,
	"sha1_hash": "4833936bd85f580468223cdde036ca350e3e81f3",
	"title": "A Deep Dive Into IcedID Malware: Part III - Analysis of Child Processes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1404305,
	"plain_text": "A Deep Dive Into IcedID Malware: Part III - Analysis of Child\r\nProcesses\r\nBy Kai Lu\r\nPublished: 2019-07-22 · Archived: 2026-04-05 18:07:39 UTC\r\nFortiGuard Labs Threat Analysis Report Series\r\nIn Part II of this blog series, we identified three child processes that were created by the IcedID malware. In Part\r\nIII below, we’ll provide a deep analysis of those child processes.\r\nLet’s get started!\r\n0x01 Child process A (entry offset: 0x168E)\r\nThis first child process is primarily responsible for performing web injection in browsers and acting as a proxy to\r\ninspect and manipulate traffic. It can also hook key functions in browsers.\r\nThe following is the pseudo code of the entry point.\r\nFigure 1. The pseudo code of the entry point in the trampoline code\r\nIn this function, the process first unhooks the RtlExitUserProcess API and then loads a number of dynamic\r\nlibraries. The function sub_0x1A9F() is the core function. \r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 1 of 10\n\nFigure 2. The core function sub_0x1A9F()\r\nHere’s a list of the key functionalities of this function. \r\n1.     Build a C2 server list \r\n2.     Create a thread to set IPC with file mapping technique \r\n3.     Create a thread and then call the QueueUserAPC function to add a user-mode asynchronous procedure call\r\n(APC) object to the APC queue of the specified thread. In APC, it can read the DAT config file, decrypt it with an\r\nRC4 key, and then decompress the data as follows.\r\nFigure 3. The decrypted web injection DAT config file\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 2 of 10\n\nThis DAT config file is used for performing web injections. It uses a Magic number, “zeus”. IcedID then uses a\r\ncustomized algorithm to decode the content. The following is the decompressed data.\r\nFigure 4. The decompressed data of web injection\r\n4. Add self-signed certificate into the certificate store and then create a proxy server which is bound to 127.0.0.1\r\non TCP port 61420. Next, it calls the RegisterWaitForSingleObject function to register a WSA (Windows Socket\r\nAPI) event handler, then uses the socket of the initialized proxy server to handle all connect, send, and receive\r\nnetwork requests.\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 3 of 10\n\nFigure 5. Proxy server handles network requests\r\nAdditionally, in order to perform a MiTM attack on SSL connections, the proxy server has to generate a certificate\r\nand add it into the cert store. The following is that implementation.\r\nFigure 6. Adding a self-signed cert into the cert store\r\nWe can also see that this svchost.exe child process is listening on TCP port 61420.    \r\n5. Create a thread to perform code injection into the browser. The following is the thread function of the browser\r\ncode injection.\r\nFigure 7. The browser injection function\r\nIt uses the ZwQuerySystemInformation function to gather a list of all current running processes. If a browser\r\nprocess is found, it performs code injection into the browser process and sets up a hook on the\r\nZwWaitForSingleObject function. The following is the function that checks to see if a running process is a\r\nbrowser process. It first generates a hash with the process name using a specified algorithm. Then, it compares the\r\nhash with the given hash of four browsers: Firefox, Edge, IE, and Chrome.\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 4 of 10\n\nFigure 8. Checking the hash of the process name\r\nBefore performing its code injection, it first checks to see if this process is running on 64 bits by calling the\r\nIsWow64Process function. It then performs a code injection into the browser process, and depending on the\r\nprocess bits version, it calls the corresponding hook function to set up a hook on the ZwWaitForSingleObject\r\nfunction. \r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 5 of 10\n\nFigure 9. Process injection and setting up a hook in a browser\r\nHere we will use Firefox to demonstrate how it performs its process injection and sets up a hook.\r\nFigure 10. Process injection into Firefox\r\nIt sets up a hook on the ZwWaitForSingleObject API in the Firefox process as follows.\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 6 of 10\n\nFigure 11. Hooked ZwWaitForSingleObject function\r\nWhen Firefox calls the ZwWaitForSingleObject function, it jumps to the trampoline code. The entry point of\r\ntrampoline code is at offset 0x1856 from the injected memory region.\r\nLet’s take a closer look at the trampoline code (offset:0x1856).\r\nIn this trampoline code, it first unhooks the ZwWaitForSingleObject API. Then it sets up a hook on the\r\nSSL_AuthCertificateHook API (in nss3.dll for Firefox.) The nss3.SSL_AuthCertificateHook function specifies a\r\ncertificate authentication callback function that is called to authenticate an incoming certificate.\r\nThe following is the hooked nss3.SSL_AuthCertificateHook function.    \r\nFigure 12. The hooked nss3.SSL_AuthCertificateHook function\r\nIt configures the nss3.SSL_AuthCertificateHook function to always return SECSuccess. \r\nNote that it can set up a hook for browser-specific functions depending on the type of browser. However, we won’t\r\nbe providing details for any other browsers in this blog.\r\nNext, it continues to set up a hook on the connect API in ws2_32.dll. The following is the hooked connect API.\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 7 of 10\n\nFigure 13. The hooked connect API in ws2_32.dll\r\nThe following is the pseudo code of the trampoline code for the hooked connect API.    \r\nFigure 14. The pseudo code of the trampoline code for the hooked connect API\r\nOnce the connect function returns 0 (the connection has succeeded), it sends 12 bytes of data to proxy server\r\n127.0.0.1:61420, which was created in this svchost.exe child process. The captured traffic is shown in Figure 15.\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 8 of 10\n\nFigure 15. Brower sends 12 bytes of data to proxy server\r\nThe structure of these 12 bytes consists of four parts, as follows:\r\n0x00: Unknown\r\n0x04: Target website’s IP address\r\n0x08: Port\r\n0x0A: Browser type\r\n0x02 Child Process B (entry offset: 0x1E0A)\r\nThis second child process is used to communicate with the C2 server. It will attempt to send an HTTP request to\r\nthe C2 server via WebSocket, as follows.\r\nFigure 16. Requesting data from the C2 via WebSocket\r\nIt also communicates with the parent svchost.exe process using a mapping file technique. And, depending on the\r\nshared info, it may attempt to make network requests to a C2 server over SSL, and then create a new process,\r\nperform code injections, and set up a hook on the RtlExitUserProcess function.\r\n0x03 Child Process C (entry offset: 0x10DF)\r\nThis process communicates with the parent svchost.exe process by using a mapping file technique. It is also able\r\nto perform some registry operations.\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 9 of 10\n\n0x04 Solution\r\nThis malicious PE file has been detected as “W32/Kryptik.GTSU!tr” by the FortiGuard AntiVirus service.\r\nThe C2 server list has been rated as “Malicious Websites” by the FortiGuard WebFilter service.\r\n0x05 Conclusion\r\nIn this series of posts, I have provided a detailed analysis of a new IcedID malware sample. The entire detailed\r\nanalysis is divided into three parts. The first two part are available here: Part I: Unpacking, Hooking, and Process\r\nInjection and Part II: Analysis of the Core IcedID Payload (Parent Process).\r\nIcedID is a sophisticated and complicated banking trojan that performs web injection in browsers and acts as\r\nproxy to inspect and manipulate traffic. It is designed to steal information – such as credentials – from victims and\r\nthen send that stolen information to attacker-controlled servers. To accomplish this, IcedID uses a large number of\r\nhooking and process injection techniques, and it also disguises itself as several svchost.exe processes, which we\r\nexamined in this deep dive analysis series.\r\nLearn more about FortiGuard Labs and the FortiGuard Security Services portfolio. Sign up for our weekly\r\nFortiGuard Threat Brief. \r\nRead about the FortiGuard Security Rating Service, which provides security audits and best practices.\r\nSource: https://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nhttps://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/deep-dive-icedid-malware-analysis-of-child-processes.html"
	],
	"report_names": [
		"deep-dive-icedid-malware-analysis-of-child-processes.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434773,
	"ts_updated_at": 1775791309,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4833936bd85f580468223cdde036ca350e3e81f3.pdf",
		"text": "https://archive.orkl.eu/4833936bd85f580468223cdde036ca350e3e81f3.txt",
		"img": "https://archive.orkl.eu/4833936bd85f580468223cdde036ca350e3e81f3.jpg"
	}
}