Blog Droppers, Downloaders and TrickBot: Detecting a Stealthy COVID-19-themed Campaign using Toolmarks

October 8, 2020 Category: Threat Research By: Alex Holland Comments: 0

Droppers, Downloaders and TrickBot: Detecting a Stealthy COVID-19-themed Campaign using Toolmarks


One of the doctrines of forensic science is Locard’s exchange principle that every action taken by the perpetrator of a crime leaves a trace.[1] Through the process of carefully collecting and interpreting these traces, an investigator can characterise what happened and form hypotheses about other aspects of the crime, such as the capabilities of the perpetrator. This idea holds for digital forensic investigations just as much as it does in a physical crime scene. Cybercrimes involving malware require threat actors to use defence evasion techniques to circumvent security controls in the target’s network to achieve their objectives.[2] The good news for network defenders is that these techniques often involve manipulating files, which leave traces or “toolmarks” that can be used as signs of malicious intent or to track specific threat actors.[3] In this article, we describe how a stealthy TrickBot campaign in September 2020 masquerading as COVID-19 alerts and invoices evaded detection by encrypting, modifying and embedding payloads in files.


TrickBot Operators Toy with Droppers, July 2020

In July 2020, we saw an unusual spam campaign delivering TrickBot banking malware. The configuration data used by every TrickBot binary contains an identifier called a gtag, which represents the campaign or distribution method used to deliver the malware.[4] In that campaign, TrickBot executables using the gtag “end4” were embedded in Microsoft Word document attachments.[5] This differed from the delivery mechanism usually favoured by TrickBot’s operators, where a downloader retrieves and executes the payload from a remote server. Over the last two years, we’ve seen variations of this, commonly involving obfuscated Visual Basic for Applications (VBA) macros. TrickBot has also been delivered using Ostap, a JScript downloader, and through systems that have been infected with Emotet.[6]

First seen in 2014, TrickBot is a modular banking Trojan thought to be operated from Russia.[7] It has extensive capabilities for making fraudulent transactions through web injections and stealing banking credentials. However, since June 2019 it has also been used as a platform to distribute post-exploitation tools and Ryuk ransomware, particularly against large enterprises.[8]

Why Attackers Choose Droppers

Droppers offer several benefits to attackers over downloaders, which may be factors why we are seeing an increase in their use.

No need to host malware externally

Since the payload is embedded in a file, there is no need to host it externally. This saves the time and cost associated with obtaining and managing web infrastructure for hosting the payloads. Attackers don’t need to purchase web servers from bulletproof hosting providers or compromise legitimate web servers.

Reduces detection exposure

Embedding the payload in a document also reduces the chance of the malware being detected by security controls that inspect network traffic for malicious activity, such as web proxies and network intrusion detection or prevention systems. This places extra reliance on email gateways to block malicious attachments. These controls tend to be less effective at blocking command and control (C2) traffic, especially where C2 servers are rotated regularly, as is the case with TrickBot. Web servers used for hosting malware tend to be active for longer periods of time, which means they are more likely to be blocked.

Immune to takedowns

Droppers cannot be taken down by network defenders. With downloaders, the web servers used to host the payloads are vulnerable to takedown action through abuse reports to hosting providers and domain registrars. Takedowns are particularly effective at disrupting the operations of threat actors with small hosting infrastructures. Large hosting infrastructures tend to be more resilient to takedowns. This becomes clear if we examine a malware distribution network using network analysis, a way of analysing entities (in this case, web servers, downloaders and payloads) that shows the type of relationship that exists between them.[9]

If a threat actor only has a few web servers, the number of ties each hosting node will have to the downloaders used in a campaign will be high. This would mean that each node used for hosting has high degree centrality in the distribution network. These web servers represent “choke points” that would severely limit the distribution of the malware if they were taken offline. Conversely, a distribution network consisting of many web servers is more resilient to takedowns because each hosting node has fewer ties. Therefore, an attacker might decide to use droppers instead of downloaders if they lack hosting capacity.

Figure 1 – A TrickBot campaign from July-August 2019 that used Ostap as a downloader. Removing the two yellow nodes with the most edges would significantly reduce the number of infections.

Denies defenders network artefacts

Droppers also deny defenders network indicators of compromise (IOCs) associated with the initial download and execution of the malware. Web server configurations, DNS and WHOIS records and other network artefacts are a valuable source of information for tracking the activities of threat groups over time and across campaigns.

Dropper Disadvantages

Worse targeting and operational security (OPSEC)

One area where downloaders are better than droppers is OPSEC. Downloaders allow threat actors to choose targets selectively based on their IP address (geofencing), user agent and other client information exposed to the web server hosting the malware. They also enable attackers to switch payloads in and out at will, reducing the window of opportunity for researchers and defenders to download and analyse the malware. However, these OPSEC benefits are generally considered less important to operators of massively deployed malware families, such as TrickBot.

TrickBot Malspam Campaign, September 2020

COVID-19 and Invoice Lures

Starting on 16 September 2020, we detected a high-volume TrickBot spam campaign that used the gtag “ono76”, where the Trojan was embedded in hundreds of encrypted DOCM attachments masquerading as COVID-19 alerts and invoices.

Figure 2 – Fake invoice lure used in the TrickBot campaign from September 2020.

Low Detection Rates

Unlike the documents used in the July campaign that had relatively high detection rates (30/61) on VirusTotal,[5] the files in this campaign were more effective at evading detection. 70% of the samples were detected by four or fewer scanning engines, and several files received zero detections (Figures 3 and 4).

Figure 3 – A TrickBot sample that evaded detection, September 2020.

Figure 4 – Low detection rates of TrickBot samples, September 2020.

TrickBot Dropper Toolmarks

Document encryption

These low detection rates were primarily caused by the documents being encrypted using Microsoft Word’s “Encrypt with Password” feature. In this case, the documents’ content and extended metadata were encrypted using AES in CBC mode with a 256-bit key. The emails containing the malicious attachments referenced the password so that recipients would be able to decrypt and open the documents. The most common passwords we found in this campaign were five characters long (e.g. “DLW16”), matching the regular expression [A-Z]{3}\d{2}. Without the password, static and behavioural engines are unable to inspect the contents of the files. This technique also slows down investigations if the document password is not known.

One of the side effects of encrypting a DOCM file using Word’s built-in encryption feature is that tools like file and exiftool will fail to parse the document’s metadata fully. For example, here’s the output of the file command for one of the documents from this campaign:

CDF V2 Document, corrupt: Cannot read summary info

When combined with VirusTotal’s “magic” file search modifier, this output becomes a useful way of identifying encrypted Office documents.[10] For example:

magic:"CDF V2 Document, corrupt: Cannot read summary info"

Similarly, exiftool normally parses extensive document metadata, such as its creation date, creator and information about the version and locale of Microsoft Office used. Since the droppers in this campaign stored a long VBScript in the body of the documents (Figure 6), the very high word count (>10,000) usually would be shown by exiftool. However, this metadata is inaccessible because of the encryption. Therefore, the limited output from exiftool can be used as a sign of encryption or that metadata has been removed, which may prompt an analyst to investigate further.

Unusual byte modifications

We often see threat actors create a handful of malicious documents as templates and then programmatically modify them without changing the payload or download logic.[11][12]  These slight modifications are typically done to evade hash-based detection since each document will generate a unique hash value as a result of the change. In this campaign, we found over 400 documents that were identical except for two bytes that had been modified with the following values:

Original ValueNew Value


Using these file artefacts, we were able to write a YARA rule to detect TrickBot dropper documents distributed in this campaign with high confidence, even though the contents of the files were encrypted.

Figure 5 – A toolmark left in a TrickBot dropper document from September 2020. Two bytes in the bottom document were modified with 0xE2E2.

Execution Chain

All the documents contained an AutoOpen macro that copies a VBScript stored behind the lure image, which is then written to a file in C:\ProgramData with a .VBE (VBScript Encoded File) file extension.

Figure 6 – VBScript containing an encoded TrickBot payload hidden behind the lure image, September 2020.

Figure 7 – VBE file dropped to C:\ProgramData.

We identified two ways that the VBA macro executes the TrickBot DLL payload. In the first method, the macro creates and runs a scheduled task named “Windows Defender” with the start time set to the system date and time returned by VBA’s Second, Minute, Hour, Day, Month and Year functions. The trigger event runs the VBE file using WScript.exe (Windows Script Host), the default VBE file handler. The other variant creates a WshShell object to run the VBE file, which also opens it with WScript.exe.

Figure 8 – Execution of the dropped VBE file using a scheduled task.

Figure 9 – Execution of the dropped VBE file using a WshShell object.

The VBE file contains junk code and the TrickBot payload, stored either as hexadecimal values (Figure 10) or Base64 encoded. The script creates a directory in C: and then writes the payload there with a .DLL extension.