UEFI Secure Boot Bypass via Vendor Apps
Vendor-signed UEFI applications can be abused BYOVD-style to bypass Secure Boot and run unsigned code before the OS loads.
CERT/CC discloses that multiple vendor-signed UEFI applications, including bootloaders and shell utilities, contain functionality that can manipulate memory, NVRAM variables, or load raw drivers without adequate access controls. Because these binaries are legitimately signed and trusted by the UEFI Authorized Signature Database, an attacker with administrative privileges or physical access can abuse them to circumvent Secure Boot and execute arbitrary code during the pre-boot phase, before the operating system or any endpoint security tooling initializes.
The impact is significant on systems where the affected vendor certificates are trusted: successful exploitation can lead to persistent platform compromise, including loading of unsigned or malicious kernel components that survive reboots and OS reinstalls, and that are invisible to standard EDR and security controls. ESET researcher Martin Smolar identified the vulnerable applications; the referenced ESET write-up on CVE-2024-7344 describes the same class of Secure Boot bypass via a signed UEFI shell/bootloader.
Mitigation requires vendors to issue corrected UEFI application binaries and, critically, for administrators to update the UEFI Forbidden Signature Database (DBX) to revoke the vulnerable signed binaries so they can no longer execute during boot. CERT/CC also references a public DBX audit tool to help administrators verify their systems' revocation status.
Mentioned in this report
Detection guidance
BCDEdit Disabling Driver Signature Enforcement or Test Signing
Detects use of bcdedit.exe to disable driver signature enforcement, enable test signing, or ignore boot failures - a precursor step attackers use to load unsigned/malicious boot components after bypassing Secure Boot trust. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: BCDEdit Disabling Driver Signature Enforcement or Test Signing
description: Detects bcdedit.exe invocations that weaken code signing policy enforcement
at boot time (testsigning, nointegritychecks, or ignoring boot failures). This is
a common step after a Secure Boot/UEFI bypass to allow unsigned kernel components
to load persistently.
tags:
- attack.defense-evasion
- attack.t1553.006
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: \bcdedit.exe
CommandLine|contains:
- testsigning
- nointegritychecks
- ignoreallfailures
- loadoptions
filter_known_dev_tools:
CommandLine|contains:
- WDKTestCert
- VisualStudio
condition: selection and not filter_known_dev_tools
falsepositives:
- Driver developers enabling test signing on dedicated development VMs
- Legitimate use of bcdedit by IT for boot troubleshooting (rare, should be investigated)
level: high
id: f873ed27-84f2-5823-8ded-4f169c9d753a
status: experimental
author: Vorant
Unsigned File Write to EFI System Partition Boot Path
Detects file creation or modification under the EFI System Partition boot directories outside of Windows Update/firmware update processes, consistent with planting a malicious or vulnerable signed bootloader/shell to bypass Secure Boot. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Unsigned File Write to EFI System Partition Boot Path
description: Detects processes writing files into the EFI\Boot or EFI\Microsoft boot
directories. Legitimate changes here are almost exclusively performed by TrustedInstaller,
Windows Update, or OEM firmware update utilities; other writers are suspicious and
align with bootkit-style persistence abusing vulnerable signed UEFI applications.
tags:
- attack.persistence
- attack.t1542.003
logsource:
category: file_event
product: windows
detection:
selection:
TargetFilename|contains:
- \EFI\Boot\
- \EFI\Microsoft\Boot\
TargetFilename|endswith:
- .efi
- .img
filter_trusted_writers:
Image|endswith:
- \TrustedInstaller.exe
- \TiWorker.exe
- \poqexec.exe
- \wuauclt.exe
condition: selection and not filter_trusted_writers
falsepositives:
- OEM firmware/BIOS update utilities legitimately updating boot files
- Manual dual-boot or recovery media setup by administrators
level: high
id: 14cfacb8-43ef-51fb-9c72-9efb6803c2de
status: experimental
author: Vorant
Registry Modification of Secure Boot Policy Variables
Detects direct modification via reg.exe or PowerShell of registry keys that expose Secure Boot / UEFI signature database state on Windows, which is unusual outside of vendor firmware tooling and can indicate an attempt to tamper with or query Secure Boot enforcement state as part of a bypass. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Registry Modification of Secure Boot Policy Variables
description: Detects command-line tools (reg.exe, PowerShell) writing to the SecureBoot
registry hive that mirrors UEFI Secure Boot/Signature Database state. Legitimate
change is normally done only by firmware/OS update components, not interactively
via reg.exe or scripts.
tags:
- attack.defense-evasion
- attack.t1553.006
logsource:
category: registry_set
product: windows
detection:
selection:
TargetObject|contains: \SYSTEM\CurrentControlSet\Control\SecureBoot
filter_system_process:
Image|endswith:
- \svchost.exe
- \services.exe
condition: selection and not filter_system_process
falsepositives:
- OEM firmware configuration utilities that legitimately update Secure Boot state
through the registry
- Group Policy or MDM tooling reading/writing Secure Boot compliance flags
level: medium
id: 87db92af-8793-5763-b3fc-58615abe18d9
status: experimental
author: Vorant
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://kb.cert.org/vuls/id/457458
This is the public brief
Subscribers see the full picture: extracted IOCs, ready-to-deploy detections (Sigma, Splunk, KQL, Elastic, YARA, Suricata), the entity graph, TAXII 2.1 feed and real-time alerts matched to your sectors.
Start free