Fraud
September 04, 2019

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

article
6 min. read
By Daniel Frank
Additional Contributions By Remi Cohen

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.1 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.2

IcedID’s core module and some processes were deeply technically analyzed by two other security companies.34 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.

Figure 1: Screenshot showing the configuration files dropped by IcedID

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

Figure 2: Screenshot of a packet capture showing the key 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:

Figure 3: Screenshot showing the ‘zeus’ header used to verify webinjects files

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

Figure 4: Screenshot of the ‘zeus’ header being verified in the IcedID assembly code

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.

Figure 5: Screenshot of IcedID searching for specific bytes

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.

Figure 6: Screenshot of the malware without the appropriate header

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.

Figure 7: Screenshot of the malware with the gzip header highlighted

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.1

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

Figure 8: Decryption and Decompression script

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

Figure 9: Decompressed and decrypted data from the IcedID webinjects file

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:

Technical
Preventative
  • Implement web fraud protection to detect customers logging into your applications with infected clients designed to engage in fraud.
Administrative
Corrective
  • Notify your clients of the malware you detected on their system while logging into your application (which can result in them being blocked from carrying out a transaction), so they can take steps to clean their systems.
Administrative
Preventative
  • Provide security awareness training to employees and to clients.

Need-to-Know

Expertly picked stories on threat intelligence

Hundreds of apps will be attacked by the time you read this.

So, we get to work. We obsess over effective attack methods. We monitor the growth of IoT and its evolving threats. We dive deep into the latest crypto-mining campaigns. We analyze banking Trojan targets. We dissect exploits. We hunt for the latest malware. And then our team of experts share it all with you. For more than 20 years, F5 has been leading the app delivery space. With our experience, we are passionate about educating the security community-providing the intel you need to stay informed so your apps can stay safe.

Every

9 hrs

a critical vulnerability—with the potential for remote code execution—is released.