Safeguard
Application Security•

Detecting Pre-OS Boot Persistence (T1542)

Malware that runs before the operating system escapes host defenses. How firmware and boot persistence works, what to monitor and how secure boot and TPM help.

Safeguard Security Team
3 min read

Pre-OS Boot (T1542) is a Stealth and Persistence technique. MITRE lists Linux, macOS, network devices and Windows. During start up, a computer loads firmware and various services before the operating system takes control, and those programs decide how execution flows from then on.

How attackers use it

MITRE explains that adversaries may overwrite data in boot drivers or in firmware such as BIOS and UEFI, to persist at a layer below the operating system. That makes it difficult to find, because malware at this level will not be seen by host software based defenses.

The technique has sub-techniques for System Firmware, Component Firmware, Bootkit and ROMMONkit, each aimed at a different layer. This parent entry covers the shared idea.

How to detect it

MITRE's detection strategy lists signals by platform:

  • Windows: unusual changes to boot records (MBR, VBR) or EFI partitions that do not match patch cycles or OS upgrades, firmware update tools run from unexpected parent processes, direct writes to raw disk sectors, and then abnormal boot configuration changes followed by unsigned driver loads.
  • Linux: writes to the boot or EFI folders outside package manager updates, kernel log and auditd events about overwriting bootloader binaries such as grub or shim, and unexpected use of efibootmgr or dd writing to disk devices followed by boot parameter changes.
  • macOS: abnormal changes to EFI firmware binaries or NVRAM parameters not linked to OS updates, calls to bless or nvram from untrusted parent processes, and unsigned kext loads after EFI variable tampering.
  • Network devices: unexpected firmware image uploads over TFTP, FTP or SCP, changes to boot image pointers, boot variables redirected to non standard images, and unexplained reboots right after firmware changes.

The unifying clue is a boot related change that has no matching patch or maintenance record.

How to reduce the risk

MITRE lists five mitigations:

  1. Boot Integrity: use TPM technology and a secure or trusted boot process, and check the integrity of the existing BIOS or EFI to see if it is vulnerable to modification.
  2. Update Software: patch the BIOS and EFI as needed.
  3. Privileged Account Management: make sure the right permissions are in place to stop adversaries reaching the privileged accounts needed for these actions.
  4. Audit: scan systems, permissions, insecure software and configurations to find weaknesses.
  5. Limit Access to Resource Over Network: restrict access to file shares, remote access and unnecessary services, for example with network concentrators or RDP gateways.

Check your own environment

Read only Windows PowerShell checks (run as administrator):

Confirm-SecureBootUEFI
Get-Tpm

On Linux:

mokutil --sb-state

Also check that firmware versions are current on each hardware model, and that network devices boot only signed images.

Quick check

Why can antivirus not see pre-OS malware?

It runs before the operating system loads, at a layer below host software based defenses, so those tools are not in a position to inspect it.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.