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.
Bootkits 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.
| Module name | GUID | Module type | Description |
|---|---|---|---|
| SmmInterfaceBase | F50258A9-2F4D-4DA9-861E-BDA84D07A44C | DXE-driver | Driver that executes the SmmAccessSub application before execution of the OS bootloader (after receiving EFI_EVENT_GROUP_READY_TO_BOOT) |
| Ntfs | F50258A9-2F4D-4DE9-86AE-BDA84D07A41C | DXE-driver | Driver for interacting with NTFS file systems |
| SmmReset | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0C | EFI-application | Application that creates an indicator of firmware infection – UEFI variable “fTA” |
| SmmAccessSub | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0B | EFI-application | Application that saves the IntelUpdate.exe file (malicious payload) to %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup directory |
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 Managed XDR 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
| Module name | GUID | MD5 РЕ from section EFI_SECTION_PE32 |
|---|---|---|
| SmmInterfaceBase | F50258A9-2F4D-4DA9-861E-BDA84D07A44C | F5B320F7E87CC6F9D02E28350BB87DE6 |
| Ntfs | F50258A9-2F4D-4DE9-86AE-BDA84D07A41C | DD8D3718197A10097CD72A94ED223238 |
| SmmReset | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0C | 91A473D3711C28C3C563284DFAFE926B |
| SmmAccessSub | EAEA9AEC-C9C1-46E2-9D52-432AD25A9B0B | 0C136186858FD36080A7066657DE81F5 |
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
%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
set instance state
single UI
Office Module
foregrounduu state
process attach Module
Indicators: Network indicators
| Known indicators | Extra indicators provided by Group-IB External Threat Hunting | |||
|---|---|---|---|---|
| menjitghyukl.myfirewall[.]org | 103[.]215[.]80[.]1 | |||
| 103[.]39[.]109[.]252 | 103[.]229[.]126[.]101 | |||
| 117[.]18[.]4[.]6 | 103[.]229[.]126[.]246 | |||
| 103[.]229[.]1[.]26 | 103[.]39[.]109[.]231 | |||
| 43[.]252[.]228[.]252 | 103[.]56[.]113[.]61 | |||
| 103[.]82[.]52[.]18 | 103[.]96[.]72[.]148 | |||
| 103[.]195[.]150[.]106 | 103[.]96[.]74[.]144 | |||
| 43[.]252[.]230[.]180 | 122[.]10[.]82[.]30 | |||
| 43[.]252[.]228[.]179 | 144[.]48[.]240[.]101 | |||
| 144[.]48[.]241[.]32 | 144[.]48[.]240[.]145 | |||
| 43[.]252[.]228[.]84 | 185[.]216[.]117[.]91 | |||
| 150[.]129[.]81[.]21 | 212[.]64[.]6[.]161 | |||
| 43[.]252[.]228[.]75 | 216[.]241[.]155[.]120 | |||
| 103[.]30[.]40[.]116 | 43[.]224[.]248[.]143 | |||
| 103[.]39[.]109[.]239 | 43[.]251[.]17[.]187 | |||
| 103[.]243[.]26[.]211 | 43[.]252[.]229[.]32 | |||
| 103[.]56[.]115[.]69 | 43[.]252[.]229[.]33 | |||
| 103[.]39[.]110[.]193 | 43[.]252[.]230[.]146 | |||
| 103[.]243[.]24[.]171 | 43[.]252[.]231[.]135 | |||
| 103[.]30[.]40[.]39 | 45[.]116[.]78[.]238 | |||
| 144[.]48[.]241[.]167 | 45[.]116[.]79[.]186 | 45[.]64[.]75[.]178 | 52[.]174[.]139[.]136 | 69[.]6[.]23[.]85 |
MITRE ATT&CK и MITRE Shield
| Tactics | Technique | Description | Counter- and protection measures | Group-IB security solutions against such threats |
|---|---|---|---|---|
| Persistence/ Defense Evasion | T1542.001 – Pre-OS Boot: System Firmware | Modules SmmInterfaceBase, Ntfs, SmmReset and SmmAccessSub are part of UEFI. The modules are loaded before the Os boot | M1046 – Boot Integrity M1026 – Privileged Account Management M1051 – Update Software | |
| Persistence | T1547.001 – Registry Run Keys / Startup Folder | File IntelUpdate.exe is saved to %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup by SmmAccessSub EFI application | Managed XDR | |
| Execution | T1559.001 – Inter-Process Communication: Component Object Model | File IntelUpdate.exe uses COM-libraries | M1048 – Application Isolation and Sandboxing M1026 – Privileged Account Management | Managed XDR |
| Defense Evasion | T1197 – BITS Jobs | Mosaic Regressor uses BITS to receive and transfer data | M1037 – Filter Network Traffic M1028 – Operating System Configuration M1018 – User Account Management | Managed XDR |
| Defense Evasion | T1027 – Obfuscated Files or Information | Some strings in the IntelUpdate.exe file are encrypted | M1049 – Antivirus/Antimalware | Managed XDR |
| Command and Control | T1105 – Ingress Tool Transfer | IntelUpdate.exe file downloads DLLfiles and calls functions CallA, CallB, CallC, CallD, and CallE | M1031 – Network Intrusion Prevention | Managed XDR |
