By AdvIntel & Eclypsium
Key Takeaways:
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.
Introduction
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.
Contents:
TrickBot Background
TrickBot Actor Insights
Discovery of New TrickBoot Functionality
Overview of the Boot Process, SPI Controller, and UEFI Firmware
TrickBot Sets It Sights on Firmware
Implications
Mitigation
Conclusion
TrickBot Background
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.
Implications
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 most vetted and well-funded actors, it has been forged into what can best be described as an arsenal of capability, integrating powerful exploitation capabilities like EternalBlue and EternalRomance to help it worm through networks and leveraging powershell to perform extremely effective reconnaissance to determine high-value targets. It does this with agility, stealth, and the ability to incorporate specific modules only as needed to accomplish campaign objectives without tipping its hat to defenders. So why is this new TrickBoot capability so impactful? Here are five considerations organizations and government should note:
1. TrickBoot is only one line of code away from being able to brick any device it finds to be vulnerable. UEFI level destruction is more impactful than the run-of-the-mill ransomware tactic of encrypting hard drives. Recovering from a bricked UEFI means replacing the entire motherboard or attempting reflash of the UEFI firmware and is more labor-intensive than simply re-imagining or replacing a hard drive. The national security implications arising from a widespread malware campaign capable of bricking devices is enormous. The TrickBoot module targets all Intel-based systems produced in the last five-plus years. Based on Eclypsium analysis, most of these systems remain vulnerable to one of the multitudes of firmware vulnerabilities currently known, with a smaller proportion susceptible to the particular firmware misconfiguration issue checked for by this module.
2. Historically, TrickBot actors have needed to evade and persist at the operating system level. But this has become a ‘race against time’, as eventually today’s AV and EDR tools catch up to the actor at the OS layer. While some threat actors like the Russian GRU 85th GTsSS have taken to kernel-level rootkits, that vector is generally less feasible on modern devices with Secure Boot enabled. But once UEFI persistence is achieved, TrickBot operators can disable any OS level security controls they want, which then allows them to re-surface to a modified OS with neutered endpoint protections and carry out objectives with unhurried time on their side.
3. Normally an actor wanting to gain UEFI level access needs to plan, customize, and build attack tools to target a specific victim environment. But with TrickBoot, actors can simply ‘land’ on tens of thousands of hosts per day and extract which of them are inside a high-value target organization and vulnerable to UEFI attacks.
4. Actors are going lower in the stack to avoid detection. The same actors (APT28) behind the DNC hack in 2016, also deployed LoJax, a UEFI implant with a similar infection method and use of the same vulnerability this TrickBoot module looks for. The difference here is that TrickBot’s modular automated approach, robust infrastructure, and rapid mass-deployment capabilities bring a new level of scale to this trend. All pieces are now in place for mass-scale destructive or espionage focused campaigns that can target entire verticals or portions of critical infrastructure.
5. 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.
Test Framework & Status Reporting
Because TrickBot uses a modular framework to allow new modules to be developed and deployed to targets, this sample includes some infrastructure code to implement this framework, which is shared with previous samples.
The main function where the module-specific operations start is at 0x1000D663, which we’ll refer to as “permadll32_main_module”. This is the main function for this module, which loads and initializes the RwDrv.sys driver by calling open_or_init_driver, determines the identity of the platform (both CPU and PCH) by calling identify_platform, determines which register locations to use for this platform by calling get_regs_from_generation, checks if the SPI BIOS Region is writable by calling check_spi_protections, and returns the platform identity and if the SPI BIOS Region is writable back to the caller.
Although this module appears only to identify the target hardware and determine if the BIOS region is writable, its code could be easily modified to write to the SPI Flash to implant the system by modifying the firmware or brick the system by erasing the BIOS Region entirely. This could be automated via the use of an additional module to perform the attack after the reconnaissance has been completed by this module or via ‘at-the-keyboard’ manual operations.
Mitigation
Given the popularity of TrickBot in the wild, it is important for security teams to ensure that their devices are not vulnerable and have not been compromised. Firmware integrity checks are particularly important for any device that is known to have been compromised by TrickBot. The following steps can be performed with open-source tools such as CHIPSEC or via the Eclypsium platform.
Check devices to ensure that BIOS write protections are enabled. See how in our Protecting System Firmware Storage blog. Eclypsium customers can specifically look for systems with the “Missing BIOS Write Protection” vulnerability.
Verify firmware integrity by checking firmware hashes against known good versions of firmware. Monitor firmware behavior for any signs of unknown implants or modifications.
Update firmware to mitigate numerous vulnerabilities that have been discovered. See our blog on Firmware Updates for the Enterprise for best practices.
Incident Response (IR) teams performing host-level forensics on devices impacted by TrickBot should examine firmware as part of their playbook in order to ensure eradication and to gain hotwash insight into risks presented by adversaries targeting device firmware in their specific environment.
TrickBoot Indicators of Compromise (IOCs)
permaDll32:
md5:491115422a6b94dc952982e6914adc39
sha1:55803cb9fd62f69293f6de21f18fd82f3e3d1d68
sha256:c1f1bc58456cff7413d7234e348d47a8acfdc9d019ae7a4aba1afc1b3ed55ffapermaDll32 (pre-decryption):
md5:cef670f443d2335f44a1838463ea44ed
sha1:30aa28e6df66fe7b4ec643635df8187ede31db06
sha256:c065e39ce4e90a5a966f76d9798cb5b962d51a3f35e3890f91047acfefa8c58e Note: The TrickBoot module includes an obfuscated copy of RwDrv.sys embedded inside it, but when this file is dropped into the Windows directory, it can be identified with the following IOCs.
Rwdrv.sys
md5:257483d5d8b268d0d679956c7acdf02d
sha1:fbf8b0613a2f7039aeb9fa09bd3b40c8ff49ded2
sha256:ea0b9eecf4ad5ec8c14aec13de7d661e7615018b1a3c65464bf5eca9bbf6ded3YARA Signature
rule crime_win32_perma_uefi_dll : Module {
meta:
author = "@VK_Intel | Advanced Intelligence"
description = "Detects TrickBot module decrypter permaDll"
md5 = "491115422a6b94dc952982e6914adc39"
strings:
$module_cfg = "moduleconfig"
$str_imp_01 = "Start"
$str_imp_02 = "Control"
$str_imp_03 = "FreeBuffer"
$str_imp_04 = "Release"
$module = "user_platform_check.dll"
$intro_routine = { 83 ec 40 8b ?? ?? ?? 53 8b ?? ?? ?? 55 33 ed a3 ?? ?? ?? ?? 8b ?? ?? ??
56 57 89 ?? ?? ?? a3 ?? ?? ?? ?? 39 ?? ?? ?? ?? ?? 75 ?? 8d ?? ?? ?? 89 ?? ?? ?? 50 6a 40 8d ?? ?? ?? ?? ?? 55 e8 ?? ?? ?? ?? 85 c0 78 ?? 8b ?? ?? ?? 85 ff 74 ?? 47 57 e8 ?? ?? ?? ?? 8b f0 59 85 f6 74 ?? 57 6a 00 56 e8 ?? ?? ?? ?? 83 c4 0c eb ??}
condition:
6 of them } Mitre ATT&CK Framework: TrickBoot
Attack Pattern
Spearphishing Attachment - T1193
Scheduled Task - T1053
User Execution - T1204
PowerShell - T1086
Component Firmware - T1109
DLL Search Order Hijacking - T1038
Process Hollowing - T1093
Hooking - T1179
Account Discovery - T1087
Query Registry - T1012
Process Discovery - T1057
System Information Discovery - T1082
Windows Admin Shares - T1077
Automated Collection - T1119
Data from Local System - T1005
Email Collection - T1114
Man in the Browser - T1185
Connection Proxy - T1090
Custom Command and Control Protocol - T1094
Automated Exfiltration - T1020
Data Destruction - T1485
Firmware Corruption - T1495
Persistence, Pre-OS Boot: System Firmware - T1542
Inhibit System Recovery - T1490
System Shutdown/Reboot - T1529Advanced Intelligence is an elite threat prevention firm. We provide our customers with tailored support and access to the proprietary industry-leading “Andariel” Platform to achieve unmatched visibility into botnet breaches, underground and DarkWeb economy and mitigate any existing or emerging threats.
For additional technical information and Indicators of compromise, please see the full report attached as well as the indicators of compromise mapped to Mitre ATT&CK framework in JSON and CSV format.