De-icing IcedID: Decompression and Decryption Methods Explained in an IcedID Attack

IcedID is a well-researched banking trojan. For this analysis, F5 researchers zeroed in on how its decompression method works.

• In this article, we provide the code with which to analyze the decompression method used by IcedID for its target list and webinject configuration file.
• Decompression is significant because once it occurs, the file is loaded to the malware’s proxy module where it can then inject relevant files on a target website.
• While IcedID remains an active threat to financial institutions, it’s now also targeting social media, video streaming, search engines, and digital communications.

IcedID (also known as Bokbot) is a malicious banking trojan that was first spotted in late 2017 by the IBM X-force research team.¹ It continues to be an active threat, constantly evolving, and updating its level of sophistication. It was spotted in 2018 collaborating with Trickbot, another active banking trojan, for distribution and development.²

IcedID’s core module and some processes were deeply technically analyzed by two other security companies.^3, 4 F5 researchers wanted to expand and characterize the actual decompression method used by IcedID to decompress dropped webinject configuration files. The sample analyzed here is not new, but the methods described remain useful for malware analysis techniques. The decompression method used here is significant because it allows us to see the malware’s target list and webinjects in plaintext.

According to the previous research on IcedID, there are various unique IDs created by the malware to fingerprint the infected machine. The initial RC4 key that is being used to decrypt the webinject files is generated out of these IDs.

Looking at a specific packet, the key is sent over to the command and control (C&C) server in plaintext.

In order to RC4 decrypt the webinject files, we can take the first four bytes, reverse their order, and use them as the initial RC4 key to decrypt the webinject files. In the above example our key will be ‘\xe3\x2d\x88\xec’.

Now that we have the key, we can decrypt the first stage. After the decryption, we need to make sure we see the ‘zeus’ header in the beginning of the decrypted file. IcedID, a child of the Zeus malware, uses the ‘zeus’ header to verify it is a webinjects file:

Looking at the malware assembly code, the ‘zeus’ header is verified.

Then, another check is made, this time in search of a gzip header. IcedID searches for specific gzip “magic bytes” and compression methods. Figure 5 shows the search of value 0x8, which stands for DEFLATE, which is a lossless data compression file format. This information is valuable to the malware so it can use the right decompression method in order to decompress and load the webinjects into its proxy module. Simply, this is the key step which will allow the malware to unveil its webinjects in order to steal information.

When IcedID is decompressing the webinjects file in real-time, the malware does not have the appropriate header stored either in memory or in the rc4 decrypted file, as shown in Figure 6.

But, when the decompression of another file (the malicious hosts list) is executed, a gzip header is prepended onto the data. These are the “magic bytes” which indicate the previously mentioned DEFLATE decompression method should be used, and another seven zeroed bytes that complete the header structure.

We found that if the header is prepended to a given RC4 decrypted webinjects file,we can create a Python script that skips the first 8 bytes, then creates a zlib object and decompresses the file. The first 8 bytes in the decrypted file represent the previously mentions ‘zeus’ header and decompressed data size; we can also trim the last 4 bytes, which also represent the decompressed data size. However, this method will still work without trimming the last 4 bytes. It’s also important to note that we must set the window size to be 16 + zlib.MAX_WBITS for the decompression to work. Read more about this in python documentation linked in the footnotes.¹

Finally, after installing pycrpto and combining both stages, our decryption and decompression script will look like this:

Once the script is run, the decrypted and decompressed data are shown in Figure 9.

The next step in this process is to convert the decrypted and decompressed data file from binary into a human readable format. The following python snippet provides a regular expression that will roughly split the injects from one another:

import re

regex_res = re.split('[\x00]{1}[\x00-\xff]{7}[\x00]{2}[\x01-\xff]{1}', data[7:])

The steps outlined here can be used on the different webinjects files and command and control (C&C) list files dropped by IcedID.

During an attack, decompression and decryption is an essential step in IcedID’s attack process. Once the decompression takes place, the resulting data file is loaded into the malware’s proxy module. When an infected system visits a website in the target list, IcedID injects the relevant webinjects. The ability to decompress and decrypt these files into a human readable format grants visibility into what sites are being targeted by the malware, and what kinds of web injections are being used during its attacks.

Conclusions

IcedID is an active banking trojan that has been seen collaborating with other malware in the past. IcedID continues to target many different financial institutions, as well as social media sites, search engines, and video streaming. This means that everyone should be aware of the dangers of this trojan. This decompression and decryption technique provides an additional resource and tool for researchers looking to glean more detail from the IcedID samples they may encounter.

Countermeasures

The following security controls are recommended to mitigate these types of attacks: