TrickBot’s returned, Worse than Before

The botnet called TrickBot and its operators has been a pain in the side of cybersecurity experts for years now. In October, Microsoft announced that the tech giant had partnered with several security firms and internet service providers that it had attempted to cripple TrickBot’s infrastructure. It was hoped that their actions would takedown the botnet often used to spread ransomware. These were high hopes, and the InfoSec community knew that TrickBot would return. Microsoft’s actions were not in vain, as one of the main aims of the partnership was to prevent TrickBot from having an impact on the recent US National Elections. In this, the mission succeeded, but more than a few probably hoped that TrickBot remained hobbled for longer.

Those behind TrickBot were not inclined to admit defeat after their infrastructure had been crippled, the opposite is probably true and several new features have been added recently that make TrickBot a more fearsome opponent than before. Towards the end of November 2020, Bitdefender discovered that the malware had been updated to include improved communications, a new command-and-control infrastructure, and several newly packaged modules.

The packaging of modules has been determined by researchers to be an attempt to clean up TrickBot's ability to spread laterally across networks.

The new command-and-control infrastructure now includes the ability to infect Mikrotik routers and use them to expand the bot network TrickBot relies upon. Bitdefender researchers concluded that,

“Completely dismantling TrickBot has proven more than difficult, and similar operations in the past against popular Trojans has proven that the cybercriminal community will always push to bring back into operation something that’s profitable, versatile and popular. TrickBot might have suffered a serious blow, but its operators seem to be scrambling to bring it back, potentially more resilient and difficult to extirpate than ever before.”

The second update that deserves special mention is the incorporation of new code obfuscation routines. Now TrickBot uses what Microsoft machines were built on, DOS, or disk operating system. While not called that anymore, currently the Command Prompt and PowerShell serve as more up to date command-line tools, to allow for backward compatibility all Microsoft machines still have DOS in some distilled form. Security researcher John Hammond, analyzed how TrickBot had changed for its “100th Version” to abuse cmd.exe to obfuscate the code carrying the malicious payloads.

This is not the first time cmd.exe has been exploited by hackers and such exploitation remains popular. The reason for this is that cmd.exe presents users and hackers with an interface that can be used to run commands, start programs, as well as creating, moving, or deleting files on the system.

Importantly, in the case of TrickBot, the command prompt functionality extends to where it can be automated to run scripts, referred to as batch scripts. In normal day usage, batch scripts are used by developers to improve workflow, but threat actors use them for other purposes. If you have a good antivirus product these simple but malicious text files can be detected, so while they make it easier for threat actors to run malicious programs they can be detected. This is where code obfuscation comes in, which is simply performing actions to make code harder to read, often by including junk characters to hide the actual purpose of the malware.

TrickBot does this by making use of batch scripts. For example, the code that launches TrickBot reads as absolute gibberish but the script allows for the malware to steal data, infect other networked assets, and deploy ransomware further down the infection train. The launch code is turned into gibberish to avoid detection by antivirus suites and once launched it may be too late to stop TrickBot’s infection race from reaching high gear. Commenting on this Hammond noted that humans can sift through the code to remove the junk and see it for what it is a malicious program, but

“The thing is… an automated system like an off-the-shelf EDR product or signature-based anti-virus or detection system won’t know how to do that. The machine won’t see any bad or malicious commands, and perhaps this malware-stager will slide right under the radar! That’s the real point here. This obfuscation technique is one clever trick to mask and cover up the code that could be leveraged to do more damage… and maybe an automated defense tool won’t alert on it.”

TrickBot now Targets Firmware

The above two updates mentioned are interesting and are done with a purpose but the last of the discovered updates is the one that spikes TrickBot’s danger levels. In a joint report published by Advanced Intelligence and Eclypsium, researchers revealed that TrickBot can now interact with an infected computer's BIOS or UEFI firmware. This is scary for several reasons, but it is first necessary to explain why malware that can interact with a computer’s BIOS or UEFI firmware. This type of firmware is closely associated with the boot process of the machine, which in turn coordinates the booting of the operating system. This process is fundamental to the security of any device.

If malware is capable of interacting with the firmware it can do several things and none of them are good including:

• Bricking a device at the firmware level via a remote malware or ransomware campaign.
• Re-infecting a device that’s just been through a traditional system restore process.
• Bypassing or disabling security controls that OS and software rely upon such as virtualization-and container-based security isolation, credentials isolation, software-based full-disk encryption, and other endpoint and identity protection controls.
• Chaining exploitation of other device components such as Intel CSME/AMT firmware or Baseboard Management Controllers.
• Rolling back important firmware and microcode updates patching hardware flaws like CPU transient execution vulnerabilities.

In the case of TrickBot, the malware’s operators have never been shy of using established tools and exploits to get the job done. The malware’s new feature of targeting BIOS or UEFI firmware is no different. TrickBot uses the RwDrv.sys driver from the popular RWEverything tool to interact with the SPI controller to check if the BIOS control register is unlocked and the contents of the BIOS region can be modified. TrickBot includes an obfuscated copy of RwDrv.sys embedded within the malware itself. It drops the driver into the Windows directory, starts the RwDrv service, and then makes DeviceIoControl calls to talk to the hardware.

By being able to do this TrickBot can write malicious code to the firmware which means that malware can be executed before the operating system boots. This is done while still hiding the code from antivirus suites designed to scan the operating system.

The silver lining is that it appears this function of TrickBot is still in development. Currently, the malware is only checking the SPI controller to check if BIOS write protection is enabled or not and has not been seen modifying the firmware itself. However, the malware already contains code to read, write, and erase firmware. While not as full operational capacity, TrickBot being able to interact with the firmware in such a way does have several implications. In the future, TrickBot can brick devices, in other words, make them unusable, this can be done to prevent analysis by researchers and keep TrickBot operations in the dark.

The way TrickBot goes about interacting with the firmware means that the large majority of Intel-based systems produced over the years are vulnerable.

Historically, for TrickBot to remain persistent on an infected device it had to do this at the operating system level. By being able to interact with the firmware, TrickBot can remain persistent within the firmware meaning removing it is far more difficult. Further, the malware is capable of switching off security controls so that it can perform its tasks at an operating system level unabated. Researchers ominously noted,

“Most organizations and missions are not tooled to be able to detect, let alone mitigate, this class of firmware threat. It is precisely for this reason that threat actors push further down the stack. This means that as a nation, neither our proactive or reactive efforts are likely sufficient to get ahead of this new threat. Our hope is that this discovery, research, and recommended mitigations help elevate the awareness needed to address this global threat head-on.”

▼ Show Discussion