How do you detect bootkit and BCD persistence?

Because a bootkit runs before endpoint agents, detect it from the surrounding evidence. Search process creation for bcdedit options that weaken integrity (testsigning, nointegritychecks, DISABLE_INTEGRITY_CHECKS, debug on), monitor Security Event 4826 and Sysmon Event 9 raw disk reads, and alert on Secure Boot being disabled on a host that previously had it on. Hash the files on the EFI System Partition with Get-FileHash after mounting it, and compare against a golden image. For UEFI implants, rely on firmware integrity tooling and measured-boot attestation, and apply Microsoft’s bootloader revocation guidance to reduce exposure.

Detecting Bootkit, BCD and MBR Persistence: bcdedit, UEFI and the ESP

A bootkit persists by modifying components that run before Windows loads: the MBR or VBR on legacy systems, the bootloader on the EFI System Partition, or UEFI firmware itself. Once installed, it can survive OS reinstalls and disable kernel protections. You cannot rely on endpoint agents to see it execute, so detection concentrates on the preparation (bcdedit changes, raw disk writes), the artifacts (ESP files and Secure Boot state) and anomalies in boot configuration.

Signals at a Glance

Signal	Where	ATT&CK
bcdedit with testsigning, nointegritychecks, debug or loadoptions DISABLE_INTEGRITY_CHECKS	Sysmon 1, command-line logs	T1542.003
Boot Configuration Data loaded or changed (Event 4826)	Security log	T1542.003
Non-system process reading or writing the raw disk (\\.\PhysicalDrive0)	Sysmon 9	T1542.003
Files on the EFI System Partition changed outside servicing	File integrity monitoring, EDR	T1542.003
Secure Boot disabled, or boot loader hash not in the expected set	Attestation, PowerShell inventory	T1542.001
Safe-mode or recovery changes (safeboot, recoveryenabled no) before ransomware	Sysmon 1	T1490

Boot Configuration Tampering

Most bootkit prerequisites and several ransomware tools modify the BCD store with bcdedit.exe. The options that weaken boot-time integrity are well known, and there is almost no legitimate reason to set them on a production endpoint. Search process creation for those arguments:

index=sysmon EventCode=1 Image="*\\bcdedit.exe"
| regex CommandLine="(?i)(testsigning\s+(on|yes)|nointegritychecks|loadoptions\s+.*DISABLE_INTEGRITY_CHECKS|\bdebug\s+on|bootstatuspolicy\s+ignoreallfailures|recoveryenabled\s+no|safeboot|/set\s+\{default\}\s+bootmenupolicy\s+legacy)"
| stats count min(_time) as first values(CommandLine) as cmds values(ParentImage) as parent by host User
| convert ctime(first)
`comment("tune/validate: lab and driver-development hosts legitimately use testsigning and debug")`

Pair this with the Security log. Event 4826 records BCD loading, and a change in the loaded boot options between boots, including Secure Boot policy or kernel debug settings, is worth an alert on servers. Sysmon Event 9 (RawAccessRead) flags non-system processes reading the physical drive, which is how MBR wipers and some bootkit installers operate.

UEFI, Secure Boot and the ESP

Modern bootkits such as BlackLotus (which abused CVE-2022-21894, with later mitigations tracked under CVE-2023-24932) replace or add files on the EFI System Partition and rely on a vulnerable signed bootloader. The strongest control is verification: confirm Secure Boot is on, hash what is on the ESP, and compare it with known-good values.

# PowerShell (elevated): Secure Boot state, BCD options and ESP file hashes
$sb = try { Confirm-SecureBootUEFI } catch { 'LegacyBIOS-or-unsupported' }
"SecureBoot: $sb"

bcdedit /enum all | Select-String -Pattern 'testsigning|nointegritychecks|debug|loadoptions|path'

mountvol S: /S
Get-ChildItem S:\EFI -Recurse -File -ErrorAction SilentlyContinue |
  Get-FileHash -Algorithm SHA256 |
  Select-Object Hash, Path
mountvol S: /D
# tune/validate: collect hashes from a golden image per OS build and compare centrally.

Alert when a host that reported Secure Boot enabled reports it disabled; the transition itself is the signal.
Monitor the ESP with file integrity tooling. Changes outside of Windows servicing windows, or new files such as an additional .efi binary, merit investigation.
Apply the revocation guidance for the bootloader vulnerabilities Microsoft has documented, and track the dbx update status of your fleet.
Firmware implants are outside what an OS agent can inspect; use vendor firmware integrity tooling and measured-boot attestation where you can.

Vetted sources

Use the SigmaHQ bcdedit rules, Elastic’s boot-configuration and MBR/VBR detections, Splunk ESCU content, MITRE CAR analytics and Atomic Red Team T1542.003 tests, together with Microsoft’s published guidance on the bootloader vulnerabilities above. Baseline your own environment, since driver developers and lab hosts legitimately use test-signing.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Boot Configuration Tampering

UEFI, Secure Boot and the ESP

Build Detections That Fire

Persistence Detection

Detection Hub

Windows Service Persistence Detection