TrickBot: Ono! New Tricks!

During the past few weeks, my team and I (The Binary Defense Security Operations Center Threat Hunters), have been tracking a TrickBot gtag that has been behaving differently compared to the other TrickBot gtags. In those weeks, we observed differences in its:

• Distribution
• Runtime
• Post-infection

High-level TrickBot Exploitation Flow

TrickBot’s actions in runtime

Let’s look at the history of TrickBot in case you are unfamiliar with it.

A bit about TrickBot

TrickBot is a modular banking trojan that has recently been used by various malware authors to distribute their own payloads. Just as TrickBot was found piggybacking off emotet a few months ago, many malware campaigns (notably Ryuk) have been found to be piggybacking off of TrickBot’s successful campaigns. TrickBot is typically spread through malspam campaigns, using either itself or other malware families like ursniff as the stage 1.

TrickBot uses several different modules, or “plugins”. Once installed on a victim’s computer, TrickBot lies in wait while stealthily gaining user information, like stealing passwords stored in web browsers or other applications. Additionally, TrickBot is able to detect when a user has connected to a banking website and then dynamically inject html files, which allows TrickBot to steal banking credentials without the user’s knowledge. In newer campaigns, TrickBot’s plugins even allow for it to steal cookies, or take control of the computer using the VNC module!

As TrickBot is used by a select few cybercriminal groups, the TrickBot operators needed a way to identify each campaign. TrickBot uses a <gtag> identifier, which is stored in its encrypted config file, and exposed in its web traffic. This gtag is used to identify each campaign from the other. While we have witnessed many different gtags recently, the gtag that we will be focusing on here is the onoXX gtag (currently on ono13).

Distribution

While TrickBot is no stranger to a little bit of filename obfuscation in order to hide itself, the onoXX campaign seems to be partial to the .php extension. Because of this, onoXX samples are easy to identify on urlhaus.org, as they seem to be the only campaign thus far to use .php to hide their files.

However, this behavior in and of itself is not very odd. Where the activity becomes odd is in the hashbusting that is used in the distro in order to change the received hash of each TrickBot loader. @Jroosen of the Cryptolaemus team was the first to notice this activity. As seen in the below image, with each request to download the file (one request was sent 20s from the last), a different hash is received.

The onoXX TrickBot operators appear to have some script running in the background of their distribution websites that appends seemingly random data to the end of the file in order to change the hash received.

Fileless Runtime Behavior

This is really where the activity demonstrated by the onoXX campaign begins to act very strangely. As shown in the first section’s image, TrickBot’s main directory consists of the TrickBot exe, a .ini file (typically called settings.ini), along with a data folder. When the loader downloads the modules, the modules are first saved in the data folder before being injected into a hollowed-out svchost process. This activity occurs for both Windows 7 and Windows 10. However, this changes for the onoXX campaign, at least for Windows 10.

While Windows 7 still behaves relatively the same as in past TrickBot campaigns, onoXX’s Windows 10 samples behave quite differently. Both Windows 7 and Windows 10 share a change in the files dropped in the Main directory. Specifically, the .ini file has been changed to a .txt, with a random name like “readme”. Windows 7 samples seem to run incredibly slowly (~30 mins for full runtime), possibly to evade sandboxes.

Additional behavior noted by the Windows 10 samples indicate that the onoXX operators are attempting to approach TrickBot campaigns with a more fileless mindset, similar to emotet’s module loading. When modules are downloaded on Windows 10, onoXX’s loader does not drop the files into the data folder, but instead, loads them directly into memory.

This type of behavior makes it very difficult during Incident Response to identify which modules are downloaded on the system. The Binary Defense Threat Hunting team has created several YARA rules for each of the modules that easily identify the modules loaded into memory—rules we apply to our client accounts.

Post-infection behavior

The onoXX operators are also demonstrating different post-infection behavior than what is currently observed with other TrickBot gtags. On July 25, 2019, while analyzing an ono10 sample of TrickBot, our team noticed some very interesting behavior. Typically, after gathering all of the system and network information, the TrickBot operators will identify whether or not the computer exists in a corporate environment. This identification comes from information stolen, (e.g., if a domain controller is present), along with other indicators such as the processes running in the background. If a corporate environment is identified, the TrickBot operators will then either load their VNC module, or they will take advantage of any VNC software running in the background that they can access using credentials stolen by the pwgrab module. (credit to @vallabh for this finding). Once VNC connections are established, the operators will then typically drop ransomware like Ryuk. Ryuk is particularly nasty as it has no blacklist for default Windows files. Ryuk bases its ransom off of the size of the company, meaning ransoms are typically $100,000+.

This is not the behavior that we witnessed during our analysis of TrickBot. Our analysis environment was set up to be a fresh Windows 7 instance with no saved passwords or notable software. We then connected it to the internet, ran TrickBot and let it run for approximately 12 hours.

Imagine our surprise when we returned to find these files in our main directory:

These two additional files (win.part1 and win.part2.rar), are the installation file for an XMR cryptominer that mines through minergate. XMR is a cryptocurrency that is favored by cybercriminals due to its near total anonymity with no open ledger, along with the fact that XMR can be mined on a computer using solely CPU, allowing cybercriminals to mask the mining behavior.

Cryptominer analysis and IOCs

The cryptominer itself is actually relatively basic in terms of operations. The two files are actually self-extracting RAR files. The dropped files consist of

• config.json
• control.bat
• control.vbs
• hide.bat
• hide.vbs
• setup.bat
• setup.vbs
• start.cmd
• start.vbs
• system32.exe
• Windows Defender.exe

The above files are dropped in C:ProgramDataWindows. The first two files that run when the sample is launched are hide.vbs and setup.vbs. Both of these files open a Wscript.Shell object and then execute hide.bat and setup.bat, respectively. Hide.bat is tasked with hiding the two installation directories (C:ProgramDataWindows and %appdata%Silent), while setup.bat seems to be more of an installer.

Upon running setup.bat, the malware first adds a registry key with value = “Windows Defender” and path = C:ProgramDataWindowsWindows Defender.exe to the Run key (Software/Microsoft/Windows/CurrentVersion/Run), presenting as the persistence mechanism. Next, setup.bat runs Windows Defender.exe and control.vbs. Finally, it deletes setup.bat, setup.vbs, hide.bat, and hide.vbs.

Control.vbs behaves the same as the other .vbs files and executes control.bat, which as the name would suggest, appears to be the main control script for the cryptominer. This script has a fairly simple runthrough which is as follows:

1. Searches processes for taskmgr, procexp64, and processhacker
2. If found, closes system32.exe
3. If not found, verifies that system32.exe is running
4. If not running, run start.vbs
5. If running, go to step 1

Start.vbs operates identically to the other .vbs files. It executes start.cmd, which runs System32.exe. System32.exe appears to be the miner itself. The configuration information is stored in config.json, and appears to be a mining config, for XMR mining. The following information has been extracted from the config.json:

• url: xmr.pool.minergate.com:45700
• user: [email protected]

That leaves Windows Defender.exe, which is the main control file. This executable is also another self-extracting RAR file, dropping files that we’ve already seen, namely setup.bat, control.vbs, and start.vbs.

IOCs

Cryptominer IOCs:

James is one of the threat hunters on our team. He spends a fair amount of time looking for potential dangers lurking in the digital shadows, studying and reverse engineering malware, and more—all part of helping our clients protect their data, brand, and people every hour of every minute of every day. Check out our site to learn more about how we help enhance cybersecurity for organizations across every industry with our SOC-as-a-Service platform.

Credits:

Flowchart Icons:

https://www.flaticon.com/free-icon/spam_158610

https://www.flaticon.com/free-icon/exe-file_71611

https://www.flaticon.com/free-icon/cloud-internet-symbol_33415

Many thanks to @JRoosen(https://twitter.com/JRoosen) and the rest of the Cryptolaemus team for their help with the hashbusting identification.