{
	"id": "68fb28b0-55c8-4992-83c6-5f08deb0e50c",
	"created_at": "2026-04-06T00:15:17.085589Z",
	"updated_at": "2026-04-10T03:20:32.18683Z",
	"deleted_at": null,
	"sha1_hash": "2bd38f5cae64301d0977767070c1eca30be0c87a",
	"title": "A Deep Dive Into IcedID Malware: Part II - Analysis of the Core IcedID Payload (Parent Process)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4995198,
	"plain_text": "A Deep Dive Into IcedID Malware: Part II - Analysis of the Core\r\nIcedID Payload (Parent Process)\r\nBy Kai Lu\r\nPublished: 2019-07-16 · Archived: 2026-04-05 17:24:53 UTC\r\nFortiGuard Labs Threat Analysis Report Series\r\nIn part I of this blog series, I demonstrated how to unpack the IcedID malware, hooking and process injection\r\ntechniques used by IcedID, as well as how to execute the IcedID payload. In this part below, let’s take a closer\r\nlook at the core payload.\r\n0x01 Overview Of The Payload\r\nThe following is the entry point of the payload. It first unhooks the function RtlExitUserProcess. The core\r\nfunction is implemented in the function sub_0x27FE(). Once the core module is executed successfully, the\r\nprogram is entering into an infinite loop that ensures the svchost.exe process does not exit. \r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 1 of 16\n\nFigure 1. The entry point of the payload\r\nNext, let’s look at the function sub_0x27FE(). \r\nFigure 2. The function sub_0x27FE()\r\nIn the next sections, I will show you what the function does.\r\n0x02 Two Injected Memory Regions\r\nAs you can see in Figure 15 of Part I, there are two injected memory regions into svchost.exe process. The first\r\none is a data segment whose size is 8KB. This segment stores several system API’s addresses at the beginning,\r\nencrypted C2 server list as well as other useful info.\r\nThe following is the system API’s addresses. The program can invoke them indirectly by instructions like “call\r\n[base_addr + offset]”.  The way of indirectly calling system API is tricky to static analysis.\r\nFigure 3. The system API’s addresses stored in the injected memory region\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 2 of 16\n\nThe following is these corresponding API’s names for the addresses above.\r\nFigure 4. These system API’s names\r\nAdditionally, it stores the encrypted C2 server list at offset 0x350.\r\nFigure 5. The encrypted C2 server list\r\nThe second memory region has three segments (one code segment and two data segments). The core function of\r\nthe payload is implemented in the code segment.\r\n0x03 Communication With C2 Server\r\nLet’s first look at how to get the C2 server list. As shown in Figure 5, the encrypted data are 256 bytes. And the\r\ndecrypted data is shown in Figure 6. \r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 3 of 16\n\nFigure 6. The C2 server list\r\nWe can get the initial C2 server list.\r\nalbarthurst[.]pro\r\nmozambiquest[.]pw\r\nransmittend[.]club\r\nsummerch[.]xyz\r\nIcedID uses the WinHTTP APIs to communicate with C2 servers. It sends a request and receives the response over\r\nHTTPS. We can intercept the HTTPS traffic via Fiddler. But before using it, we have to set WinHTTP’s Proxy. \r\nOn Windows Vista and later, we need to use an elevated (admin) command prompt to call netsh like the following.\r\nThe detailed instructions please refer to https://www.telerik.com/blogs/using-fiddler-with-winhttp.\r\nFigure 7. Set WinHTTP’s Proxy\r\nThe following is the decrypted HTTPS traffic IcedID sent in Fiddler.\r\nFigure 8. The decrypted HTTPS traffic IcedID sent in the initial stage\r\nIn the initial stage, IcedID could send a HTTP request over SSL to the C2 server. Then it parses the response and\r\ncontinues to send 7 HTTP requests over SSL to download seven .DAT config files. Next, let’s dive into the URL\r\nparameters of the HTTP POST request. I highlighted some key items.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 4 of 16\n\nFigure 9. The HTTP POST request’s URL parameters\r\nThe first one is the Bot ID which is also used as RC4 key to encrypt the original .DAT config files. The parameter\r\n‘r’ indicates the version of IcedID. Its version number is 108 in this sample. Regarding the RC4 key generation\r\nalgorithm, I will unveil its details in next section.\r\n0x04 RC4 Key Generation Algorithm\r\nThe function sub_0x29E2 is used to generate the RC4 key whose size is 4 in bytes. \r\nFigure 10. The RC4 key generation algorithm\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 5 of 16\n\nThe RC4 key is stored at offset 0x74A8 from starting address of the second injected memory region. Then the\r\nRC4 key is also copied to the buffer at offset 0x74B8.\r\n0x05 Multiple Threads For Cooperative Work\r\nIcedID could create multiple threads to perform different tasks. Based on my analysis, there are five child threads\r\ncreated by invoking the function CreateThread. Some threads are always running, the others would exit after\r\ncompleting their tasks depending on the received C2 command. Here I list their thread functions below.\r\nThread 1 - Thread Function 0x2601\r\nThis thread function is mainly responsible for the initial communication with C2 server, handling the HTTP\r\nresponse, as well as downloading the .DAT config files or other types of files depending on the HTTP response\r\nand storing them into the corresponding folders. The following is the pseudo code of this thread function.\r\nFigure 11. The thread function 0x2601\r\nIn this infinite loop, it waits until the specified object is in the signaled state or the time-out interval (here it’s 5\r\nminutes) elapses. Then it generates the URL parameters and HTTP request body. Next, it could communicate with\r\nC2 server over HTTPS. Finally, it handles the HTTP response and continues to download the .DAT config files or\r\nother files depending on the parsing result of the HTTP response. This thread doesn’t exit and is always running to\r\ncommunicate with the C2 server.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 6 of 16\n\nWhen IcedID is executed at the first time, the initial communication traffic is shown below.\r\nFigure 12. The initial communication with C2 server\r\nAs shown in Figure 12, the response is a multiple-line message. Each line is a C2 command consisting of three\r\nparts that are separated by a semicolon. The malware could call the corresponding handler function to complete\r\nspecific task based on the C2 command number. The first part represents the event ID, the second part represents\r\nthe index of handler function, the third part represents the parameter passed to the handler function.  The\r\nfollowing is the call to handler function.\r\nFigure 13. The call to handler function and all handler’s addresses\r\nIn this IcedID sample, it supports 18 different types of C2 commands.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 7 of 16\n\nThread 2 - Thread Function 0x5599\r\nThis thread function is responsible for downloading .DAT config file and other types of files (such as executable\r\nfile) from C2 server, and saving these data into the local files. For .DAT config files, the HTTP response body is\r\nencrypted twice by RC4 algorithm with two different keys. Let’s take a closer look at the encryption process.  The\r\nfollowing is the HTTP response from C2 server.\r\nFigure 14. Two-layer RC4 encryption process on HTTP response body\r\nAs shown in Figure 14, the first 8 bytes in the HTTP response body is the first layer’s RC4 key. The length of\r\nsecond RC4 key is 4 in bytes. Its generation algorithm refers to the section “RC4 key generation algorithm”.\r\nThread 3 - Thread Function 0x2E59\r\nThis thread function is responsible for copying the IcedID PE file into \"C:\\ProgramData\\{0CD48D26-D226-\r\n4D28-9E39-3D2840658FD3}\\{8CD48D26-D226-4D28-9E3A-3D2844658FD3}\\qgbjaykqtsu.exe\" and scheduling\r\na task at logon. The name of the sub-directory may differ on different compromised machines. The scheduled task\r\nis shown below.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 8 of 16\n\nFigure 15. Schedule a task at logon\r\nThread 4 - Thread Function 0x1F9B\r\nThis thread function is responsible for communicating with C2 server. This thread is created in the handler\r\nfunction which handles the C2 command 17 in Figure 13.\r\nThread 5 - Thread Function 0x52FC\r\nThis thread function is responsible for creating three new svchost.exe child processes and injecting code into these\r\nprocesses’ space.\r\nFigure 16. The thread function 0x52fc\r\nAs shown in Figure 16, IcedID creates the svchost.exe child process with parameter CREATE_SUSPENDED. The\r\nprimary thread of the new process would be in a suspended state, and the newly created process does not run until\r\nthe ResumeThread function is called. Before resuming the primary thread, IcedID performs the code injection\r\ninto the new process space. After that, it calls the ResumeThread function. The pseudo code of the injected code\r\nis shown in Figure 17.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 9 of 16\n\nFigure 17. Inject code into svchost.ext child process\r\nIn the injection function, it first allocates three memory regions into the remote process space. Then it decrypts the\r\ninjected code from DAT config file. Next, it performs the code injection into previous allocated three memory\r\nregions. Finally, it sets up a hook at RtlExitUserProcess API in the remote process space. Next, let’s continue to\r\nanalyze which DAT config file is injected into the corresponding child process.\r\n1. yxuvgoshgc.dat(748961aabd75b85ee602e5f6d70322b281930349fbc98ad5c638104a759eba0b)\r\nThis DAT config file is injected into the child process 1 like the following. There are three memory regions to be\r\ninjected into the child process 1. The first one is the injected code segment. The second one is a data segment\r\nincluding several system API’s addresses and updated C2 server list. The third one is a PE file.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 10 of 16\n\nFigure 18. Injected svchost.exe child process 1\r\nThe hooked RtlExitUserProcess in child process 1 is shown below. When the RtlExitUserProcess function is\r\ncalled, it jumps to 0x210DF(offset:0x10DF) to execute the payload.\r\nFigure 19. Hooked RtlExitUserProcess in svchost.exe child process 1\r\n2. uvgbwwwjcc.dat(b1d9d9bb617463a1cef665322949b29ad23ebfee2892908385b30cd739c163ce)\r\nThis DAT config file is injected into the child process 2 like the following. There are three memory regions to be\r\ninjected into the child process 2. The first one is the injected code segment. The second one is a data segment\r\nincluding several system API’s addresses and updated C2 server list. The third one is a data segment.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 11 of 16\n\nFigure 20. Injected svchost.exe child process 2\r\nThe hooked RtlExitUserProcess in child process 2 is shown below. When the RtlExitUserProcess function is\r\ncalled, it jumps to 0x21E0A(offset:0x1E0A) to execute the payload.\r\nFigure 21. Hooked RtlExitUserProcess in svchost.exe child process 2\r\n3. encziczibc.dat(672440151cd67a20bccc5c9f9f66f7d091098b0bd2a087eeac79af1f11bf3403)\r\nThis DAT config file is injected into the child process 3 like the following. There are three memory regions to be\r\ninjected into the child process 3. The first one is the injected code segment. The second one is a data segment\r\nincluding several system API’s addresses and updated C2 server list. The third one is a data segment.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 12 of 16\n\nFigure 22. Injected svchost.exe child process 3\r\nThe hooked RtlExitUserProcess in child process 3 is shown below. When the RtlExitUserProcess function is\r\ncalled, it jumps to 0x11168E(offset:0x168E) to execute the payload.\r\nFigure 23. Hooked RtlExitUserProcess in svchost.exe child process 3\r\nRegarding how these three child processes work internally, I will continue to analyze it in part III.\r\n0x06 Persistent Payload And File Write Operations\r\nWe observed some file write operations like the following. It puts the persistent payload into a specific folder. And\r\nit also puts seven .DAT config files into the folder “C:\\ProgramData\\cmrreaykdkq”. The sub-directory name might\r\ndiffer in different compromised systems.\r\nFigure 24. The file write operations of persistent payload and DAT config files\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 13 of 16\n\nThe following table lists the detailed description of these DAT config files. \r\nTable 1. The detailed description of DAT config files\r\n0x07 Signature Verification\r\nIcedID can do signature verification of the payload. It first decrypts the C2 server config file(alofykqgeb.dat) with\r\nRC4 key (see “RC4 key generation algorithm” section). The decrypted data buffer is shown below. This buffer has\r\nthree parts. The first 8 bytes is the original RC4 key. The subsequent 0x80 bytes of data is the signature data to be\r\nverified. The third part is the updated C2 server list.\r\nFigure 25. Decrypt data in alofykqgeb.dat\r\nNext, it decrypts the buffer of hard-coded RSA public key with XOR operation.\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 14 of 16\n\nFigure 26. The hard-coded RSA public key which is encrypted and RSA public key\r\nThen, it calls CryptVerifySignatureW function to verify the signature.\r\nFigure 27. Call CryptVerifySignatureW function to verify the signature\r\n0x08 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\n0x09 Conclusion\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 15 of 16\n\nWe have walked through what the svchost.exe parent process does internally. It includes how IcedID\r\ncommunicates with C2 server, RC4 key generation algorithm, the code injection process, what the multiple\r\nthreads do in detail, signature verification, etc.\r\nIn the next blog, I will provide a deep analysis of these three svchost.exe child processes. \r\nReference\r\nSHA256\r\nalofykqgeb.dat(00040d021a4813f11ba580ad76c669144ae787b8b93c6a3559e6662301d3be72)\r\nencziczibc.dat(672440151cd67a20bccc5c9f9f66f7d091098b0bd2a087eeac79af1f11bf3403)\r\nkdkdkqtfdb.dat(9bfb66621cf27f086f8db9e8761841fd0aff3a0a6348988324b408319639b9b8)\r\nuvgbwwwjcc.dat(b1d9d9bb617463a1cef665322949b29ad23ebfee2892908385b30cd739c163ce)\r\nwjalosuiec.dat(29d47ddb05381dd591c77c5eee62236cfc7120b1719d6e40f29872e9c9b53a0c)\r\nyxuvgoshcb.dat(24818652fd0031b3a1626da35068ec868d8d3b9635cb011677188cf73bc3eb5a)\r\nyxuvgoshgc.dat(748961aabd75b85ee602e5f6d70322b281930349fbc98ad5c638104a759eba0b)\r\nC2 Server\r\nalbarthurst[.]pro\r\nmozambiquest[.]pw\r\nransmittend[.]club\r\nsummerch[.]xyz\r\nethracial[.]pw\r\nsaudienter[.]pw\r\ngoodinzone[.]at\r\nforsynanchyv[.]com\r\nhipponexunam[.]org\r\nchardiop[.]club\r\nparenessed[.]icu\r\nmechangerous[.]space\r\nexchangests[.]xyz\r\nhydrylater[.]online\r\ncarlsbadenomise[.]top\r\nwagenstead[.]xyz\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/icedid-malware-analysis-part-two.html\r\nhttps://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/icedid-malware-analysis-part-two.html"
	],
	"report_names": [
		"icedid-malware-analysis-part-two.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434517,
	"ts_updated_at": 1775791232,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2bd38f5cae64301d0977767070c1eca30be0c87a.pdf",
		"text": "https://archive.orkl.eu/2bd38f5cae64301d0977767070c1eca30be0c87a.txt",
		"img": "https://archive.orkl.eu/2bd38f5cae64301d0977767070c1eca30be0c87a.jpg"
	}
}