Introduction

On 03.12.20 Eclypsium published a threat report about a new capability discovered in latest variants of the Trickbot malware family. In their document, we learn that they discovered a new version that contains code allowing to inspect UEFI/BIOS firmware.

From their report, there is no sign that UEFI/BIOS implant is currently used by Trickbot. They later confirmed on Twitter that they did not see such behavior and that their report is to bring awareness on the added capabilities.

The analyzed code is copied from an open-source project that do contain firmware modifications capabilities and as such, could potentially be used in future versions of Trickbot to either brick or persist on the infected host.

The following post is to shed light on UEFI/BIOS implants both in terms of capabilities for an attacker and how to prevent, detect such attacks.

Hacknowledge position

Hacknowledge is constantly working on use-cases to detect previous steps of attacks, from first execution to lateral movements and persistence. Please refer to our portal and contact your Technical Account Manager to enable the use-cases that best fits your environment.

We will work on a use-case to detect the load of RwDrv.sys using either service creation or Sysmon driver loaded event. Keep in mind that this could be bypassed should the attacker uses another driver or a vulnerable one already running on your hosts. As such, we recommend working on preventing those executions in the first place (see Do section below).

Do

• This is the last step for an attacker, focus on blocking and detecting their first steps: initial execution from macros, credentials stuffing from phishing attacks. As such, we recommend to first start with MFA, block RDP access from the internet, vulnerability management and an EDR
• Plan to deploy an allow-listing solution in your environment such as Microsoft AppLocker or Windows Defender Application Control
• Enable and test your SIEM use-cases related to activities conducted during attacks using Trickbot and variants to detect first steps of such an attack
• Apply recommended security configuration and fixes from your hardware vendor to limit the exposition to firmware-based vulnerabilities
• For High value targets, investigate usage of Windows Secure-core PC with added security regarding the hardware and defaults settings for HVCI

Don’t

• Focus on this attack. This is not the most important threat for most organizations

Technical details

Introduction

UEFI/BIOS rootkit (more commonly called bootkit) are known for quite sometimes and have already been in the news, like with the LoJax implant used by the APT28 attack group. Yet for now they have been seen as a technique related to APT groups only even if open-source tools and presentations on the topic allow skilled engineer to develop them.

Here, Trickbot authors continue in their operational methodologies, by leveraging available tools and repurposing them for malicious intent instead of security research and penetration testing (previous example with usage of tools such as mimikatz, bloodhound, cobalt strike, …).

Installation

In order to deploy UEFI/BIOS bootkit, attackers either need physical access in order to flash the SPI chip (where the firmware is stored) or code execution in the kernel, since it runs with privileges allowing to read and write at the memory addresses mapped for the firmware.

In the published report, Trickbot is using a well-known driver, RwDrv.sys which is used to read and write parts of the UEFI firmware. As such, the attacker needs Windows SeLoadDriverPrivilege rights in order to load this driver. This privilege is accessible from accounts in the local administrator group for example.

Another technique could be to leverage vulnerabilities in an already loaded driver in order to inject code in the kernel. This is not a technique mentioned in the published report.

Once the driver is loaded, it can read and write to the memory mapped for the UEFI firmware and inject modules in it.

Capabilities

Attackers would leverage an UEFI/BIOS bootkit for several purposes:

• Brick the device by overwriting the UEFI/BIOS with bogus firmware, rendering the computer unable to boot
• Install an UEFI module that will be run before the main OS and antivirus solutions are loaded. This will allow them to regain persistence and deactivate security measures of the OS and security solutions installed on it

Prevention

Outside of physical security, prevention can also be made from a software point-of-view. The first step is to limit the list of drivers that can be loaded on your hosts. Microsoft provides several features to do so: WHQL to load only certified drivers, HVCI to validate kernel code integrity and WDAG to enforce applications and drivers whitelisting by leveraging virtualization technologies.

At the firmware level, a write protection can be set at the BIOS level. However, this protection is easily disabled if the configuration to lock it is not set. Other protection at the SMM level can also be enabled. Bypass of this level of protection requires exploitation of firmware vulnerabilities in order to flash unsigned code.

Platforms with secure elements (such as Microsoft Secure-cores, Apple devices with T2 chips and Chromebooks) could validate the state of the firmware at boot time and as such alert of compromise, or even reflash with latest known-good version.

Assessment of the current level of security can be done using tools such as CHIPSEC on a development PC or by booting on a live-cd like Linux UEFI validation.

Detection

Physical forensics

For this, you will need to connect directly to the chip after opening the chassis. Firmware programmers could be used for this. Lighter solutions typically used in hardware security research such as Teensy device could also be used.

The extracted firmware and UEFI modules will then have to be analyzed using methods such as:

• comparing files hashes to known good and known bad
• reverse engineering

Software forensics

Tools such as CHIPSEC can be used in order to read the firmware from the kernel. Those tools use drivers like RwDrv.sys used by Trickbot but only to read the content of the memory. This method has drawbacks and can be tampered with by an attacker. There is for example, a timing attack that would allow an attack to send back fake data when the SPI controller is asked to read memory of the SPI chip.

Yet, several EDR solutions and AV (ex: Microsoft Defender, osquery) integrate firmware checking capabilities. In the case of Defender, this is in the built-in version shipped with Windows10. Using Defender for Endpoints allows you to query this data and centralized the related alerts.

Remediation

As for physical vs hardware based forensics, the remediation is clearly dependant on the capabilities of the malicious code that infected your system. Given that you cannot be 100% sure of the threat you are facing with the software approach, using a SPI programmer is the recommended option to restore an infected host. For added fun, note that it is possible to also infect the firmware of other components of your machine to achieve persistence, but lets keep that for another Friday 😉

Sources

• https://eclypsium.com/2020/12/03/trickbot-now-offers-trickboot-persist-brick-profit/
• https://www.blackhat.com/docs/asia-17/materials/asia-17-Matrosov-The-UEFI-Firmware-Rootkits-Myths-And-Reality.pdf
• https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf
• https://attack.mitre.org/software/S0397/
• Rootkits and Bootkits, A. Matrosov, E. Rodionov and S. Bratus, NoStarchPress
• https://2014.ruxcon.org.au/assets/2014/slides/rux-BiosAttackSummary-ruxcon2014.pdf
• https://github.com/chipsec/chipsec
• https://01.org/linux-uefi-validation
• https://www.microsoft.com/security/blog/2020/03/17/secured-core-pcs-a-brief-showcase-of-chip-to-cloud-security-against-kernel-attacks/