Pre-OS Boot T1542
- Tactics
- Persistence, Stealth
- Platforms
- Linux, macOS, Network Devices, Windows
- Version
- 2.0
- Created
- 13 November 2019
- Last modified
- 12 May 2026
Adversaries may abuse Pre-OS Boot mechanisms as a way to establish persistence on a system. During the booting process of a computer, firmware and various startup services are loaded before the operating system. These programs control flow of execution before the operating system takes control.[1]
Offense vs defense T1542
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Pre-OS Boot detection strategy DET0278
MITRE names one behaviour worth catching for this technique and breaks it into 4 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for T1542 Pre-OS Boot
AN0774 · Windows
Unusual modification of boot records (MBR, VBR) or EFI partitions not associated with legitimate patch cycles or OS upgrades. Registry or WMI events associated with firmware update tools executed from unexpected parent processes. API calls (e.g., DeviceIoControl) writing directly to raw disk sectors. Subsequent abnormal boot configuration changes followed by unsigned driver loads.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | WinEventLog:Security | EventCode=4688 |
| File CreationDC0039 | WinEventLog:Sysmon | EventCode=11 |
| Drive AccessDC0054 | WinEventLog:Sysmon | EventCode=9 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AllowedFirmwareUpdateTools | Legitimate vendor tools or processes authorized to modify firmware or boot records. |
| TimeWindow | Correlating boot-sector modification with subsequent reboot events. |
| EntropyThreshold | Heuristic threshold for detecting obfuscated/packed boot code. |
AN0775 · Linux
Detection of writes to /boot or EFI directories outside of expected package manager updates. Monitoring kernel log and auditd events for attempts to overwrite bootloader binaries (e.g., grub, shim). Unexpected execution of efibootmgr or dd writing to /dev/sdX devices followed by boot parameter changes.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| File ModificationDC0061 | auditd:SYSCALL | open, write: Modification of /boot/grub/* or /boot/efi/* |
| Command ExecutionDC0064 | auditd:EXECVE | exec: Execution of dd, efibootmgr, or flashrom modifying firmware/boot partitions |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| PackageManagerUpdateWhitelist | Allowlist of legitimate grub/shim updates via apt, yum, or rpm. |
| FilesystemPaths | Directories (e.g., /boot/efi, /boot/grub) monitored for unauthorized modification. |
AN0776 · macOS
Abnormal modification of EFI firmware binaries in /System/Library/CoreServices/ or NVRAM parameters not associated with OS updates. Unified logs capturing calls to bless or nvram commands executed from untrusted parent processes. Sudden unsigned kext loads after EFI variable tampering.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | macos:unifiedlog | Execution of bless or nvram modifying boot parameters |
| File ModificationDC0061 | macos:unifiedlog | Modification of /System/Library/CoreServices/boot.efi |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AllowedBootUtilities | Known Apple-signed processes responsible for firmware updates. |
| BootParamBaseline | Baseline set of allowed NVRAM boot parameters for anomaly detection. |
AN0777 · Network Devices
Unexpected firmware image uploads via TFTP/FTP/SCP. Configuration changes modifying boot image pointers. Logs showing boot variable redirection to non-standard images. Anomalous reboots immediately following firmware changes not tied to patch schedules.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Firmware ModificationDC0004 | networkdevice:config | Boot variable modified to point to non-standard or unsigned image |
| Drive ModificationDC0046 | networkdevice:firmware | Unexpected firmware image upload events via TFTP/FTP/SCP |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ApprovedFirmwareHashes | Known good firmware image hashes allowed for boot. |
| MaintenanceWindows | Timeframes during which firmware updates are expected. |
Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses.
Use Trusted Platform Module technology and a secure or trusted boot process to prevent system integrity from being compromised. Check the integrity of the existing BIOS or EFI to determine if it is vulnerable to modification.
Prevent access to file shares, remote access to systems, unnecessary services. Mechanisms to limit access may include use of network concentrators, RDP gateways, etc.
Ensure proper permissions are in place to help prevent adversary access to privileged accounts necessary to perform these actions
Patch the BIOS and EFI as necessary.