How The IcedID Banking Trojan Exploits The Pandemic

The IcedID malware, also known as Bokbot, is a banking trojan first discovered in 2017 that steals credentials by tricking browser functions into redirecting traffic. It is a stealthy, fileless malware with anti-sandbox capabilities. Previously, F5 Labs analyzed IcedID decompression methods for web injecting relevant files into a target list. This is a much deeper attack chain analysis of IcedID and its techniques.

Stage 1: IcedID is Distributed through Microsoft Word Document Email Attachments

In recent attacks, IcedID has been deployed as part of the TA551, or Shathak, email-based malware distribution campaign, often targeting English-speaking victims. The campaign uses lures tied to the COVID-19 pandemic to trick users into opening malicious attachments. Over the past year, F5 Labs has seen that the majority of phishing and fraud attacks have been cloaked in pandemic-related lures.

In the current campaign, IcedID rides in on Microsoft Word documents with a poisoned macro that inserts an installer to install the malware, which is designed to steal users’ credentials, payment card data and other sensitive information from major financial institutions and retailers.

Stage 2: IcedID is Installed and Injected

The malicious Microsoft Word macro download and executes the installer which relocates itself to %APPDATA%\Local\{user}\ or %APPDATA%\Local\{GUID}\ and sets a scheduled task to run every hour or user logon for persistency. Later on the installer tries to download a PNG image from several command-and-control (C&C) domains.

Inside the PNG is an IcedID loader encrypted with RC4 hidden as a legitimate PNG file, a technique called steganography to hide itself from security solutions such as antivirus, malware-detecting sandboxes, and static analysis tools.

The installer transfers control to the RC4-decrypted shellcode that injects itself into other processes by creating a suspended process, writing the shellcode to the process’s memory, setting an asynchronous procedure call (APC) thread to transfer control to the shellcode, and lastly calling NtResumeThread to start the injection.

The injected process is usually msiexec.exe or svchost.exe, as shown in Figure 1. Both are digitally signed by a well-known Microsoft certificate, making it harder to detect.

IcedID APC Injection

IcedID uses part of the process hollowing technique to inject malicious code into suspended processes and to evade process-based defenses. Figure 2 shows this technique’s specific code snippet for IcedID. The suspended legitimate process is either svchost.exe or msiexec.exe, which are known and signed Microsoft processes.

To use this technique, the malware does the following:

1. Creates a process using CreateProcessA with a SUSPENDED flag,
2. Allocates memory using NtAllocateVirtualMemory API,
3. Writes the shellcode to memory using ZwWriteVirtualMemory API,
4. Changes the memory protections using NtProtectVirtualMemory,
5. Creates an APC thread routed to the shellcode
6. With the process still in suspended mode, the technique’s last step is to call NtResumeThread API to resume the process.

Once this is done, the shellcode walks through the process environment block (PEB) structure, comparing a hash against function names retrieved in order to create dynamic resolving (Figure 3 and Figure 4).

To make things harder for antimalware controls and security researchers, this technique dynamically creates an import table with no strings associated with function names in memory. It does so by making use of the PEB, a data structure within the process’ memory to hold information about the current processes. IcedID scans through the PEB, enumerating all the module function names, find the needed functions and store them in variables for later use.

Stage 3: IcedID Sneaks through the System

With the malware fully running in the infected system, it now seeks out targets within the system to ensure it’s in a good place to steal credentials. However, it also needs to continue to resist analysis and evade detection by antivirus software.

IcedID Certificate Store

IcedID creates a tmp file inside the %TEMP% folder (Figure 5), which contains a certificate store used to save all self-signed certificates the malware has generated so it won’t have to regenerate the certificate for every website.

IcedID String Evasion Techniques

IcedID uses string encryption to avoid being detected. String obfuscation is an evasion technique that malware uses to hide malicious activity as well as to make static analysis harder for researchers and automations. A common way to hide strings is to create a hash and compare against a hard coded precalculated hash. IcedID uses this method to find the browser’s file name without using the associated string, which could be detected within the malware, as shown in Figure 6.

Another evasion technique that IcedID uses is to encrypt the malicious strings beforehand and only decrypt them in memory, as shown in Figure 7.

Finally, another common IcedID technique is to hide strings within the stacks. It breaks down the string one character at a time and saves it inside a variable, which is put onto the stack, as shown in Figure 8.

IcedID Anti-debugging and Anti-Sandboxing Techniques

To hide itself from virtual machines, often used to debug or detect malware, IcedID needs to determine if it is running in a sandbox. It does this by first calculating the timing execution of the cpuid instruction by using the read time-stamp counter (RDTSC) to count the number of CPU cycles since reset. It uses SwitchToThread in this function to measure with RDTSC without the context switch fluctuations, as shown in Figure 9. Note that the call to SwitchToThread happens prior to the RDTSC instruction to ensure the measurement happens in the same time slice (without a context switch in the middle of measuring). For a more reliable measure, this is done in a loop 16 times.

With this information, IcedID can check the hypervisor’s brand using cpuid with EAX=0x40000000 and turn on a bit accordingly inside the in_vm variable, as shown in Figure 10.

IcedID Maintains Persistence

To stay persistent on the infected machine, IcedID copies itself to directory %AppData%\Roaming\%username%\ or (in some variants) also copies itself to C:\Users\%username%\AppData\Roaming\[GUID]\. It then creates a task in the Task Scheduler to run the malware upon user logon or every hour, as shown in Figure 11. This ensures IcedID remains running after reboots.