T1542.003: Bootkit
Adversaries may use bootkits to persist on systems. A bootkit is a malware variant that modifies the boot sectors of a hard drive, allowing malicious code to execute before a computer's operating system has loaded. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
In BIOS systems, a bootkit may modify the Master Boot Record (MBR) and/or Volume Boot Record (VBR).CitationMandiant M Trends 2016 The MBR is the section of disk that is first loaded after completing hardware initialization by the BIOS. It is the location of the boot loader. An adversary who has raw access to the boot drive may overwrite this area, diverting execution during startup from the normal boot loader to adversary code.CitationLau 2011
The MBR passes control of the boot process to the VBR. Similar to the case of MBR, an adversary who has raw access to the boot drive may overwrite the VBR to divert execution during startup to adversary code.
In UEFI (Unified Extensible Firmware Interface) systems, a bootkit may instead create or modify files in the EFI system partition (ESP). The ESP is a partition on data storage used by devices containing UEFI that allows the system to boot the OS and other utilities used by the system. An adversary can use the newly created or patched files in the ESP to run malicious kernel code.CitationMicrosoft SecurityCitationwelivesecurity
Security context for executives and security teams
Bootkits matter because they target the startup path of Linux and Windows systems before the operating system is fully in control. That makes persistence and stealth unusually durable: normal endpoint cleanup may miss the malicious code if responders do not inspect the boot path, MBR/VBR, or UEFI EFI System Partition.
Executive priority
Treat suspected bootkit activity as a high-consequence persistence scenario, not routine malware cleanup. Leadership should ask whether critical systems have boot integrity controls, whether privileged access to raw disks and boot partitions is tightly governed, and whether incident response procedures include evidence collection and remediation below the operating system. This technique is especially relevant to resilience, audit evidence for privileged control, and recovery confidence after a serious compromise.
Technical view
ATT&CK defines Bootkit as a Linux and Windows sub-technique of Pre-OS Boot used for stealth and persistence. Defenders should validate monitoring for creation or modification of boot-related files, especially in UEFI EFI System Partition locations, and assess whether changes to BIOS-era MBR/VBR areas can be detected or investigated. Because official ATT&CK detection text is not provided, detection engineering should anchor on the related DET0150 strategy for boot file creation/modification, plus local boot integrity and privileged account telemetry.
Likely telemetry
- Boot file creation or modification events, including files in the EFI System Partition where available
- Evidence of access to or modification of MBR, VBR, or raw boot drive areas
- Privileged account activity involving SYSTEM, root, administrative, or equivalent access
- Boot integrity, secure boot, or hardware-rooted trust status and failure events where implemented
- Incident response disk images or forensic artifacts from boot partitions and boot sectors
Detection direction
- Validate whether SOC tooling can see boot file changes on Linux and Windows endpoints, not just user-space process and file activity.
- Tune detections around unusual privileged writes to boot partitions or boot-related paths while accounting for legitimate OS updates, bootloader changes, and administrative recovery activity.
- Confirm whether boot integrity telemetry is centrally collected and retained enough to support incident decisions.
- Use relationship context carefully: ATT&CK links this technique to several groups and software families, but local detection should focus on the behavior rather than assuming attribution.
Mitigation priorities
- Prioritize Boot Integrity controls for systems where hardware and operating system support them, including mechanisms that verify the boot process and critical components.
- Strengthen Privileged Account Management so only tightly controlled administrative, root, or SYSTEM-level workflows can alter boot-critical areas.
- Include boot-sector, bootloader, and EFI System Partition checks in incident response playbooks for high-severity persistence cases.
- Ensure recovery procedures can rebuild or reimage affected systems from trusted media when boot-level tampering is suspected.
Additional notes and limits
This object is ATT&CK T1542.003 Bootkit, an enterprise sub-technique under Pre-OS Boot. ATT&CK relationships include mitigations M1026 Privileged Account Management and M1046 Boot Integrity, detection strategy DET0150 for file creation or modification of boot files, and historical relationships to named groups and software such as APT28, Lazarus Group, APT41, ROCKBOOT, BOOTRASH, FinFisher, TrickBot, Carberp, and WhisperGate.
Official ATT&CK detection guidance for this technique is not provided in the supplied object. Practical coverage depends on local endpoint visibility, boot integrity configuration, access logging, forensic readiness, and whether BIOS/UEFI boot artifacts are monitored in the environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Bootkit
Adversaries may use bootkits to persist on systems. A bootkit is a malware variant that modifies the boot sectors of a hard drive, allowing malicious code to execute before a computer's operating system has loaded. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
In BIOS systems, a bootkit may modify the Master Boot Record (MBR) and/or Volume Boot Record (VBR).CitationMandiant M Trends 2016 The MBR is the section of disk that is first loaded after completing hardware initialization by the BIOS. It is the location of the boot loader. An adversary who has raw access to the boot drive may overwrite this area, diverting execution during startup from the normal boot loader to adversary code.CitationLau 2011
The MBR passes control of the boot process to the VBR. Similar to the case of MBR, an adversary who has raw access to the boot drive may overwrite the VBR to divert execution during startup to adversary code.
In UEFI (Unified Extensible Firmware Interface) systems, a bootkit may instead create or modify files in the EFI system partition (ESP). The ESP is a partition on data storage used by devices containing UEFI that allows the system to boot the OS and other utilities used by the system. An adversary can use the newly created or patched files in the ESP to run malicious kernel code.CitationMicrosoft SecurityCitationwelivesecurity
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.
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.
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.