The place in the chain of attack: why break the firmware
Compromise of UEFI-fishering is notan end in itself, but the solution of two tasks in kill chain
ersistence below the level of the OS and stealth from softwareprotection.According to the MITRE ATT&CKclassification, attacks on firmware cover several technicians:
• T1542.001 System Firmware(Persistence, Defense Evasion) - modification of the system firmwarefor fixing
• T1542.003 Bootkit(Persistence, Defense Evasion) - introduction of code into thedownloading process
• T1495 Firmware Corruption(Impact) - Firmware damage to disable the system
• T1562.001 Disable or ModifyTools (Defense Evasion) - disabling security mechanisms through themodification of the pre-boot environment
• T1553.006 Code Signing PolicyModification (Defense Evasion) - changing the policy of codesignature, including modification db/dbx
Typical scenario: physical access tothe endpoint → bypass BIOS lock → Disable Securo Boot →Download from the external media → installation boott → BIOSsettings. The regular OS is loaded normally, EDR works, the user doesnot notice anything - but payload is executed before the start ofWindows and any security software. The previous stage is to obtainphysical access (penetration, social engineering, access to theserver). Next up is the lateral movement through a compromisedendpoint.
UEFI Secure Boot chain: what exactlywe break
Secure Boot relies on a hierarchy ofcryptographic keys in NVRAM:
• Platform Key (PK) - trustroot, owned by OEM (Lenovo, Dell, HP). Controls access to KEK.
• Key Exchange Key (KEK) - keysfor verifying changes in db and dbx.
• Signature Database (db) -whitelist: certificates and hashes of permitted binary trees.
• Revocation List (dbx) -blacklist: hashes of revoked or vulnerable binarys.
When booting UEFI Boot Manager checkseach component (bouncer, driver, kernel) by db and dbx. Binary withvalid signature from db and missing in dbx - starts. Otherwise,Security Violation.
On the vast majority of devices in dbthere are two Microsoft certificates:
• Microsoft Windows ProductionPCA 2011 - for Microsoft's own downloaders
• Microsoft Corporation UEFI CA2011 - for signature of third-party UEFI-PO (Linux shim, recoveryutilities, disk encryption)
The second certificate creates themain surface of the attack: any developer can send his UEFI binary toMicrosoft’s signature via Windows Hardware DevC. If there is avulnerability in the signed binary - Secure Boot will miss it. As theESET researchers noted, the opacity of the process of reproach fromMicrosoft poses a systemic problem: “obviously insecure” binariesreceive a signature and fall into a trusted environment.
Software vectors bypass Secure Boot
CVE-2024-7344: custom PE-loaderbypasses the trust chain
According to a study by ESET(published on January 16, 2025), CVE-2024-7344 is affected by theUEFI application Howyar Reloader, signed by a Microsoft CorporationUEFI CA 2011 certificate.
CVSS: 8.2 (HIGH), vectorCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. CWE-347 is an ImproperVerification of Cryptographic Signature.
The essence is simple toindistinguishing: the application uses a custom PE-downloader insteadof standard UEFI functions LoadImage and StartImage. Because of this,it pulls any UEFI-binary - including unsigned - from a file with arigidly given name cloak.dat, completely ignoring the state of SecureBoot. That is, Microsoft signed a binary, which explicitly bypassesthe mechanism for which Secureu Boot exists.
Thrown with products (according toNVD): Howyar SysReturn, Greenware GreenGuard, Radix SmartRecovery,Sanfong EZ-back System, CES NeoImmpact. According to ESET, WeayeRecoveryRX and SignalComputer HDD King are also vulnerable, but theyare not available on the NVD list and require independentverification.
Operation Vector: an attacker withlocal administrator rights (PR:H in a CVSS vector) places avulnerable but signed application on the EFI System Partition, alongwith a malicious cloak.dat. Secure Boot validates the signature ofthe binary, it loads arbitrary code from cloak.dat. And here's what'sbeautiful: for operation no needthat the target car is a vulnerablesoftware - the attacker brings its copy of the signed binary. TheBYOVB (Bring Your Own Vulnerable Bootloader)
According to MSRC, the vulnerable arewithdrawn by the update of January 14, 2025 (KB5050048, KB5050004,KB5049993). Microsoft at MSRC from 14.01.2025 evaluates impact asImportant (Security Feature Bypass, CVSS base=6.7 - below NVD ratings.22, as the MSRC evaluates the bypassing the security function ofWindows, and NVD - exposure through a vulnerable UEFI application).
According To CISA Vulnrichment, SSVCDecision - Track: exploitation in the wild is not recorded(exploitation: none), automation is not possible (automatable: no),but technical impact - total. The probability of operation on EPSS is0.39% for 30 days (60th percentage, above the median among all CVE),which indicates a moderate but real risk.
Works if: Secure Boot is included,but dbx does not contain a hash of a vulnerable binary (an updatefrom January 2025 not established); the attacker has the rights torecord on the ESP.
Does not work if: dbx has beenupdated; Windows 11 Secured-core PC with disable trust in third-partyUEFI CA; Intel Boot Guard is active and verifies firmware before theUEFI Boot Manager launch.
CVE-2020-10713 (BootHole): bufferoverflow in GRUB2
CVSS: 8.2 (HIGH), vectorCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. CWE-120 - Buffer Copywithout Checking Size of Input.
BootHole - classic buffer overflow inthe parser of configuration file grub.cfg GRUB2 bootloader (to the2.06). Secure Boot verifies the signature of the binary GRUB2, butdoes not verify the contents grub.cfg. The attacker with root accessmodifies the configuration file to trigger overflow at the nextdownload. According to the NVD, the vector is not limited to localroot - the attacker can also replace the configuration through thePXE-boot network or use remote root access to the network system.Overflow occurs after the loader verification, but before loading thekernel - the result: arbitrary code execution in a trusted context.
Affected systems (according to NVD):GNU GRUB2, Debian Linux, openSUSE Leap, VMware Photon OS. Accordingto the MSRC (release 18.08.2020), CBL-Mariner grub2 is affected tothe 2.06~rc1. EPSS - 0.37% (59th percent).
The architectural problem thatBootHole demonstrates: the signature validates the integrity of theexecutable code, but does not validate the data that this codeprocesses. Signed a binary - well done. And what he's next parsite isnone of your business. Logic worthy of a separate entry in thetextbook.
Works if: on the system is GRUB2 <2.06, dbx not updated, the attacker has root access (local or remote)or the ability to replace the PXE-boot configuration. Does not workif: GRUB2 is updated to 2.06+; a system without GRUB2 (net Windowswithout dual boot); the hash of a vulnerable GRUB2 in dbx.
SMM Exploitation: attack from Ring-2
System Management Mode (SMM) -privileged x86-process mode, "Ring -2". The code in SMM isexecuted in a separate address space (SMRAM) invisible to the OS andhypervisor. It starts through System Management Interrupts (SMI).
If an attacker finds a vulnerabilityin a buffer overflow (Confused - unsubscribe of pointers from anunprivileged context), it receives a code execution in SMM. From thiscontext, you can:
• Modify variablesdb/dbx/KEK/PK in NVRAM - direct bypass Secureu Boot (T1553.006)
• Completely disable SecureBoot protection
• Re-register SPI-flash withfirmware (T1601.001 Patch System Image)
It is impossible to detectSMM-operation with standard means - the code is executedtransparently for the OS kernel. Detecting requires hardwaremonitoring (Intel Boot Guard) or specialized integrity checks throughexternal TPM.
Works if: SMRAM is not blocked(CHIPSEC module common.smm returns [FAILED]), there is a vulnerableSMI handler in the firmware. Does not work if: SMM Lock is correct,Memory Range Register (SMRR) is active.
The crisis dbx: why review does notsolve the problem
The dbx mechanism is the main line ofdefense against BYOVB. In practice, it falls apart for three reasons:
1. The size of NVRAM is limited.dbx with thousands of hashes can not be obscure in the availablespace of SPI flash.
2. The risk of “octuring”.Aggressive dbx update blocks a single work bootloader on the disk -the system stops booting. Administrators know this and postponing it.
3. Vulnerability window. Monthsbetween CVE detection and dbx-up renewal on all devices take months.
The attacker exploits this window,delivering an old, vulnerable, but still “trusted” bootloaderwhose hash didn’t have time to get into the dbx target system.
Bypassing BIOS protection withphysical access
Removal and modification of the dumpSPI-flash
Adjustments to the environment:
• Programmer: CH341A (~500rub.) or Depedprogor SFC600 (~$300 for professional use)
• SOIC-8 / SOIC-16 forconnecting to a chip without sacrificing
• PC with Linux (Ubuntu22.04+), 4 GB RAM minimum
• flashrom (apt installflashrom), UEFITool NE Alpha 68 (last release: 2024, GitHub, activeproject)
• For DXE module analysis:Ghidra 11.x (free) or IDE Pro
BIOS Password Bypass without aprogrammer
On a number of platforms, the BIOSpassword can be bypassed without soldering - the removal ofCMOS-batteries, master-passwords based on Service Tag (on the part ofthe Dell models), hardware reset through the closure of certaincontacts. There is no universal method - for each vendor and modeltheir own approach. For red team, the Damp SPI-flash remains the mostreliable option independent of vendor-specific backdoor backdoor.
Firmware audit with CHIPSEC
Adjustments to the environment:
• OS: Linux (Ubuntu 22.04 /Fedora 38+) or Windows 10/11 with TestSigning included
• Python 3.8+, build-essential,python3-dev, nasm, libpici-dev
• 4+ GB RAM, root-access
• Run only on the test stand -CHIPSEC downloads a kernel-level driver with direct access tohardware resources. On a productive server, this can end BSOD, andexplain the reason for the customer will be awkward.
CHIPSEC (last release: 2024, ~2.5kstars on GitHub, actively supported by Intel) is a framework forauditing the security of the platform at the firmware level.
Key modules for BIOS protection:
• common.secureboot.variables-checks the protection of Secure Boot variables from the modificationfrom the OS
• common.spi_lock- SPI-flashwrite protection; [FAILED]= firmware can be overwritten softwarewithout physical access
• common.bios_wp- WriterProtection for BIOS-region
• common.smm- SMRAM protection;[FAILED]= SMM-exploitation is possible
If common.spi_lock returns [FAILED],firmware can be re-recorded software - this is the way to installUEFI rootkit without opening the body. On corporate devices that havenot passed firmware hardening, this is found regularly. On one auditof ten laptops in the organization seven returned [FAILED] byspi_lock - and they weren't the cheapest cars.
Choosing a vector attack on firmware
Grey box script (issued by low-privcrcredentials): First privilege escalation to admin/root (T1068), thenchecking the condition dbx: mokutil --sb-state in Linux orConfirm-SecureBootUEFI in PowerShell. If dbx is obsolete - BYOVB. Inparallel: sudo python3 chipsec_main.py -m common.spi_lock - if theSPI is not located, the software overlap is available. If everythingis located and updated, you need physical access or SMM vector.
What fixes the defense when attackingthe firmware
What is Detected:
• Recording on EFI SystemPartition - any EDR with file system monitoring will record theappearance of .efi files in /boot/efi/or \EFI\Boot\. CrowdStrikeFalcon and SentinelOne register file operations on ESP.
• Change of Secure BootVariables - SetVariable()for PK/KEK/db/db/dbx logged in UEFI eventlog. Windows fixes this through Event ID 1032.
• Violation of Measured Boot -when loading the hasheshes of components are recorded inPCR-registers TPM. Remote Attestation will reveal the discrepancywith baseline.
What software does not see:
• Hardware modification ofSPI-flash through an external programmer - occurs when the system isturned off, EDR is powerless. The machine is off, the software isconnected to the chip directly - what's the EDR?
• SMM-level operations - codein Ring -2 is invisible to the OS, hypervisor and any software-basedmonitoring.
Vendor-specific: Kaspersky EDR Expertincludes UEFI Scanner to check the integrity of the firmware whendownloading. Microsoft Defender for Endpoint supports UEFI Scanner onWindows 10/11 with UEFI. CrowdStrike Falcon monitors file operationson ESP, but firmware integrity monitoring is not included in thestandard configuration. None of these solutions will detect amodification through an external programmer - this requires IntelBoot Guard or hardware Root of Trust.
Firmware Protection Checklist
1. Activate Secure Boot inEnforce mode (not Setup Mode) on all endpoints.
2. Install current dbx updates -use UEFI revocations from Microsoft Patch Tuesday.
3. Include Intel Boot Guard (orAMD Platform Secure Boot) - root of trust moves to CPU hardwarefuses.
4. Check SPI write protection:CHIPSEC module common.spi_lockmust return [PASSED].
5. Configure the BIOS SupervisorPassword at least 12 characters; make sure that the password isstored in a secure NVRAM.
6. Enable Measured Boot andRemote Attement via TPM 2.0 on critical servers.
7. Monitoring ESP entry - rule inEDR/SIEM to create/modify files in /boot/efi/and \EFI\Boot\.
8. Disable CSM (CompatibilitySupport Mode) - it completely bypasses the UEFI trust chain.
9. On Windows 11, use theSecured-core PC, where third-party UEFI CA is not trusted by default.
10. Apply physical protectionSPI-flash - anti-tamper stickers or filling with a compound oncritical devices.
Bypassing the protection of BIOS andSecure Boot is one of those where declared and real security divergethe strongest. Every year, the CVE level of the CVE-2024-7344 levelsurfaces, where the signed Microsoft binary contains such an obviousarchitectural defect - a custom PE-dester instead of standardLoadImage/StartImage - what is the question "what exactly doesMicrosoft check when signing a third-party UEFI code?" ceases tobe rhetorical. According to ESET, this is not the first case ofdetection of “obviously unsafe” signed beinaries, and how manymore such are hidden – no one knows. On audits of firmware ofcorporate laptops, SPI write protection is often not configured, anddbx has not been updated since the purchase of the device. SecureBoot is formally turned on and creates the illusion of protection.The real security of the pre-boot environment begins not with a tickin BIOS Setup, but with Intel Boot Guard + current dbx + ESP +physical protection monitoring. Without any of these components,Secure Boot is a lock on the door without walls. Check your endpointsvia CHIPSEC common.spi_lock and common.secureboot.variables. If yousee [FAILED] - you have the same
