17.03.2021

Masters of disguise

Let's hunt some bootkits

Semyon Rogachev

Malware Analyst at Group-IB

Nation state or state-sponsored hacker groups have a long and successful history of using bootkits — special stealthy malicious code for BIOS/UEFI — which can remain undetected for a long time. Bootkits can even survive reinstalling the OS and changing the hard drive. Such attacks are difficult to detect (information security vendors have managed to detect such threats on their own only twice!), which is why there is a growing demand for such an infection method among financially motivated hackers, such as TrickBot operators. Semyon Rogachev, Malware Analyst at Group-IB, explains how to hunt such threats on a local network and build your own test bench with the latest available Mosaic Regressor UEFI bootkit. Bonus material: new network indicators of compromise associated with the Mosaic Regressor infrastructure and protection recommendations in line with MITRE ATT&CK and MITRE Shield.

Let's start with a brief historical overview

2013

In 2013, Sébastien Kaczmarek from QuarksLab created a Dreamboot PoC bootkit that uses UEFI to attack the OS bootloader. Its source code is available on GitHub. It should be mentioned that this bootkit worked only when the Secure Boot mechanism was disabled. Later, at the BlackHat USA 2013 conference, the "A Tale of One Software Bypass of Windows 8 Secure Boot" report was presented. The authors described the first public way to bypass this mechanism.

2014

In 2014, Rafal Wojtczuk and Corey Kallenberg published information about the Darth Venamis vulnerability in the S3 Resume mechanism. Computers use this mechanism to continue operating after waking up from sleep mode. The research revealed that the memory area that stores S3 BootScript (a list of commands that initialize devices after waking up from sleep mode) is not protected from modification, which leads to various vulnerabilities. The CIA is believed to have used the same vulnerability to install implants. Further information is available here, here and here.

2015

In 2015, Corey Kallenberg and another researcher, Xeno Kovah, presented LightEater, a rootkit that allows to obtain critical data (encryption keys, etc.) through direct access to physical memory and page-by-page searches using signatures.

In the same year, after a data leak from HackingTeam, the Vector-EDK framework was discovered. The malware was designed to inject implants in UEFI-based firmware. The framework was used to develop Mosaic Regressor.

2016

In 2016, Dmytro Oleksiuk developed PeiBackdoor, the first publicly available UEFI rootkit that is loaded at the PEI (Pre-EFI Initialization) stage.

In the same year, the leak of Equation Group documents (allegedly associated with the US NSA) revealed the existence of the BANANABALLOT BIOS module, which deploys a certain implant to interact with CISCO routers.

2017

In 2017, WikiLeaks published information about DerStarke, the UEFI version of the Triton backdoor for macOS.

2018

In 2018, ESET detected and analyzed the LoJax UEFI rootkit, the first UEFI bootkit discovered by information security companies in the wild.

2020

In October 2020, while investigating an attack, Kaspersky Lab discovered Mosaic Regressor, a UEFI bootkit created using tools obtained from the HackingTeam data leak.

In December 2020, a new version of TrickBot was discovered. One if its features was embedding UEFI code. There is currently no evidence confirming that TrickBot implemented UEFI-implants in the wild, but the fact that such a feature even exists suggests that threat actors are interested in such attacks.

Vector-EDK framework was designed to inject implants in UEFI-based firmware. The framework was used to develop Mosaic Regressor.

Even the above incomplete list shows how relevant and dangerous UEFI-related attacks are. In recent years, the number of publicly disclosed vulnerabilities in firmware has been doubling annually. As a result, cybercriminals become more interested and there are more targeted attacks.

Development of a UEFI bootkit bench

Mosaic Regressor includes several modules, which are described in the table below.

To create a test bench, we will infect the firmware of the QEMU virtual machine. This virtual machine uses the Open Virtual Machine Firmware to emulate the firmware. Firmware is stored in the OVMF_CODE.fd file.

Therefore, to modify the virtual machine firmware, it is necessary to change the OVMF_CODE.fd file. To do this, we use the cross-platform open-source utility UEFITool. It helps analyze the firmware, extract modules from it, and more.

To infect the firmware, two DXE drivers and two UEFI applications must be added to it. First, it is necessary to find the section that contains all the DXE drivers used (in this case, it is the section with GUID 8C8CE578-8A3D-4F1C-9935-896185C32DD3 in FFSv2 format):

Before writing, each of the existing EFI files must be presented as an FFS (Firmware File System) file. Each file in FFS format consists of sections (two sections for each file in this case). The first section contains the executable code, the second one contains the name of the module in a human-readable form. All drivers are assembled to EFI_FV_FILETYPE_DRIVER files. All applications are assembled to EFI_FV_FILETYPE_APPLICATION files. For assembling, the EDK II GenSec and GenFfs utilities are used (available in the EDK II repository).
Creating a section with code:


GenSec.exe -o pe32.sec .\Ntfs.efi -S EFI_SECTION_PE32

Creating a section with a name:


GenSec.exe -o name.sec -S EFI_SECTION_USER_INTERFACE -n "NTFS"

Creating a file in FFS format from the sections:


GenFfs -g "F50258A9-2F4D-4DE9-86AE-BDA84D07A41C" -o ntfs_driver.ffs -i pe32.sec -i name.sec -t EFI_FV_FILETYPE_DRIVER

When creating a section with a name, it is necessary to change the file name passed after the -n argument. When creating a section with a code, the path to the EFI file should be changed (e.g., — .\Ntfs.efi).

When creating FFS files, it is necessary to change the GUID (-g argument), the created file type (the -t argument must be EFI_FV_FILETYPE_DRIVER for drivers and EFI_FV_FILETYPE_APPLICATION for applications), and the name of the output file (-o argument).

As a result, four files in FFS format are obtained, which can be added to the firmware using UEFITool. When adding, it is necessary to make sure that the section has enough free space. The modified firmware should look something like this:

After replacing the firmware file and launching the virtual machine, Mosaic Regressor starts to create files; this process indicates that the firmware has been successfully modified. These files are %WINDIR%\setupinf.log and %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup\IntelUpdate.exe. The first one is an indicator of compromise (the IntelUpdate.exe file will be created only if the setupinf.log file does not exist), the second file downloads the payload from the server:

Even though in this case a virtual machine was infected, this technique can be used by the attackers to infect computers with incorrect configurations and ensure that the malware is launched.

Hunting down Mosaic Regressor

There are several ways to detect Mosaic Regressor:

Search for indicators in the firmware or compare to the UEFI reference image
Search for indicators at the OS level
Analyze network activity

Let's take a closer look at each method.

Search for indicators in the firmware

After analyzing the EFI file SmmReset, a firmware compromise indicator was obtained. This executable creates an NVRAM variable named "fTA". A variable with the same name and functionality was used in rkloader developed by HackingTeam, so searching for this indicator makes it possible to find Mosaic Regressor, rkloader, and other bootkits based on rkloader.

The multifunctional Chipsec utility distributed and supported by Intel can be used to detect this and other indicators of compromise. The utility carries out firmware security testing, obtains firmware dumps, and much more. The Chipsec utility can also be executed from the OS or after booting into the UEFI Shell. In this case, the second option was chosen. To create a bootable flash drive to launch the Chipsec, the following steps should be followed:

Format the flash drive to the FAT-32 file system.
Save the UEFI Shell that will be executed after the computer boots on the flash drive. To do this, download UEFI Shell and save it to /efi/boot as "Bootx64.efi".
Download Chipsec repository.
Extract the content of _instal_/UEFI/chipsec_uefi_x64.zip to the flash drive root directory.
Copy the remaining contents of the repository to the flash drive's root directory.

After booting into the UEFI Shell, the mount command is executed, which shows a list of available devices. In this case, the flash drive is designated as FS0 (which is clear from the "USB" inscription in the device description):

After accessing the Chipsec directory, the python chipsec_util.py uefi var-find fTA command can be used to check whether there is a variable with this name in the firmware. If so, its dump will be saved to a file:

If a more in-depth analysis of the firmware is required, Chipsec makes it possible to obtain its dump. To do this, one needs to execute the following command: python chipsec_util.py spi dump rom.bin

The aforementioned UEFITool can be used to open the received dump and extract suspicious modules, for example.

If there is a reference firmware image, Chipsec makes it possible to use it to detect firmware modifications. To do so, a list of reference image modules must be generated using the python command python chipsec_main.py -i -m tools.uefi.scan_image -a generate,list_of_variables.json,firmware.bin, where list_of_variables.json is the file to which the execution result will be saved. In this case, firmware.bin is a reference firmware dump.

After receiving data about the reference image, comparisons can be made using python chipsec_main.py -i -m tools.uefi.scan_image -a check,list_of_variables.json,suspected_firmware.bin, where suspected_firmware.bin is the name of the dump file of the tested firmware.

As mentioned above, the Chipsec utility can be used from the OS. To do so, the Chipsec driver must be installed and the .py files must be run using the Python interpreter. This way, firmware images can be collected automatically for further analysis.

Search for indicators at the OS level

This section describes how to detect an infection with Mosaic Regressor firmware at the operating system level. After booting the operating system, the Mosaic Regressor payload (IntelUpdate.exe file) behaves like common malware. It can be detected using data obtained by analyzing EFI files, the hash of the file saved in %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup, its name, and other indicators. It should be mentioned, however, that the search for the file creation event will not be successful because the file is created before the OS is loaded, which means that the event will not be detected using EDR or similar solutions (the only option to detect this kind of file creation seems to save information about the file system state before shutting down or hibernating the computer and comparing the saved state with the state after booting the OS).

A similar situation occurs with file %WINDIR%\setupinf.log, which is used by Mosaic Regressor as an additional indicator of compromise along with the UEFI variable. The IntelUpdate.exe file will only be saved if the setupinf.log file does not exist.

Using the following query in Huntbox, it is possible to find traces of the payload launch, which was saved by the Mosaic Regressor EFI module:


event_type: "Process creation" AND Payload.CommandLine: "Microsoft\Windows\Start Menu\Programs\Startup\IntelUpdate.exe"

The IntelUpdate.exe file is created with unmodified time attributes, so if an autorun file is launched without creating respective events, it is a good reason to continue investigating.

All files created at startup should be checked in sandboxes or malware detonation platforms. In our case, Huntpoint sends files for analysis to Polygon, which identifies those that are malicious. As a result, the launch of such files is blocked on all hosts.

Using a combination of EDR and Malware Detonation systems is quite a universal solution, but it is not always possible to install clients at all workstations. In such cases, analyzing network traffic for connections using known malicious hosts may help.

By doing so, it is possible to check whether there are network connections to the server that is sending the payload:


event_type: "Network connection opening"  AND Payload.RemoteAddress: "103.56.115.69"


dns_query: "myfirewall.org"

High-quality indicators are required to make detecting such threats in the traffic more effective. For this purpose, Group-IB created Threat Hunting Framework allowing for external threat hunting, which helps identify similar adversary infrastructure by analyzing known malicious hosts. All newly detected hosts are automatically converted into rules for detecting such threats in network traffic. An extended list of network indicators is provided at end of the "Indicators" section.

Potential attack vectors

There are three scenarios involving a UEFI infection:

Remote infection
Infection with physical access
Infection via supply chain

To carry out a remote infection, attackers must gain elevated privileges to install a payload that will be run at the OS kernel level. After that, they must exploit the SMM vulnerability. This will make it possible to execute the code in SMM mode, thereby bypassing various firmware protection mechanisms (Flash Write Protection) and gaining direct access to the firmware memory.

In case of infections involving physical access, attackers can exploit errors in the UEFI configuration or the firmware update mechanism.

If the supply chain becomes infected, the criminals can add their own implant to the firmware or update it and bypass existing protection methods. For such attacks, it is necessary to compromise the manufacturer and gain access to the firmware source codes, for example.

Chipsec can also be used for basic UEFI configuration check or to scan for vulnerabilities. To do this, the main module must be run using the python command python chipsec_main.py, which will run various security checks, such as a check to overwrite protection.

It should be noted that successfully passing this test does not mean that your system is not infected since Chipsec provides only a basic set of security checks. However, failing the test means that the latest UEFI updates must be installed or the reason why the firmware's basic security mechanisms are violated must be found.

Conclusion

UEFI threats are among the most serious, and the security industry is just beginning to adjust its solutions to make detecting these threats more effective.

You shouldn't wait for a silver bullet or rely on built-in mechanisms to load the operating system safely and with confidence. To protect infrastructure and effectively hunt such threats, cyber threat intelligence data must be used. In addition to commercial products that implement countermeasures, it is possible to use free tools such as Chipsec, which allows for greater possibilities of hunting by indicator and helps check whether the UEFI configuration is correct.

Indicators: UEFI modules

Indicators: Hash

9F13636D5861066835ED5A79819AAC28

FA0A874926453E452E3B6CED045D2206

72C514C0B96E3A31F6F1A85D8F28403C

0D386EBBA1CCF1758A19FB0B25451AFE

B53880397D331C6FE3493A9EF81CD76E

7B213A6CE7AB30A62E84D81D455B4DEA

A69205984849744C39CFB421D8E97B1F

08ECD8068617C86D7E3A3E810B106DCE

89527F932188BD73572E2974F4344D46

9E182D30B070BB14A8922CFF4837B94D

61B4E0B1F14D93D7B176981964388291

7908B9935479081A6E0F681CCEF2FDD9

3D2835C35BA789BD86620F98CBFBF08B

1732357D3A0081A87D56EE1AE8B4D205

233B300A58D5236C355AFD373DABC48B

36B51D2C0D8F48A7DC834F4B9E477238

DC14EE862DDA3BCC0D2445FDCB3EE5AE

0EFB785C75C3030C438698C77F6E960E

1C5377A54CBAA1B86279F63EE226B1DF

328AD6468F6EDB80B3ABF97AC39A0721

AE66ED2276336668E793B167B6950040

E2F4914E38BB632E975CFF14C39D8DCD

C63D3C25ABD49EE131004E6401AF856C

12B5FED367DB92475B071B6D622E44CD

B23E1FE87AE049F46180091D643C0201

7C3C4C4E7273C10DBBAB628F6B2336D8

3B58E122D9E17121416B146DAAB4DB9D

70DEF87D180616406E010051ED773749

88750B4A3C5E80FD82CF0DD534903FC0

D273CD2B96E78DEF437D9C1E37155E00

3B3BC0A2772641D2FC2E7CBC6DDA33EC

AFC09DEB7B205EADAE4268F954444984

6E949601EBDD5D50707C0AF7D3F3C7A5

92F6C00DA977110200B5A3359F5E1462

D197648A3FB0D8FF6318DB922552E49E

74DB88B890054259D2F16FF22C79144D

449BE89F939F5F909734C0E74A0B9751

67CF741E627986E97293A8F38DE492A7

CFB072D1B50425FF162F02846ED263F9

Indicators: File paths

%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup \IntelUpdate.exe

%TEMP%\RepairC.dll

%APPDATA%\Microsoft\Windows\SendTo\load.dll

%APPDATA%\Microsoft\Windows\load.rem

%APPDATA%\Microsoft\Internet Explorer\FileD.dll

%TEMP%\wrtreg_32.dll

%APPDATA%\Microsoft\Internet Explorer\FileOutA.dat

%APPDATA%\Microsoft\Internet Explorer\%Computername%.dat

%COMMON_APPDATA%\Microsoft\Windows\user.rem

%TEMP%\RepairB.dll

%APPDATA%\sdfcvb.dll

%TEMP%\RepairA.dll

%APPDATA%\Microsoft\subst.tbl

%appdata%\return.exe

%APPDATA%\Microsoft\Windows\SendTo\cryptui.sep

%appdata%\dwhost.exe

%appdata%\msreg.exe

%APPDATA%\newplgs.dll

%APPDATA%\Microsoft\Windows\LnkClass.dat

%APPDATA%\Microsoft\Internet Explorer\FileB.dll

%APPDATA%\rfvtgb.dll

%APPDATA%\Microsoft\Network\DFileC.dll

%APPDATA%\Microsoft\Internet Explorer\FileA.dll

%APPDATA%\Microsoft\exitUI.rs

%APPDATA%\Microsoft\Network\subst.sep

%APPDATA%\Microsoft\Network\DFileD.dll

%TEMP%\BeFileA.dll

%APPDATA%\Microsoft\Network\DFileA.dll

%APPDATA%\Microsoft\sppsvc.tbl

%APPDATA%\msreg.dll

%TEMP%\wrtreg_64.dll

%APPDATA%\Microsoft\Internet Explorer\FileC.dll

%APPDATA%\Microsoft\WebC.dll

%appdata%\winword.exe

%APPDATA%\Microsoft\Windows\mapisp.dll

%APPDATA%\Microsoft\WebB.dll

%APPDATA%\Microsoft\WebA.dll

%APPDATA%\Microsoft\Credentials\MSI36C2.dat

%TEMP%\BeFileC.dll

%TEMP%\RepairD.dll

Indicators: Mutex

set instance state

single UI

Office Module

foregrounduu state

process attach Module

Indicators: Network indicators

MITRE ATT&CK и MITRE Shield