MITRE ATT&CK T1542 Pre-OS Boot: Detecting Firmware, Bootkit and Boot Image Persistence

Code that runs before the operating system survives reinstalls and disk replacement, and sits below the endpoint tools that are meant to find it. MITRE ATT&CK T1542 Pre-OS Boot covers adversaries abusing firmware and boot mechanisms that load before the operating system to persist at a layer where host-based defences cannot see them. In ATT&CK v20 it sits under two tactics, Stealth (TA0005) and Persistence (TA0003), on Windows, Linux, macOS and network devices, with five sub-techniques, five mitigations and a detection strategy for the parent and each sub-technique. This guide is the technique view: how each sub-technique differs, the recorded cases, the telemetry in the v20 detection strategies, and how to respond when one is suspected. It is for detection engineers, endpoint and network teams. The boot chain itself, Secure Boot keys and the BlackLotus certificate rotation are covered in the Firmware and Boot Security Guide, and persistence as a whole in the Persistence Techniques Guide; this page does not repeat them.

Key takeaways

• Five targets, one idea. System firmware (T1542.001), component firmware (T1542.002), boot records (T1542.003 Bootkit), Cisco ROMMON (T1542.004) and network boot images over TFTP (T1542.005) all run before the operating system.
• Detect the write, not the implant. The v20 detection strategies look for raw disk writes, changes to the EFI System Partition and /boot, flashing tools run from unusual parents, and boot variables pointing to non-standard images.
• Attestation is the only view from below. Measured Boot stores hashes of firmware and boot components in the TPM so a remote attestation server can judge the device, independent of an operating system that may be lying.
• Network devices count. Two of the five sub-techniques target routers and switches; configuration and boot variable monitoring is the main signal there.
• Remediation is physical work. A firmware implant is removed by reflashing a known-good image or replacing the board, not by reimaging the disk.

The five sub-techniques

ATT&CK v20 describes T1542 as adversaries overwriting data in boot drivers or firmware such as BIOS and UEFI to persist below the operating system, noting this is particularly difficult to detect because host software-based defences will not see it. The ATT&CK page shows version 2.0, last modified 12 May 2026.

Related but separate techniques: T1601 Modify System Image changes the network device operating system itself, T1495 Firmware Corruption destroys firmware for impact rather than persistence, and T1014 Rootkit hides at the kernel level after boot.

How adversaries use it: real cases

The procedure examples below are from the ATT&CK v20 data, with the sources ATT&CK cites.

LoJax in detail

ESET's research, which ATT&CK cites, found Sednit (APT28) operators writing a malicious UEFI module into SPI flash. At boot the module dropped and ran malware on disk, so it survived operating system reinstallation and disk replacement. The operators used three tools: one to dump low-level system settings, one to save an image of SPI flash, and one to add the module to the image and write it back. All three used a kernel driver bundled with a legitimate hardware utility and signed with a valid certificate. Where platform protections blocked writes, the patching tool exploited a known vulnerability affecting older chipsets. ESET's remediation was to reflash the SPI flash with a clean, board-specific image or replace the motherboard, and its recommendations included keeping UEFI current and using a hardware root of trust such as Intel Boot Guard on supported processors. ESET also noted in an update that Secure Boot did not protect against this rootkit, a reminder that Secure Boot verifies the boot loader, not the firmware doing the verifying.

Cyclops Blink in detail

The NCSC malware analysis report (23 February 2022) describes Cyclops Blink waiting for a firmware upgrade image, replacing the legitimate installer, adding itself and a startup script to the image, and recalculating the image HMAC, which was possible because the devices used a hard-coded key, so the modified image passed verification. The botnet had been active since at least June 2019. The lesson: a firmware update path is part of the attack surface, and image verification is only as strong as the key behind it.

What to detect and where

The table combines the parent strategy DET0278 with the sub-technique strategies. Log sources are as named in ATT&CK v20; the detection ideas are NHI Mgmt Group recommendations.

Measured boot and attestation

Microsoft documents four layers in the Windows boot process: Secure Boot verifies the boot loader signature, Trusted Boot has the boot loader and kernel verify each later component, Early Launch Anti-Malware (ELAM) checks boot drivers before other non-Microsoft drivers load, and Measured Boot records hashes of the firmware, boot loader, boot drivers and everything loaded before the anti-malware driver into the TPM. Measured Boot requires UEFI 2.3.1 and a TPM, plus a remote attestation client and server. At the end of startup the TPM signs the log with a key from the attestation server, which judges the device healthy or sends it to a quarantine network. Attestation is the detection that does not depend on the compromised layer telling the truth; tie it to conditional access so an unhealthy device loses access rather than raising a ticket.

Keeping the noise down

• Know your flashers: list the vendor firmware update tools and agents in use and alert on any other process writing to firmware or raw disk.
• Use change windows: boot partition and firmware changes outside an approved patch window or change ticket are the signal; inside them, verify versions match the vendor release.
• Watch reboots: an unexpected reboot or reload shortly after a boot change is common to every sub-technique.

Mitigations

ATT&CK v20 maps five mitigations to T1542, with sub-technique specifics for network devices (M1031 Network Intrusion Prevention and M1028 Operating System Configuration also apply to TFTP Boot). Concrete settings are NHI Mgmt Group guidance.

Where identity fits

Most pre-OS boot techniques need administrative access first: local administrator or root to write raw disk or flash firmware, or privileged network device access to change boot variables. The credentials behind firmware update agents, baseboard management controllers and network automation accounts are therefore high-value non-human identities. Keep them in a vault, scope them to the devices they manage, log every use, and rotate them after any suspected boot-level compromise, since an implant that survives a reimage can capture them again.

Responding to a suspected pre-OS implant

1. Preserve first: capture the firmware image and boot records with vendor or approved forensic tools before any update, alongside TPM event logs and EDR data.
2. Isolate: move the device to a quarantine network; for network devices, route around them if possible.
3. Compare: check the captured firmware and boot components against the vendor's known-good image for that model and version.
4. Remediate below the OS: reflash firmware with a clean board-specific image, or replace the board; rebuild boot records; for network devices, reload a verified image and ROMMON from trusted media.
5. Rotate credentials: rotate local administrator, BMC and device credentials and any service account used on the host.
6. Hunt across the fleet: look for the same flashing tool, driver or boot variable change elsewhere.

Detailed response steps are in the Firmware and Bootkit Compromise Playbook.

How to test your coverage

1. Telemetry check: on a lab host, write a benign file to the EFI System Partition and run a firmware inventory tool from an unusual parent; confirm Sysmon 9 and 11 or auditd events reach the SIEM and alert.
2. Attestation check: change a boot setting on a lab device and confirm the attestation service marks it unhealthy and access policy reacts.
3. Network device check: on a lab router, change the boot variable and confirm the configuration change alert fires.
4. Firmware inventory: confirm you can report firmware version for every laptop, server and network device model.
5. Record results: update the ATT&CK coverage map per sub-technique.

Metrics

• Secure Boot coverage: share of endpoints and servers with Secure Boot enabled.
• Attestation coverage: share of high-value hosts reporting Measured Boot health.
• Firmware currency: share of devices on the vendor's current firmware for their model.
• Unexplained boot changes: boot partition or boot variable changes without a change record, per month.
• Integrity check cadence: share of network devices with an image integrity check in the last 90 days.

Framework mapping

Practitioner checklist

• Enable Secure Boot fleet-wide and Measured Boot with attestation on high-value hosts.
• Inventory firmware versions for every model and put firmware in the patch programme.
• Collect Sysmon 9 and 11 for the EFI System Partition and raw disk access; auditd for /boot and flashing tools.
• Alert on network device boot variable changes, ROMMON upgrades and TFTP image transfers.
• Restrict firmware tools and boot configuration to a small admin group; vault BMC and device credentials.
• Schedule image and firmware integrity checks against vendor hashes.
• Keep a tested reflash procedure and known-good images per model.
• Test detections and attestation each quarter in a lab.

Standards and references

• MITRE ATT&CK: Pre-OS Boot (T1542)
• Microsoft Learn: Secure the Windows boot process
• ESET WeLiveSecurity: LoJax, first UEFI rootkit found in the wild
• NCSC: Cyclops Blink malware analysis report
• MITRE ATT&CK: Boot Integrity (M1046)
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: ATT&CK Persistence Tactic · ATT&CK Stealth and Defense Impairment Tactics Guide · Hardware Root of Trust Guide · Linux Secure Boot and Shim Guide · Network Device Syslog and Configuration Change Detection Guide