Vendor shim bootloaders enable Secure Boot bypass
Outdated vendor forks of the open-source shim UEFI bootloader can be exploited to bypass Secure Boot and execute code before the OS loads.
Sourcekb.cert.org — open the original
What to check
- Applies to
- The 1 CVE named below. Whether you run an affected version is not assessed: check the versions the source lists.
- Exploitation
- No exploitation in the wild and no public exploit is recorded for the CVEs named.
ESET researcher Martin Smolar identified multiple vendor-forked versions of the open-source shim UEFI bootloader (primarily version 0.9 and earlier) that were never updated after upstream security fixes were released. Because these outdated shim bootloaders remain signed by Microsoft's UEFI CA 2011 certificate and have not been added to the Forbidden Signature Database (DBX), they continue to be trusted by Secure Boot-enabled systems even when otherwise fully patched, creating a long-standing supply-chain exposure across the UEFI ecosystem.
An attacker with administrative access or the ability to tamper with the boot chain could leverage one of these vulnerable shim binaries in a BYOVD-style attack to execute arbitrary code during early boot, before the operating system and most security tooling (including EDR) initialize. This can lead to persistent, stealthy compromise that survives reboots and even OS reinstallation, since the malicious code operates below the visibility of OS-level defenses.
Microsoft will add the affected bootloaders to the DBX revocation list as part of coordinated disclosure. Organizations should apply vendor firmware/bootloader updates and subsequent DBX updates (in the correct DB-then-DBX order to avoid bricking systems), and use audit tools such as Check-UEFISecureBootVariables or uefi-dbx-audit to verify exposure across fleets, particularly in large-scale enterprise, cloud, and virtualization environments.
Mentioned in this report
Detection guidance
Suspicious EFI Bootloader File Write to EFI System Partition
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects creation or modification of .efi bootloader files (e.g. shim, grub) within EFI System Partition paths outside of expected OS update processes, consistent with planting a vulnerable/outdated shim for a Secure Boot bypass bootkit. 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: Suspicious EFI Bootloader File Write to EFI System Partition
logsource:
category: file_event
product: windows
detection:
selection:
TargetFilename|contains:
- \EFI\Boot\
- \EFI\Microsoft\Boot\
- \EFI\ubuntu\
- \EFI\redhat\
- \EFI\centos\
- \EFI\fedora\
- \EFI\opensuse\
TargetFilename|endswith:
- .efi
filter:
Image|endswith:
- \TiWorker.exe
- \TrustedInstaller.exe
- \dism.exe
- \poqexec.exe
- \bootim.exe
condition: selection and not filter
falsepositives:
- Legitimate Windows Update or OS servicing operations updating boot components
- OS installation, imaging, or dual-boot bootloader (GRUB) maintenance by administrators
- Firmware/bootloader vendor patch deployment tools
level: high
tags:
- attack.t1542.003
- attack.persistence
id: 0fe86d8c-52a8-5398-b64f-d72befd2e908
status: experimental
author: Vorant
Boot Configuration Data Modification via bcdedit Referencing Custom Loader Path
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects use of bcdedit.exe to create or modify boot entries pointing to non-default bootloader paths, which can be used to chain-load a vulnerable/outdated signed shim binary as part of a Secure Boot bypass bootkit. 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: Boot Configuration Data Modification via bcdedit Referencing Custom Loader
Path
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: \bcdedit.exe
CommandLine|contains:
- /set
- /create
- /copy
suspicious_path:
CommandLine|contains:
- path
- .efi
filter:
CommandLine|contains:
- \Windows\System32\winload.efi
- \Windows\System32\Boot\winload.efi
- \bootmgfw.efi
condition: selection and suspicious_path and not filter
falsepositives:
- Legitimate dual-boot configuration or recovery environment setup by administrators
- OEM/vendor bootloader repair or firmware update tooling
level: medium
tags:
- attack.t1542.003
- attack.stealth
id: 4775ce79-33ae-5dee-9f36-a46e28460a31
status: experimental
author: Vorant
EFI System Partition Manually Mounted via mountvol or diskpart
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects manual mounting of the hidden EFI System Partition using mountvol or diskpart, a common precursor step to reading, replacing, or planting bootloader files (e.g. an outdated vulnerable shim) for a bootkit-based Secure Boot 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: EFI System Partition Manually Mounted via mountvol or diskpart
logsource:
category: process_creation
product: windows
detection:
selection_mountvol:
Image|endswith: \mountvol.exe
CommandLine|contains: ':'
selection_diskpart:
Image|endswith: \diskpart.exe
esp_indicator:
CommandLine|contains:
- EFI
- System Partition
- ESP
condition: (selection_mountvol or selection_diskpart) and esp_indicator
falsepositives:
- Administrators performing legitimate boot repair, dual-boot setup, or firmware update
tasks
- Imaging and deployment tools (e.g. MDT, SCCM) accessing the EFI partition during
OS provisioning
level: medium
tags:
- attack.t1542.003
- attack.stealth
id: ebd2f2e4-5cc3-5062-ac6a-ae3463bebc49
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/616257
Free public brief. The indicators and the detections with Splunk SPL already written (plus Elastic and KQL where they apply) are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its extracted indicators, its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply), and live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,436 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs