Persist, Brick, Profit -TrickBot Offers New “TrickBoot” UEFI-Focused Functionality
Updated: Oct 8
By AdvIntel & Eclypsium
TrickBot malware now has functionality designed to inspect the UEFI/BIOS firmware of targeted systems. This marks a significant step in the evolution of TrickBot. Firmware level threats carry unique strategic importance for attackers.
It is clear that TrickBot will benefit greatly from including a UEFI level bootkit in their kill chain. They would survive system re-imagining efforts during the recovery phase of a Ryuk or Conti ransomware event, and they would further their ability to semi-permanently brick a device. This provides criminal actors even more leverage during ransom negotiation, and the TrickBot group is already known for being hard-line negotiators.
Given that the TrickBot group AchorDNS malware installation framework has been used by some of the most notorious criminal, Russian, and North Korean actors to target healthcare, finance, telecoms, education, and critical infrastructure, we view this development as critically important to both enterprise risk and national security.
Adversaries leveraging TrickBot now have an automated means to know which of their latest victim hosts are vulnerable to UEFI vulnerabilities, much like they tooled up beginning in 2017 to leverage EternalBlue and EternalRomance vulnerabilities for worming capabilities. Security teams should take action immediately to mitigate this risk.
Collaborative research between Advanced Intelligence (AdvIntel) and Eclypsium has discovered that the notorious TrickBot malware now has functionality designed to inspect the UEFI/BIOS firmware of targeted systems. This new functionality, which we have dubbed “TrickBoot,” makes use of readily available tools to check devices for well-known vulnerabilities that can allow attackers to read, write, or erase the UEFI/BIOS firmware of a device. At the time of writing, our research uncovered TrickBot performing reconnaissance for firmware vulnerabilities. This activity sets the stage for TrickBot operators to perform more active measures such as the installation of firmware implants and backdoors or the destruction (bricking) of a targeted device. It is quite possible that threat actors are already exploiting these vulnerabilities against high-value targets. Similar UEFI-focused threats have gone years before they have been detected. Indeed, this is precisely their value to attackers.
This marks a significant step in the evolution of TrickBot. Firmware level threats carry unique strategic importance for attackers. By implanting malicious code in firmware, attackers can ensure their code is the first to run. Bootkits allow an attacker to control how the operating system is booted or even directly modify the OS to gain complete control over a system and subvert higher-layer security controls. UEFI level implants are the deepest, most powerful, and stealthy form of bootkits. Since firmware is stored on the motherboard as opposed to the system drives, these threats can provide attackers with ongoing persistence even if a system is re-imaged or a hard drive is replaced. Equally impactful, if firmware is used to brick a device, the recovery scenarios are markedly different (and more difficult) than recovery from the traditional file-system encryption that a ransomware campaign like Ryuk, for example, would require.
TrickBot has proven to be one of the most adaptable pieces of malware today, regularly incorporating new functionality to escalate privilege, spread to new devices, and maintain persistence on a host. The addition of UEFI functionality marks an important advance in this ongoing evolution by extending its focus beyond the operating system of the device to lower layers that are often not inspected by security products and researchers.
Given that the TrickBot group toolset has been used by some of the most notorious criminal, Russian, and North Korean actors to target healthcare, finance, telecoms, education, and critical infrastructure, we view this development as critically important to both enterprise risk and national security. Adversaries leveraging TrickBot now have an automated means to know which of their latest victim hosts are vulnerable to UEFI vulnerabilities, much like they tooled up beginning in 2017 to leverage EternalBlue and EternalRomance vulnerabilities for worming capabilities. Security teams should take action immediately to mitigate this risk.
TrickBot Actor Insights
Discovery of New TrickBoot Functionality
Overview of the Boot Process, SPI Controller, and UEFI Firmware
TrickBot Sets It Sights on Firmware
TrickBot is a highly modular trojan that is particularly notable for its ability to gain administrator privileges, spread within a network, and deliver additional malware payloads. Originally identified in 2016, TrickBot was initially focused on stealing financial data and was considered a banking trojan. However, as the malware evolved, attackers quickly found that it was a valuable enabler in all types of malware campaigns. Notably, TrickBot has been widely observed working in conjunction with Emotet to deliver Ryuk ransomware. TrickBot includes several key features that make it valuable for persistent malware campaigns. The tool is able to capture user and admin credentials using Mimikatz and has incorporated UAC bypass techniques to ensure it can run with administrator privileges on an infected host without alerting the user. TrickBot also makes use of the notorious EternalBlue exploit (MS17-010) to spread to additional hosts in the network via SMB. These capabilities make TrickBot an ideal dropper for almost any additional malware payload. By adding the ability to canvas victim devices for specific UEFI/BIOS firmware vulnerabilities, TrickBot actors are able to target specific victims with firmware-level persistence that survives re-imagining or even device bricking capability.
The following graphics show the last two months of active TrickBot infections, peaking at up to 40,000 in a single day. Getting a footprint is not a challenge for TrickBot operators. Determining which victims are high-value targets and persisting in those environments to hit them again later defines a large portion of the TrickBot toolset, and frames the significance of this discovery.
The number of Active TrickBot infections globally based on ISP geolocation. (Image Source: AdvIntel Monitoring).
TrickBot Threat Actor Insights
While TrickBot as a malware toolset has been used by a diverse set of actors, there is one group that drives the majority of its use and is worth providing insights on in the context of this research in order to emphasize how powerful and successful TrickBot-based campaigns are. The group’s alias as we label is “Overdose,” and they are the primary Platform-as-a-Service fraud group behind TrickBot campaigns, namely those that result in Conti and Ryuk ransomware.
The group has made at least $150m since 2018 and recently extracted ~$34m (2,200 BTC) from a single victim. This is the same group behind a spate of attacks on Healthcare victims, including that of UHS. No direct attribution has been made as to their identity, other than they are Russian-speaking and Eastern European. As can be seen in the graphic below, they participate in a number of criminal/fraud-related activities.
TrickBot Enterprise Structure. Source; AdvIntel
Their most common attack chain largely begins via Emotet malspam campaigns, which then loads TrickBot and/or other droppers, and moves to attack tools like PowerShell Empire or Cobalt Strike to accomplish objectives relative to the victim organization under attack.
Often, at the end of the kill-chain, either Conti or Ryuk ransomware is deployed.
The same actor also uses LightBot, which is a set of PowerShell scripts designed to perform reconnaissance on victim networks, hardware, and software, in order to hand-pick which are high-value targets. It is clear that such actors would benefit greatly from including a UEFI level bootkit in their kill chain. They would survive system re-imagining efforts during the recovery phase of a Ryuk or Conti event, and they would further their ability to semi-permanently brick a device. This provides criminal actors even more leverage during ransom negotiation, and the TrickBot group is already known for being hard-line negotiators.
With this module, the TrickBot kill chain is primed with a list of vulnerable targets for firmware-level compromise. The world’s most notorious malware authors can now leverage Emotet to malspam entire regions or verticals and then let TrickBoot tell them where and how to target the UEFI/firmware. Finally, as part of their negotiation tactics, Ryuk and Conti malware operators often offer to remove backdoors in an enterprise if the ransom is paid. Now, these actors can show a victim that they have removed common forms of backdoors like webshells, accounts, remote admin tools, etc., but keep a covert UEFI bootkit on the system to awaken later.
Typical TrickBot Kill Chain. Source: AdvIntel
Discovery of New TrickBoot Functionality
As is often the case with new TrickBot modules, the name “PermaDll” or the original name as “user_platform_check.dll” caught the attention of Advanced Intelligence researchers during the October 2020 discovery of the new TrickBot attack chain. “Perma,” sounding akin to “permanent,” was intriguing enough on its own to want to understand this module’s role in TrickBot’s newest arsenal of loadable modules with the usual TrickBot export modules. Initial analysis pointed to the possibility there might be capabilities related to understanding whether a victim system’s UEFI firmware could be attacked for purposes of persistence or destruction.
A joint collaboration was started with Eclypsium to analyze this module and to put whatever was found into context for defenders. During the initial discovery of this new module on October 19, 2020, the team processed the encoded “permaDll32”. They leveraged a custom-built AES encryption TrickBot module decrypter, which revealed the decoded module that became the subject of this in-depth analysis and discovery.
It took over five years for the industry to discover the use of the Hacking Team’s VectorEDK UEFI implant code in the wild as part of the MosaicRegressor campaign, despite the source code is readily available on GitHub and even documented in its use. Given how active, well-resourced, and capable TrickBot authors are, we wanted to research, analyze, and expose whatever tooling they already have in place in order to allow organizations to prepare effective defenses more rapidly.
The malware module outputs “PCH” queries based on the string slicing obfuscation
The “permaDll” module checks for administrator privileges with the output “Not Admin.”
Overview of the Boot Process, SPI Controller, & UEFI Firmware
The boot process governs how a system and its components are initialized and coordinates the loading of the operating system, making it one of the most fundamentally important aspects of security for any device. The code supporting the boot process is the first code executed on a system and is likewise some of the most privileged code, requiring protection even from privileged operating system (OS) code. If the boot process is compromised, attackers gain control over the OS itself and establish ongoing persistence on the device even if the OS is reinstalled.
The boot process begins in the SPI flash memory chip that is built into the motherboard of the device. The SPI contains the system’s BIOS, or more often, UEFI firmware, which has largely replaced BIOS as the default system firmware in modern systems. This UEFI firmware will control the boot process and ultimately select the appropriate OS bootloader and execute the initial OS code before handing control over to the operating system itself. All requests to the UEFI firmware stored in the SPI flash chip go through the SPI controller, which is part of the Platform Controller Hub (PCH) on Intel platforms. This SPI controller includes access control mechanisms, which can be locked during the boot process in order to prevent unauthorized modification of the UEFI firmware stored in the SPI flash memory chip. Modern systems are intended to enable these BIOS to write protections to prevent the firmware from being modified; however, these protections are often not enabled or misconfigured. If the BIOS is not write-protected, attackers can easily modify the firmware or even delete it completely. More broadly, any time an actor can write to SPI flash, there are a number of extremely useful things that can be accomplished from the attacker’s perspective:
Remotely bricking a device at the firmware level via a typical malware remote connection.
Re-infecting a device that’s just been through a traditional system restore process.
Bypassing significant security controls that ring zero and above operating systems rely upon such as BitLocker, ELAM, Windows 10 Virtual Secure Mode, stealing NTLM creds by bypassing Credential Guard, disabling other endpoint protection controls like A/V, EDR, etc.
Setting up a follow-on attack that targets Intel CSME vulns, some of which require SPI flash access.
Backing out ACM or microcode updates that have patched other CPU or platform vulnerabilities, like Spectre, MDS, etc.
TrickBot Sets It Sights on Firmware
TrickBot has a history of reusing established tools and exploits such as Mimikatz and EternalBlue, and the malware is taking a similar approach to achieving persistence. Specifically, TrickBot uses the RwDrv.sys driver from the popular RWEverything tool in order 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. RWEverything (read-write everything) is a powerful tool that can allow an attacker to write to the firmware on virtually any device component, including the SPI controller that governs the system UEFI/BIOS. This can allow an attacker to write malicious code to the system firmware, ensuring that attacker code executes before the operating system while also hiding the code outside of the system drives. These capabilities have been abused in the past as a way for attackers to maintain persistence in firmware, most notably by the LoJax malware and the Slingshot APT campaign. However, TrickBot marks a significant expansion of these techniques in the wild. Thus far, the TrickBot module 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. These primitives could be used to insert code to maintain persistence, as has been seen previously with the LoJax or MosaicRegressor. Attackers could also simply erase the BIOS region to completely disable the device as part of a destructive attack or ransomware campaign. The possibilities are almost limitless.
If there were a poster-child for a malware toolkit that impacts national security, it would be TrickBot. Used by criminal, Russian, and North Korean actors, it is widely deployed and benefits from the most widespread malspam apparatus of our day: Emotet. In a single day last month alone, 40,000 active, fully compromised devices were observed.
Because it is offered only to the