T1542: Pre-OS Boot
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]
Adversaries may overwrite data in boot drivers or firmware such as BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) to persist on systems at a layer below the operating system. This can be particularly difficult to detect as malware at this level will not be detected by host software-based defenses.
Analyst context for executives and security teams
Pre-OS Boot persistence matters because it targets the layer that starts the machine before the operating system and normal endpoint defenses are in control. If firmware, boot drivers, boot sectors, or network-device boot mechanisms are modified, the organization may face persistence that survives routine cleanup and is hard for host-based tools to see.
Executive priority
Treat T1542 as a resilience and assurance issue, not just a malware issue. Leaders should ask whether critical Windows, Linux, macOS, and network-device assets have boot integrity controls, firmware update governance, privileged access restrictions, and audit evidence. For incident response, this technique raises the threshold for declaring eradication because remediation may require validating firmware and boot components, not only reimaging the operating system.
Technical view
SOC and IR teams should validate coverage around the boot chain and privileged changes on supported platforms: Linux, macOS, Network Devices, and Windows. Because ATT&CK provides no official detection text for this parent technique, teams should use the related detection strategy DET0278 where available and map monitoring to the sub-technique areas: system firmware, bootkits, ROMMONkit, and TFTP Boot. Prioritize evidence that can show unauthorized firmware, bootloader, boot-sector, boot-driver, or network-device boot configuration changes.
Likely telemetry
- Firmware and BIOS/UEFI configuration state and change records where available
- Secure boot or boot integrity status and related failure events
- Firmware, driver, operating system, and network-device image update logs
- Privileged account authentication, authorization, and administrative action logs
- Network-device boot configuration, image source, ROMMON, and TFTP-related records where applicable
Detection direction
- Validate that detection engineering has coverage below the normal operating-system layer where feasible; host software alone may not observe this behavior.
- Baseline approved firmware versions, boot settings, bootloaders, and network-device images, then alert or investigate unauthorized drift.
- Correlate boot integrity changes with privileged account activity and approved change windows to reduce false positives from legitimate firmware or system updates.
- For network devices, review boot source configuration and use of TFTP or ROMMON-related mechanisms against authorized administration patterns.
- Use DET0278 as the ATT&CK-linked detection strategy reference, but confirm local data sources and analytic logic because the parent technique has no supplied official detection procedure.
Mitigation priorities
- Start with Boot Integrity controls to verify the boot process and resist tampering with firmware, bootloaders, and critical components.
- Apply Privileged Account Management so only authorized administrators can change firmware, boot settings, system images, or network-device boot configuration.
- Limit access to network resources used for administration or boot image delivery, including file shares, remote services, and centralized image sources.
- Maintain regular auditing of configuration, privileged activity, firmware state, and boot-related settings for security review and compliance evidence.
- Keep operating systems, drivers, applications, and firmware updated through governed software update processes.
Analyst notes and limits
The relationship set is useful because it shows this parent technique is mitigated by boot integrity, privileged access control, network access restriction, auditing, and software updates, and it has sub-techniques covering system firmware, bootkits, ROMMONkit, and TFTP Boot. The practical defensive question is whether the organization can prove boot-path integrity for critical assets and network devices, especially during incident eradication.
The supplied ATT&CK object does not include official detection guidance or procedure examples. This take therefore avoids claims about active exploitation, actor use, or guaranteed detection. Local platform capabilities, hardware support, firmware management practices, and network-device logging determine how much visibility and control are actually available.
Pre-OS Boot
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]
Adversaries may overwrite data in boot drivers or firmware such as BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) to persist on systems at a layer below the operating system. This can be particularly difficult to detect as malware at this level will not be detected by host software-based defenses.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1542.003 | Bootkit Sub-technique | Bootkit subtechnique of this object. |
| Enterprise | T1542.005 | TFTP Boot Sub-technique | TFTP Boot subtechnique of this object. |
| Enterprise | T1542.002 | Component Firmware Sub-technique | Component Firmware subtechnique of this object. |
| Enterprise | T1542.004 | ROMMONkit Sub-technique | ROMMONkit subtechnique of this object. |
| Enterprise | T1542.001 | System Firmware Sub-technique | System Firmware subtechnique of this object. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 2fa72486e971… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Wikipedia Booting
Wikipedia. (n.d.). Booting. Retrieved November 13, 2019.
Open source URL -
[2]
mitre-attack T1542Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.