A Deep Dive Into IcedID Malware: Part III – Analysis of Child Processes

FortiGuard Labs Threat Analysis Report Series

In Part II of this blog series, we identified three child processes that were created by the IcedID malware. In Part III below, we’ll provide a deep analysis of those child processes.

Let’s get started!

0x01 Child process A (entry offset: 0x168E)

This first child process is primarily responsible for performing web injection in browsers and acting as a proxy to inspect and manipulate traffic. It can also hook key functions in browsers.

The following is the pseudo code of the entry point.

In this function, the process first unhooks the RtlExitUserProcess API and then loads a number of dynamic libraries. The function sub_0x1A9F() is the core function. 

Here’s a list of the key functionalities of this function. 

1.     Build a C2 server list 

2.     Create a thread to set IPC with file mapping technique 

3.     Create a thread and then call the QueueUserAPC function to add a user-mode asynchronous procedure call (APC) object to the APC queue of the specified thread. In APC, it can read the DAT config file, decrypt it with an RC4 key, and then decompress the data as follows.

This DAT config file is used for performing web injections. It uses a Magic number, “zeus”. IcedID then uses a customized algorithm to decode the content. The following is the decompressed data.

4. Add self-signed certificate into the certificate store and then create a proxy server which is bound to 127.0.0.1 on TCP port 61420. Next, it calls the RegisterWaitForSingleObject function to register a WSA (Windows Socket API) event handler, then uses the socket of the initialized proxy server to handle all connect, send, and receive network requests.

Additionally, in order to perform a MiTM attack on SSL connections, the proxy server has to generate a certificate and add it into the cert store. The following is that implementation.

We can also see that this svchost.exe child process is listening on TCP port 61420.    

5. Create a thread to perform code injection into the browser. The following is the thread function of the browser code injection.

It uses the ZwQuerySystemInformation function to gather a list of all current running processes. If a browser process is found, it performs code injection into the browser process and sets up a hook on the ZwWaitForSingleObject function. The following is the function that checks to see if a running process is a browser process. It first generates a hash with the process name using a specified algorithm. Then, it compares the hash with the given hash of four browsers: Firefox, Edge, IE, and Chrome.

Before performing its code injection, it first checks to see if this process is running on 64 bits by calling the IsWow64Process function. It then performs a code injection into the browser process, and depending on the process bits version, it calls the corresponding hook function to set up a hook on the ZwWaitForSingleObject function. 

Here we will use Firefox to demonstrate how it performs its process injection and sets up a hook.

It sets up a hook on the ZwWaitForSingleObject API in the Firefox process as follows.

When Firefox calls the ZwWaitForSingleObject function, it jumps to the trampoline code. The entry point of trampoline code is at offset 0x1856 from the injected memory region.

Let’s take a closer look at the trampoline code (offset:0x1856).

In this trampoline code, it first unhooks the ZwWaitForSingleObject API. Then it sets up a hook on the SSL_AuthCertificateHook API (in nss3.dll for Firefox.) The nss3.SSL_AuthCertificateHook function specifies a certificate authentication callback function that is called to authenticate an incoming certificate.

The following is the hooked nss3.SSL_AuthCertificateHook function.    

It configures the nss3.SSL_AuthCertificateHook function to always return SECSuccess. 

Note that it can set up a hook for browser-specific functions depending on the type of browser. However, we won’t be providing details for any other browsers in this blog.

Next, it continues to set up a hook on the connect API in ws2_32.dll. The following is the hooked connect API.

The following is the pseudo code of the trampoline code for the hooked connect API.    

Once the connect function returns 0 (the connection has succeeded), it sends 12 bytes of data to proxy server 127.0.0.1:61420, which was created in this svchost.exe child process. The captured traffic is shown in Figure 15.

The structure of these 12 bytes consists of four parts, as follows:

0x00: Unknown

0x04: Target website’s IP address

0x08: Port

0x0A: Browser type

0x02 Child Process B (entry offset: 0x1E0A)

This second child process is used to communicate with the C2 server. It will attempt to send an HTTP request to the C2 server via WebSocket, as follows.

It also communicates with the parent svchost.exe process using a mapping file technique. And, depending on the shared info, it may attempt to make network requests to a C2 server over SSL, and then create a new process, perform code injections, and set up a hook on the RtlExitUserProcess function.

0x03 Child Process C (entry offset: 0x10DF)

This process communicates with the parent svchost.exe process by using a mapping file technique. It is also able to perform some registry operations.

0x04 Solution

This malicious PE file has been detected as “W32/Kryptik.GTSU!tr” by the FortiGuard AntiVirus service.

The C2 server list has been rated as “Malicious Websites” by the FortiGuard WebFilter service.

0x05 Conclusion

In this series of posts, I have provided a detailed analysis of a new IcedID malware sample. The entire detailed analysis is divided into three parts. The first two part are available here: Part I: Unpacking, Hooking, and Process Injection and Part II: Analysis of the Core IcedID Payload (Parent Process).

IcedID is a sophisticated and complicated banking trojan that performs web injection in browsers and acts as proxy to inspect and manipulate traffic. It is designed to steal information – such as credentials – from victims and then send that stolen information to attacker-controlled servers. To accomplish this, IcedID uses a large number of hooking and process injection techniques, and it also disguises itself as several svchost.exe processes, which we examined in this deep dive analysis series.

Learn more about FortiGuard Labs and the FortiGuard Security Services portfolio. Sign up for our weekly FortiGuard Threat Brief. 

Read about the FortiGuard Security Rating Service, which provides security audits and best practices.