The ransomware threat has existed for more than ten years and in that time has developed into an increasingly sophisticated application logic that is difficult to detect and counter. Recently, a researcher from the ESET group (Martin Smolar) identified a particularly dangerous behaviour of a variant of the Petya malware. This behaviour consists in the ability to infect the UEFI (Unified Extensible Firmware Interface).
What is UEFI
UEFI code is executed almost immediately after the computer is turned on, before the operating system and any security solutions at the operating system level are started, ensuring that malware can operate with maximum privileges and in an unprotected environment. The UEFI firmware is essential for the system because, during its loading, it activates all those operations, processes and peripherals, necessary for the operating system to function properly.
UEFI and its origins
It should be explained that UEFI firmware was introduced in the early 2000s as an evolution of the predecessor BIOS. In 2005, the Unified EFI Forum (UEFI Forum) was founded, a consortium of companies that took over Intel’s EFI 1.10 specification and started to develop it into the UEFI standard. The year in which the UEFI name was formally adopted as a consortium was 2005. The first PCs equipped with UEFI and distributed on a large scale would not arrive until 2010; Microsoft, for instance, would wait for Windows 8 (2012) to take full advantage of UEFI firmware. The reason for abandoning the BIOS in favour of UEFI is mainly from a performance point of view.
- It can boot up the system in less time due to the more efficient management of the boot process and the elimination of the lengthy BIOS self-diagnosis (POST – Power-On Self-Test).
- It can manage, unlike the BIOS, hard disks with capacities above 2.2 TB using the GUID Partition Table (GPT).
- As it runs in 64-bit mode, it has access to more memory (RAM) and can execute pre-boot processes faster.
- It offers a more modern and intuitive graphical user interface with mouse support, overcoming the old BIOS interface that was text-based and limited to keyboard control.
- It supports network functionality and can load specific drivers and applications (EFI modules) before the operating system.
UEFI and main operation
How UEFI firmware works is important, so it is necessary to understand it. The first thing to know is that the actual UEFI firmware is stored on a chip installed on the computer’s motherboard. However, the UEFI firmware, in order to boot the system, needs to read some boot files that are located in a specific memory partition called the EFI System Partition. This memory partition (generally in FAT32 format) is installed inside the system’s mass storage (HDD or SSD). Thus, UEFI firmware essentially consists of two parts:
- The chip installed on the computer’s motherboard.
- The EFI System Partition created in the system’s mass memory.
This is also a radical difference with the previous system (the BIOS), which had no disk partitions but resided entirely within the memory chip on the motherboard. This made it less versatile but more secure than the UEFI.
During the initial loading of the UEFI firmware, essential procedures such as an initial reset of the system processor and a preliminary memory initialisation(PEI – Pre EFI Initialisation) are performed. Following PEI there is then the initialisation of the drivers(DXE – Driver Execution Enviroment), and only at this point does the operating system boot. For greater comprehension, the phases and their description are given below
| Security Phase (SEC) | Initialises the processor and creates temporary memory. Establishes the system’s root of trust. Passes control to the PEI phase. |
| Pre-EFI Initialisation (PEI) | It initialises the permanent memory (RAM). It collects information about the system and organises it in structures called HOBs1 (Hand-Off Blocks). It prepares the environment for the next step, DXE. |
| Driver Execution Enviroment (DXE) | Loads the necessary drivers for hardware devices. Initialises the chipset, CPU2, buses and peripherals. Provides boot and runtime services. Collaborates with the Boot Device Selection (BDS) stage to select the device from which the operating system will boot. |
| Boot Device Selection (BDS) | Determines the boot device (e.g. SSD, USB, network). Starts loading the operating system. |
It is therefore clear that, from the moment the computer’s power button is pressed to when the operating system’s loading screen appears, the UEFI system takes care of performing essential, preparatory procedures, albeit in a low-security operating environment. At the end of this preliminary procedure, the firmware calls the ExitBootServices() function, at which point the operating system is loaded.
UEFI and security
Due to its strategic nature, UEFI firmware should be kept secure through updates that users should make regularly. Updates are made, as a matter of practice, by the manufacturer and are intended to increase the stability and security of the subsystem. Despite the measures taken so far, UEFI firmware cannot be considered a ‘safe’ environment, so much so that there have already been threats in the past that exploited UEFI or bypassed its functions for malicious purposes, it is worth remembering:
- BlackLotus (exploits CVE-2022-21894)
- BootKitty
- MosaicRegressor (a malicious framework including a UEFI bootkit, discovered in 2020)
UEFI protection mechanisms exist. One of these is called UEFI Secure Boot and is designed to prevent the execution of unsigned or unauthorised code during boot-up. This security measure, however, must be updated regularly to accommodate all security changes made over time.
Specifically, UEFI Secure Boot is based on a database called the Forbidden Signature Database (DBX), which stores the digital signatures of boot software (boot loaders) identified as vulnerable or compromised (e.g. due to exploits known as ‘bootkits’ or security bugs in the signed code). Microsoft and other partners periodically release updates for the DBX. Consequently, if the DBX is not updated, the system may allow old malicious boot loaders known to be vulnerable to run, compromising security at boot time. These updates are often distributed via Microsoft Windows Update or directly from the PC manufacturer.
It must also be taken into account that signing authority certificates (such as Microsoft’s Windows boot loaders) have an expiry date. For instance, some key certificates are up for renewal, and to ensure that the system continues to recognise and securely boot the latest versions of the operating system, it is necessary to update the certificate databases(DB – Allowed Signature Database) and sometimes the KEK(Key Enrollment Key)3 before they expire.
In conclusion, it is therefore clear that in order to correct these flaws, motherboard and PC manufacturers release BIOS/UEFI updates; installing the latest firmware is therefore crucial to maintaining the integrity of Secure Boot. It should be remembered that installing these updates is also a legal obligation for P.A.’s and those impacted by NIS2, as well as a good practice.
The HybridPetya case
HybridPetya is a new Petya/NotPetya ransomware variant, but with a significant addition: the ability to compromise UEFI firmware-based systems. Unlike its predecessors, HybridPetya is able to install a malicious EFI application in the EFI System Partition (ESP). This application runs during system start-up, allowing the malware to operate at a very high privilege level, even before the operating system loads. Once running, the UEFI application encrypts the Master File Table (MFT), a crucial file that contains the metadata of all files on NTFS partitions, rendering the system inaccessible. Some analysed variants of HybridPetya exploit the CVE-2024-7344 vulnerability (a flaw in a third-party UEFI application) to bypassUEFI Secure Boot on out-of-date systems.
Apparently, although samples of HybridPetya were discovered relatively recently (in 2025 according to research), there are still no signs of its active use in ‘in the wild’ attacks, but it represents a clear evolution of ransomware tactics. Unlike NotPetya, which was predominantly destructive, HybridPetya appears to have been designed for financial gain, theoretically allowing the decryption key to be reconstructed from the victim’s personal installation code (more akin to Petya).
The ability of ransomware to attack UEFI firmware is one of the most serious threats in the IT security landscape, as it allows malware to survive even a disk change, complete formatting or reinstallation of the operating system. The only solution in many cases is to update (or replace) the motherboard firmware. By exploiting specific vulnerabilities or compromised keys, a UEFI bootkit can disable or bypass critical security mechanisms such as UEFI Secure Boot, which would otherwise prevent the loading of unsigned drivers or bootloaders.
Countermeasures
The most drastic scenario to deal with is infection of the UEFI resulting in the entire boot process being compromised, and it is therefore clear that the solution cannot be to format/replace the disks. The remediation activity must start much earlier with the flashing of the UEFI chip. This involves overwriting the UEFI with an updated version downloaded from the manufacturer’s Internet portal or restoring the original version. In some cases, the original version resides in a read-only4 (ROM – Read Only Memory) chip that can be used for extreme cases. In more serious cases, a complete replacement of the chip can be considered, but not always performed, by inserting it into a programmer, but certainly these cases are reserved for very small and specialised areas. In the vast majority of cases, in the case of a severe infection, it is necessary to replace the entire motherboard, with a considerable increase in complexity and costs for clean-up and restoration.
The question sometimes arises as to whether an ‘easy’ chip replacement is possible, without resorting to complex debulking activities (removing the solder, removing the chip and replacing it with a new one). In theory, it could be done, but only under certain specific conditions. The first is that the general characteristics are identical: same manufacturer, same model, and preferably the same revision. The second is that the detailed characteristics are the same: same memory capacity, same voltage, identical pinout and socket/soldering type.
Furthermore, it must be considered that the chip swapping activity should not be supervised by a specific procedure since the UEFI firmware contains unique platform data (such as the serial number of the motherboard, the MAC address of the network card, and in some cases, the OEM digital licence of the Windows operating system); by swapping the chip, this data is also transferred, and thus this could have an impact on the system in its complexity.
Lastly, it is worth bearing in mind that replacing the UEFI chip may not be the solution if you have not also cleaned up the partition in the mass storage: in fact, if an infection persists in the EFI System Partition, there would be a risk of infecting the newly installed chip with the malware residing in the EFI System Partition. This would frustrate the entire operation and increase costs.
Furthermore, there are easily accessible tools that can verify (with fair reliability) the integrity condition of UEFI firmware by intercepting, as in the present case, alterations made by malware.
EFI_STATUS EFIAPI MaliciousEntryPoint(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
// Intercetta la funzione ExitBootServices per iniettare un payload
OriginalExitBootServices = SystemTable->BootServices->ExitBootServices;
SystemTable->BootServices->ExitBootServices = HookedExitBootServices;
return EFI_SUCCESS;
}
EFI_STATUS EFIAPI HookedExitBootServices(IN EFI_HANDLE ImageHandle, IN UINTN MapKey) {
// Payload simulato: registra l'evento di avvio (in un malware reale, qui potrebbe iniziare la cifratura)
LogToHiddenPartition("Avvio del sistema intercettato");
// Chiama la funzione originale
return OriginalExitBootServices(ImageHandle, MapKey);
}Many security products are able to perform this type of check automatically and quite effectively, and ESET has also introduced this possibility in its products.
Conclusions
It is important to emphasise that, as of today, UEFI firmware infection is an extremely rare event and usually associated with sophisticated attacks that are hardly reserved for low-ranking individuals. However, it is just as relevant to note the evolution that this threat has undergone over the years, leading to a constant updating of attack dynamics and counter-attack logics, which are not always up to the mark. Furthermore, it is possible to note how, with the transition from BIOS to UEFI and the related increase in processing complexity, there has been a proportional increase in the threats and risks to which systems are exposed.
Notes
- The Key Exchange Key is a key element in the UEFI Secure Boot chain of trust. Its crucial function is to sign and authorise updates to the database of permitted keys (DB) and the database of revoked keys (DBX). The KEK (often owned by Microsoft or the OS/OEM manufacturer) verifies updates for DB and DBX. ↩︎
- Read-only is ensured by physical electronic components that allow electrical transmission in only one direction (e.g. diodes). ↩︎
