Each mechanism closes certain tactics on MITRE ATT&CK: from the substitution of system firmware System Firmware (T1542.001, persistence/stealth) and installation of butquitoes - Bootkit (T1542.003) before compromising the supply chain - Compromise Hardware Supply Chain (T1195.003, initial access) and abuse of the signed code - Code Signing (T1553.002, defense-impairment). None of the four covers all the stages of kill chain alone.
BIOS-password: BIOS or security protection
BIOS-password is the first thing that is mentioned when talking about protecting the pre-laden environment. And the first thing that costs audits.
The password is stored in CMOS (NVRAM) on the motherboard. Three ways to reset:
1. Remove CMOS battery for 30 seconds
2. Close the Clear CMOS
3. Read and overrewrite the contents of SPI flash by CH341A as currently done.
The programmer costs about 1200 rubles on marketplaces, SOIC clip for connecting to a chip without soldering - another 300.
In the Evil Maid (T1200, Hardware Additions) attacking physical access bypasses the BIOS-password in 5-10 minutes. In server environments with BMC/IPMI, the password is not a barrier at all: remote access through BMC allows you to change the BIOS settings software bypassing the password completely.
That the BIOS-password really protects: no more than just a random change in the download settings by the employee without technical training.
Detection: The BIOS password does not generate events in OS-level SIEM. There's nothing to monitor. The only option is a periodic audit of the BIOS configuration through CHIPSEC or proprietary motherboard vendor tools.
Secure Boot: Customization, Bypasses and Real Protection Against Butcites
Secure Boot is the main UEFI mechanism for protection against boutiques (T1542.003). Principle: cryptographic verification of each component of the boot chain on the basis of trusted certificates (db) and the list of withdrawn hashes (dbx). According to the documents - a reliable chain of trusted loading. In practice, over the past five years, three classes of vulnerabilities that break this chain regularly.
Interpretation: Local access and high privileges are needed, but the attack itself is trivial, the user’s interaction is not required. The impact on integrity is high.
The mechanism of operation: the attacker loads the legitimate, but vulnerable Windows bootloader is the one that came out before the correction. Since Microsoft at the time of detection of BlackLotus did not withdraw old bootloaders via dbx, Secure Boot took them as trusted. Through such a bootload, BlackLotus installs the UEFI module in the EFI System Partition, which is undergoing an OS reinsertress, and disables Windows Defender, HVCI and BitLocker.
According to ESET, BlackLotus is the first publicly documented UEFI-bouttee to bypass Secure Boot on the current Windows 11 and distributed as MaaS on criminal forums. Operation in the wild has been confirmed since March 1, 2023 - this is more than 1100 days of active operation.
Detection for SOC: monitoring the relevance of dbx. If the dbx park does not contain hashes of the cancelled bootloaders, your system is vulnerable. On Windows: Confirm-SecureBootUEFI in PowerShell will show whether Secure Boot is included, but will not reveal the relevance of dbx. For verification of dbx - Get-SecureBootPolicy or hand-held checking of hashes. Correlation rule: KB5012170 and subsequent dbx updates are not applied >90 days = high priority.
CVE-2024-7344: bypass through a vulnerable UEFI application Reloader
NVD CVSS 8.2 (HIGH) / MSRC CVSS 6.7 (Important) - discrepancies in evaluation between sources; MSRC 6.7 refers to Windows Server 2012/2012 R2 (KB5050048/5050004/5049993), for modern OS to be guided by NVD CVSS 8.2. Scope: Changed (C): Vulnerability in an application signed by Microsoft Corporation UEFI CA 2011 certificate allows you to perform arbitrary code in the context of UEFI.
The root cause is CWE-347 (Improp Verification of Cryptographic Signature): the app uses a custom PE-bottphone instead of standard UEFI functions LoadImage and StartImage. This downloader does not check the signatures and downloads arbitrary UEFI binary from the file cloak.dat - even unsigned. Beauty...
According to the ESET study (January 2025), the vulnerable UEFI application is Howyar Reloader (32/64-bit). According to NVD, the affected are: Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CS-Grp NeoImmpact. The ESET report also mentions WASAY eRecoveryRX and SignalComputer HDD King, but they are not available in the NVD affected list and require additional verification. The attacker does not need to wait until the victim installs one of these products: it is enough to bring your copy of a vulnerable binary to any system with Microsoft third-party UEF certificateI in db. On Windows 11 Secured-core PC, this default certificate is not trusted.
Microsoft recalled vulnerable binaries in Patch Tuesday on January 14, 2025.
Detection for SOC: File cloak.dat in EFI System Partition - direct IoC. Monitoring of changes in ESP (/boot/efi/ in Linux, mountvol + Sysmon Event Ident 11 on Windows for Ways \EFI\) If the organization does not use the listed recovery products, but their binaries are found on the host - this is an incident.
PKfail: factory test keys in production
In July 2024, Binarly found: about 900 models of devices from various OEMs (Acer, Dell, HP, Lenovo, Supermicro, etc.), using the BIOS code from IBV (AMI, Insyde, Phoenix), were supplied with the Secure Boot Platform Key (PK) test keys. These keys are generated during development - the manufacturer is obliged to replace them before release. In some cases, the private key was publicly available. How is it possible that the test key that was supposed to die in the laboratory went into production on hundreds of models?!
If private PK is available to the attacker, it signs an arbitrary bootloader - Secureu Boot will take it as a trustee. Remediation: update firmware with replacement of the test key. But only if the manufacturer has released an update. And according to IBM X-Force, the average time between the publication of CVE and elimination in the organization - 29 months, it is more than 2 years! For firmware patches, this figure is even higher.
A separate case - LogFAIL: a class of vulnerabilities in UEFI image parsing libraries discovered by Binarly in December 2023. An attacker with access to the EFI System Partition places a malicious logo file that operates parser before the Secure Boot check. LogoFAIL bypasses Secure Boot in full - the code is executed before the verification stage. The picture with the logo breaks the chain of trust. Ironically.
Detection for SOC: Act of Platform Key through chipsec_util uefi var-list or UEFITool. Test keys contain characteristic lines (DO NOT SHIP, DO NOT TRUST). Binarly provides pp.fail to test specific devices. Non-trivial image files in ESP are a potential IoC for LogoFAIL.
TPM Security and Measured Loading: What Really Protects the Chip
TPM (Trusted Platform Module) and Measured Boot use a fundamentally different approach: they do not prohibit the download of the unsigned code, but fix what exactly was loaded. Each boot chain component is hashed and recorded in PCR (Platform Configuration Registers) TPM. If the bootloader or kernel is changed, the PCR values will change.
In practice, TPM is effective in two scenarios:
BitLocker with TPP binding. The disk encryption key is sealed in TPM with reference to PCR 0, 2, 4, 7.
These specific PCR reactions represent the following components during the system boot process: 0 - Executable main system software files (BIOS/UEFI), 2 - Extended or connected executable code, 4 - Initial download sequence, 7 - Saving Download Configuration and Certificates.
If the boot chain is changed, TPM does not give the key - the disk is not decrypted. Against Evil Maid (T1200) is a serious barrier.
Remote attestation. The certification server requests a written report from the host with a signed TPM report with PCR values and compares with baseline. Deviation = altrate. This is the only way to detect compromised firmware remotely, without physical access to the machine.
TPM restrictions, which are usually silent about:
• TPM does not prevent downloading - only fixes. Without a dollout attestation or BitLocker-binding PCR-value, no one checks and the measured load is useless. In fact, it is an expensive iron that counts the hashes in the void.
• TPM does not protect against attacks in SMM (Ring -2): the SMM code is executed with privileges above the hypervisor and can manipulate the data to record in the PCR.
• TPM 1.2 vs TPM 2.0: only TPM 2.0 supports SHA-256 PCR banks. TPM 1.2 - SHA-1 only, legacy.
• Cold boot: If physically access, the attacker can remove the keys from RAM before cleaning.
Intel Boot Guard: usaldusväärse allalaadimise riistvaraline juur
Intel Boot Guard is the only one of the four mechanisms that gives a hardware root of trust. OEM in the production stitches the hash of its public key in single-programmable fuses processor. At each start, the CPU checks the signature of the Initial Boot Block (IBB) in the SPI-flash. This approach, is critical as much as it is possible: the discrepancy will not be loaded. The Point.
Two modes: Verified Boot - CPU checks the signature of the IBB and blocks the download of unsigned firmware (hard control). Measured Boot - The CPU records IBB hash in TPM PCR-0, but does not block the load (requires a remote attestation for reaction). In practice, Verified Boot is the case when an attacker with an SPI-programmer can overwrite the entire SPI flash, but the CPU will refuse to download an IBB with someone else’s signature. This hardware closes T1542.001 (System Firmware). The programmer for one and a half thousand rubles here is useless.
Restrictions:
• Boot Guard configuration - OEM responsibility. If the manufacturer has not activated the Boot Guard or has stitched a weak key, the user cannot fix it - fuses (fuse) disposable. You can't squeeze the fuses.
• Boot Guard only protects IBB (initial phase SEC/PEI). Subsequent phases (DXE, BDS) must be protected by Secure Boot.
• Supply chain attack to OEM-fook (T1195.003) bypasses Boot Guard: if the malicious firmware is signed by OEM key - everything, the game is over at the start.
• Support depends on the CPU generation: full - Coffee Lake and newer.
Dump rom.bin analyzed through UEFITool: FIT table should contain 4x0B (Key Manifest) and 0x0C (Boot Policy Manifest) records. Their absence means that Boot Guard is not configured on the device.
Comparison of UEFI Harening Mechanisms and firmware Protection
No mechanism in isolation closes the entire chain. Working combination: Intel Boot Guard (IBB) → Secure Boot with current dbx (bootloader, kernel) → TPM with remote attestation (Detection). BIOS-password is an additional layer of random changes that does not compensate for the absence of the rest.
Adjustments to the environment for inspections:
SPI Flash write protection - CHIPSEC common.bios_wppassed. CHIPSEC common.bios_wpchecks BLE=1 and SMM_BWP=1. Secure configuration: BLE=1 and SMM_BWP=1. Only BLE=1 without SMM_BWP is vulnerable to Speed Racer Race Zone (Kallenberg/Wojtzuk 2014). BLE=0 - SPI flash not protected from recording
1. Intel Boot Guard is active - FIT table in the SPI dumpet contains KM (0x0B) and BPM (0x0C)
2. Firmware is included in the VM-process - the update cycle at least once a quarter
3. ESP monitoring tuned - Sysmon Event ID 11 for tracks \EFI\(Windows), inotifywait /boot/efi/(Linux)
4. PCR baseline is removed and stored - deferral PCR-0 / PCR-7 without a ticket for updating = incident
Correlation rules for SIEM:
• Appearance of files cloak.dator atypical .efi-binaryn in ESP -> high priority (IoC for CVE-2024-7344)
• Windows Event ID 1796 (Modalness to Secure Boot) without change request -> investigation
• Deviation PCR from baseline without recorded firmware update -> investigation
• No dbx updates > 90 days on the host with active Secure Boot -> average priority, escalation
For CII entities: firmware-compromising falls under the FZ-187, incidents are subject to notification through GosSOPKA (NCCCI) within 3-24 hours, depending on the category of importance of the object.
On real audits, firmware-level is checked by units - even in organizations with a developed SOC. According to IBM X-Force, the average time between CVE posting and elimination is 29 months. For firmware patches in corporate environments, this figure is even higher: most organizations do not have a BIOS/UEFI update process as a part of management. EDR and XDR work in Ring 0, firmware lives in Ring -2 - between them the gap in which the entire detection fails.
BIOS-password: BIOS or security protection
BIOS-password is the first thing that is mentioned when talking about protecting the pre-laden environment. And the first thing that costs audits.
The password is stored in CMOS (NVRAM) on the motherboard. Three ways to reset:
1. Remove CMOS battery for 30 seconds
2. Close the Clear CMOS
3. Read and overrewrite the contents of SPI flash by CH341A as currently done.
The programmer costs about 1200 rubles on marketplaces, SOIC clip for connecting to a chip without soldering - another 300.
In the Evil Maid (T1200, Hardware Additions) attacking physical access bypasses the BIOS-password in 5-10 minutes. In server environments with BMC/IPMI, the password is not a barrier at all: remote access through BMC allows you to change the BIOS settings software bypassing the password completely.
That the BIOS-password really protects: no more than just a random change in the download settings by the employee without technical training.
Detection: The BIOS password does not generate events in OS-level SIEM. There's nothing to monitor. The only option is a periodic audit of the BIOS configuration through CHIPSEC or proprietary motherboard vendor tools.
Secure Boot: Customization, Bypasses and Real Protection Against Butcites
Secure Boot is the main UEFI mechanism for protection against boutiques (T1542.003). Principle: cryptographic verification of each component of the boot chain on the basis of trusted certificates (db) and the list of withdrawn hashes (dbx). According to the documents - a reliable chain of trusted loading. In practice, over the past five years, three classes of vulnerabilities that break this chain regularly.
Interpretation: Local access and high privileges are needed, but the attack itself is trivial, the user’s interaction is not required. The impact on integrity is high.
The mechanism of operation: the attacker loads the legitimate, but vulnerable Windows bootloader is the one that came out before the correction. Since Microsoft at the time of detection of BlackLotus did not withdraw old bootloaders via dbx, Secure Boot took them as trusted. Through such a bootload, BlackLotus installs the UEFI module in the EFI System Partition, which is undergoing an OS reinsertress, and disables Windows Defender, HVCI and BitLocker.
According to ESET, BlackLotus is the first publicly documented UEFI-bouttee to bypass Secure Boot on the current Windows 11 and distributed as MaaS on criminal forums. Operation in the wild has been confirmed since March 1, 2023 - this is more than 1100 days of active operation.
Detection for SOC: monitoring the relevance of dbx. If the dbx park does not contain hashes of the cancelled bootloaders, your system is vulnerable. On Windows: Confirm-SecureBootUEFI in PowerShell will show whether Secure Boot is included, but will not reveal the relevance of dbx. For verification of dbx - Get-SecureBootPolicy or hand-held checking of hashes. Correlation rule: KB5012170 and subsequent dbx updates are not applied >90 days = high priority.
CVE-2024-7344: bypass through a vulnerable UEFI application Reloader
NVD CVSS 8.2 (HIGH) / MSRC CVSS 6.7 (Important) - discrepancies in evaluation between sources; MSRC 6.7 refers to Windows Server 2012/2012 R2 (KB5050048/5050004/5049993), for modern OS to be guided by NVD CVSS 8.2. Scope: Changed (C): Vulnerability in an application signed by Microsoft Corporation UEFI CA 2011 certificate allows you to perform arbitrary code in the context of UEFI.
The root cause is CWE-347 (Improp Verification of Cryptographic Signature): the app uses a custom PE-bottphone instead of standard UEFI functions LoadImage and StartImage. This downloader does not check the signatures and downloads arbitrary UEFI binary from the file cloak.dat - even unsigned. Beauty...
According to the ESET study (January 2025), the vulnerable UEFI application is Howyar Reloader (32/64-bit). According to NVD, the affected are: Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery, Sanfong EZ-back System, CS-Grp NeoImmpact. The ESET report also mentions WASAY eRecoveryRX and SignalComputer HDD King, but they are not available in the NVD affected list and require additional verification. The attacker does not need to wait until the victim installs one of these products: it is enough to bring your copy of a vulnerable binary to any system with Microsoft third-party UEF certificateI in db. On Windows 11 Secured-core PC, this default certificate is not trusted.
Microsoft recalled vulnerable binaries in Patch Tuesday on January 14, 2025.
Detection for SOC: File cloak.dat in EFI System Partition - direct IoC. Monitoring of changes in ESP (/boot/efi/ in Linux, mountvol + Sysmon Event Ident 11 on Windows for Ways \EFI\) If the organization does not use the listed recovery products, but their binaries are found on the host - this is an incident.
PKfail: factory test keys in production
In July 2024, Binarly found: about 900 models of devices from various OEMs (Acer, Dell, HP, Lenovo, Supermicro, etc.), using the BIOS code from IBV (AMI, Insyde, Phoenix), were supplied with the Secure Boot Platform Key (PK) test keys. These keys are generated during development - the manufacturer is obliged to replace them before release. In some cases, the private key was publicly available. How is it possible that the test key that was supposed to die in the laboratory went into production on hundreds of models?!
If private PK is available to the attacker, it signs an arbitrary bootloader - Secureu Boot will take it as a trustee. Remediation: update firmware with replacement of the test key. But only if the manufacturer has released an update. And according to IBM X-Force, the average time between the publication of CVE and elimination in the organization - 29 months, it is more than 2 years! For firmware patches, this figure is even higher.
A separate case - LogFAIL: a class of vulnerabilities in UEFI image parsing libraries discovered by Binarly in December 2023. An attacker with access to the EFI System Partition places a malicious logo file that operates parser before the Secure Boot check. LogoFAIL bypasses Secure Boot in full - the code is executed before the verification stage. The picture with the logo breaks the chain of trust. Ironically.
Detection for SOC: Act of Platform Key through chipsec_util uefi var-list or UEFITool. Test keys contain characteristic lines (DO NOT SHIP, DO NOT TRUST). Binarly provides pp.fail to test specific devices. Non-trivial image files in ESP are a potential IoC for LogoFAIL.
TPM Security and Measured Loading: What Really Protects the Chip
TPM (Trusted Platform Module) and Measured Boot use a fundamentally different approach: they do not prohibit the download of the unsigned code, but fix what exactly was loaded. Each boot chain component is hashed and recorded in PCR (Platform Configuration Registers) TPM. If the bootloader or kernel is changed, the PCR values will change.
In practice, TPM is effective in two scenarios:
BitLocker with TPP binding. The disk encryption key is sealed in TPM with reference to PCR 0, 2, 4, 7.
These specific PCR reactions represent the following components during the system boot process: 0 - Executable main system software files (BIOS/UEFI), 2 - Extended or connected executable code, 4 - Initial download sequence, 7 - Saving Download Configuration and Certificates.
If the boot chain is changed, TPM does not give the key - the disk is not decrypted. Against Evil Maid (T1200) is a serious barrier.
Remote attestation. The certification server requests a written report from the host with a signed TPM report with PCR values and compares with baseline. Deviation = altrate. This is the only way to detect compromised firmware remotely, without physical access to the machine.
TPM restrictions, which are usually silent about:
• TPM does not prevent downloading - only fixes. Without a dollout attestation or BitLocker-binding PCR-value, no one checks and the measured load is useless. In fact, it is an expensive iron that counts the hashes in the void.
• TPM does not protect against attacks in SMM (Ring -2): the SMM code is executed with privileges above the hypervisor and can manipulate the data to record in the PCR.
• TPM 1.2 vs TPM 2.0: only TPM 2.0 supports SHA-256 PCR banks. TPM 1.2 - SHA-1 only, legacy.
• Cold boot: If physically access, the attacker can remove the keys from RAM before cleaning.
SOC tuvastamine: kaugkinnituse olemasolu korral – baas-PCR + hoiatus kõrvalekaldest. Kinnituse puudumisel – PCR-väärtuste perioodiline kogumine agendi kaudu ja võrdlemine võrdlusaluse väärtusega. PCR-0 või PCR-7 muutmine ilma registreeritud püsivara uuenduseta = potentsiaalne ohustatus.
Intel Boot Guard: usaldusväärse allalaadimise riistvaraline juur
Intel Boot Guard is the only one of the four mechanisms that gives a hardware root of trust. OEM in the production stitches the hash of its public key in single-programmable fuses processor. At each start, the CPU checks the signature of the Initial Boot Block (IBB) in the SPI-flash. This approach, is critical as much as it is possible: the discrepancy will not be loaded. The Point.
Two modes: Verified Boot - CPU checks the signature of the IBB and blocks the download of unsigned firmware (hard control). Measured Boot - The CPU records IBB hash in TPM PCR-0, but does not block the load (requires a remote attestation for reaction). In practice, Verified Boot is the case when an attacker with an SPI-programmer can overwrite the entire SPI flash, but the CPU will refuse to download an IBB with someone else’s signature. This hardware closes T1542.001 (System Firmware). The programmer for one and a half thousand rubles here is useless.
Restrictions:
• Boot Guard configuration - OEM responsibility. If the manufacturer has not activated the Boot Guard or has stitched a weak key, the user cannot fix it - fuses (fuse) disposable. You can't squeeze the fuses.
• Boot Guard only protects IBB (initial phase SEC/PEI). Subsequent phases (DXE, BDS) must be protected by Secure Boot.
• Supply chain attack to OEM-fook (T1195.003) bypasses Boot Guard: if the malicious firmware is signed by OEM key - everything, the game is over at the start.
• Support depends on the CPU generation: full - Coffee Lake and newer.
Dump rom.bin analyzed through UEFITool: FIT table should contain 4x0B (Key Manifest) and 0x0C (Boot Policy Manifest) records. Their absence means that Boot Guard is not configured on the device.
Comparison of UEFI Harening Mechanisms and firmware Protection
No mechanism in isolation closes the entire chain. Working combination: Intel Boot Guard (IBB) → Secure Boot with current dbx (bootloader, kernel) → TPM with remote attestation (Detection). BIOS-password is an additional layer of random changes that does not compensate for the absence of the rest.
Adjustments to the environment for inspections:
SPI Flash write protection - CHIPSEC common.bios_wppassed. CHIPSEC common.bios_wpchecks BLE=1 and SMM_BWP=1. Secure configuration: BLE=1 and SMM_BWP=1. Only BLE=1 without SMM_BWP is vulnerable to Speed Racer Race Zone (Kallenberg/Wojtzuk 2014). BLE=0 - SPI flash not protected from recording
1. Intel Boot Guard is active - FIT table in the SPI dumpet contains KM (0x0B) and BPM (0x0C)
2. Firmware is included in the VM-process - the update cycle at least once a quarter
3. ESP monitoring tuned - Sysmon Event ID 11 for tracks \EFI\(Windows), inotifywait /boot/efi/(Linux)
4. PCR baseline is removed and stored - deferral PCR-0 / PCR-7 without a ticket for updating = incident
Correlation rules for SIEM:
• Appearance of files cloak.dator atypical .efi-binaryn in ESP -> high priority (IoC for CVE-2024-7344)
• Windows Event ID 1796 (Modalness to Secure Boot) without change request -> investigation
• Deviation PCR from baseline without recorded firmware update -> investigation
• No dbx updates > 90 days on the host with active Secure Boot -> average priority, escalation
For CII entities: firmware-compromising falls under the FZ-187, incidents are subject to notification through GosSOPKA (NCCCI) within 3-24 hours, depending on the category of importance of the object.
On real audits, firmware-level is checked by units - even in organizations with a developed SOC. According to IBM X-Force, the average time between CVE posting and elimination is 29 months. For firmware patches in corporate environments, this figure is even higher: most organizations do not have a BIOS/UEFI update process as a part of management. EDR and XDR work in Ring 0, firmware lives in Ring -2 - between them the gap in which the entire detection fails.
