Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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).[1] 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.[2]

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.[3][4]

EnterpriseT1542.003Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.
Analyst 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.

Official MITRE ATT&CK definition

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).[1] 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.[2]

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.[3][4]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1542 Pre-OS Boot This object subtechnique of Pre-OS Boot.
Enterprise T1067 Bootkit Bootkit revoked by this object.
Associated objects

Groups, software, and campaigns

Group Enterprise

G0096: APT41

APT41 is a threat group that researchers have assessed as Chinese state-sponsored espionage group that also conducts financially-motivated operations. Active since at least 2012, APT41 has been observed targeting various industries, including but not limited to healthcare, telecom, technology, finance, education, retail and video game industries in 14 countries.[1] Notable behaviors include using a wide range of malware and tools to complete mission objectives. APT41 overlaps at least partially with public reporting on groups including BARIUM and Winnti Group.[2][3]

Group Enterprise

G0032: Lazarus Group

Lazarus Group is a North Korean state-sponsored cyber threat group attributed to the Reconnaissance General Bureau (RGB). [1] [2] Lazarus Group has been active since at least 2009 and is reportedly responsible for the November 2014 destructive wiper attack on Sony Pictures Entertainment, identified by Novetta as part of Operation Blockbuster. Malware used by Lazarus Group correlates to other reported campaigns, including Operation Flame, Operation 1Mission, Operation Troy, DarkSeoul, and Ten Days of Rain.[3]

North Korea’s cyber operations have shown a consistent pattern of adaptation, forming and reorganizing units as national priorities shift. These units frequently share personnel, infrastructure, malware, and tradecraft, making it difficult to attribute specific operations with high confidence. Public reporting often uses “Lazarus Group” as an umbrella term for multiple North Korean cyber operators conducting espionage, destructive attacks, and financially motivated campaigns.[4][5][6]

Group Enterprise

G0007: APT28

APT28 is a threat group that has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) 85th Main Special Service Center (GTsSS) military unit 26165.[1][2] This group has been active since at least 2004.[3][4][5][6][7][8][9][10][11][12][13]

APT28 reportedly compromised the Hillary Clinton campaign, the Democratic National Committee, and the Democratic Congressional Campaign Committee in 2016 in an attempt to interfere with the U.S. presidential election.[5] In 2018, the US indicted five GRU Unit 26165 officers associated with APT28 for cyber operations (including close-access operations) conducted between 2014 and 2018 against the World Anti-Doping Agency (WADA), the US Anti-Doping Agency, a US nuclear facility, the Organization for the Prohibition of Chemical Weapons (OPCW), the Spiez Swiss Chemicals Laboratory, and other organizations.[14] Some of these were conducted with the assistance of GRU Unit 74455, which is also referred to as Sandworm Team.

Malware Enterprise

S0484: Carberp

Carberp is a credential and information stealing malware that has been active since at least 2009. Carberp's source code was leaked online in 2013, and subsequently used as the foundation for the Carbanak backdoor.[1][2][3]

Windows
Malware Enterprise

S0689: WhisperGate

WhisperGate is a multi-stage wiper designed to look like ransomware that has been used against multiple government, non-profit, and information technology organizations in Ukraine since at least January 2022.[1][2][3]

Windows
Malware Enterprise

S0266: TrickBot

TrickBot is a Trojan spyware program written in C++ that first emerged in September 2016 as a possible successor to Dyre. TrickBot was developed and initially used by Wizard Spider for targeting banking sites in North America, Australia, and throughout Europe; it has since been used against all sectors worldwide as part of "big game hunting" ransomware campaigns.[1][2][3][4]

Windows
Malware Enterprise

S0182: FinFisher

FinFisher is a government-grade commercial surveillance spyware reportedly sold exclusively to government agencies for use in targeted and lawful criminal investigations. It is heavily obfuscated and uses multiple anti-analysis techniques. It has other variants including Wingbird. [1] [2] [3] [4] [5]

WindowsAndroid
Relationship explorer

All related ATT&CK context

uses · Malware S0484: Carberp Enterprise uses · Malware S0689: WhisperGate Enterprise subtechnique of · Technique T1542: Pre-OS Boot Enterprise revoked by · Technique T1067: Bootkit Enterprise detects · Detection Strategy DET0150: Detection Strategy for File Creation or Modification of Boot Files Enterprise uses · Malware S0266: TrickBot Enterprise mitigates · Mitigation M1046: Boot Integrity Enterprise uses · Malware S0112: ROCKBOOT Enterprise uses · Group G0096: APT41 Enterprise uses · Malware S0114: BOOTRASH Enterprise uses · Malware S0182: FinFisher Enterprise uses · Group G0032: Lazarus Group Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Group G0007: APT28 Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1046: Boot Integrity

Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:

Implementation of Secure Boot:

- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.

Utilization of TPMs:

- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.

Enable Bootloader Passwords:

- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.

Runtime Integrity Monitoring:

- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
1f1cbee1ebd49eb3...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 1f1cbee1ebd4…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Mandiant M Trends 2016

    Mandiant. (2016, February 25). Mandiant M-Trends 2016. Retrieved November 17, 2024.

    Open source URL
  2. [2]
    Lau 2011

    Lau, H. (2011, August 8). Are MBR Infections Back in Fashion? (Infographic). Retrieved November 13, 2014.

    Open source URL
  3. [3]
    Microsoft Security

    Microsoft Incident Response. (2023, April 11). Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign. Retrieved February 12, 2025.

    Open source URL
  4. [4]
    welivesecurity

    Martin Smolár. (2023, March 1). BlackLotus UEFI bootkit: Myth confirmed. Retrieved February 11, 2025.

    Open source URL
  5. [5]
    mitre-attack T1542.003
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use