Attack Campaign
March 04, 2021

IcedID Banking Trojan Uses COVID-19 Pandemic to Lure New Victims

article
6 min. read
App Tiers Affected:
Client
Services
Access
TLS
DNS
Network

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.

Figure 1. IcedID process tree in runtime.
Figure 1. IcedID process tree in runtime.

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.

Figure 2. Code injection technique and its functions.
Figure 2. Code injection technique and its functions.

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

Figure 3. Code snippet: IcedID scans the process environment block to find modules by encrypted hash.
Figure 3. Code snippet: IcedID scans the process environment block to find modules by encrypted hash.
Figure 4. Second code snippet: IcedID scans the process environment block to find modules by encrypted hash.
Figure 4. Second code snippet: IcedID scans the process environment block to find modules by encrypted hash.

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.

Figure 5. IcedID generates code to create a certificate store.
Figure 5. IcedID generates code to create a certificate store.

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.

Figure 6. IcedID uses string encryption to create a hash and avoid being detected.
Figure 6. IcedID uses string encryption to create a hash and avoid being detected.

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

Figure 7. IcedID technique that encrypts malicious strings and decrypts them in memory.
Figure 7. IcedID technique that encrypts malicious strings and decrypts them in memory.

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.

Figure 8. IcedID hiding strings in the stacks.
Figure 8. IcedID hiding strings in the stacks.

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.

Figure 9. IcedID using the SwitchToThread anti-sandboxing technique.
Figure 9. IcedID using the SwitchToThread anti-sandboxing technique.

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.

Figure 10. IcedID checking the hypervisor’s brand using cpuid.
Figure 10. IcedID checking the hypervisor’s brand using cpuid.

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.

Figure 11. IcedID setting up a malicious task in the Task Scheduler.
Figure 11. IcedID setting up a malicious task in the Task Scheduler.
App Tiers Affected:
Client
Services
Access
TLS
DNS
Network

Mitigation

One of the biggest threats to user systems is, and has always been, malware. Trojan horses such as IcedID are part of large and thriving ecosystem of international cybercrime. It’s a safe bet that malware will continue to plague us for years to come. Meanwhile, security researchers continue to work hard to seek out, analyze, and design defenses against these menaces. Users should always be wary of emails with attachments, especially Microsoft Office documents.

Technical
Preventative
  • Implement web fraud protection to detect customers logging into your applications with infected clients or stolen credentials.
  • Filter and monitor email for phishing and malware attacks, watching for inbound executables and macro-enabled attachments.
  • Reduce and restrict full administrative privileges. Segregate administrative accounts from system administrators and from the user accounts they use to read email and surf the web.
  • Security solution agent
Administrative
Corrective
  • Notify users and customers of the malware detected on their system while logging into your application (which can mean blocking them from carrying out a transaction), so they can take steps to clean their systems.
Administrative
Preventative
  • Provide security awareness training to employees and customers.
  • Advise users and customers to disable macros in their Microsoft Office applications.

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.