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
    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.
    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.
    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.
    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.
    In 2017, WikiLeaks published information about DerStarke, the UEFI version of the Triton backdoor for macOS.
    In 2018, ESET detected and analyzed the LoJax UEFI rootkit, the first UEFI bootkit discovered by information security companies in the wild.
    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: ""
      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.
      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






































      Indicators: File paths
      %PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup \IntelUpdate.exe




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


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

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












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



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









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









      Indicators: Mutex
      set instance state

      single UI

      Office Module

      foregrounduu state

      process attach Module
      Indicators: Network indicators
      MITRE ATT&CK и MITRE Shield