# UEFI Secure Boot Bypass via Vendor Apps

Published: 2026-06-18 · Severity: medium
Canonical: https://vorant.io/reports/3d3d6d06-b4d6-5e8d-a301-70d577f92d8f/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

- Vulnerabilities: CVE-2024-7344

## Detection guidance (public sample)

### BCDEdit Disabling Driver Signature Enforcement or Test Signing

ATT&CK: T1553.006

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.

```yaml
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

ATT&CK: T1542.003

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.

```yaml
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

ATT&CK: T1553.006

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.

```yaml
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 free public brief from Vorant Threat Intelligence. When citing, attribute "Vorant" and link https://vorant.io/reports/3d3d6d06-b4d6-5e8d-a301-70d577f92d8f/uefi-secure-boot-bypass-via-vendor-apps.
Full IOC sets, deployable detections, the entity graph, TAXII 2.1 feed and real-time alerts: https://vorant.io/signup