DC0004: Firmware Modification
Changes made to firmware, which may include its settings, configurations, or underlying data. This can encompass alterations to the Master Boot Record (MBR), Volume Boot Record (VBR), or other firmware components critical to system boot and functionality. Such modifications are often indicators of adversary activity, including malware persistence and system compromise. Examples:
- Changes to Master Boot Record (MBR): Modifying the MBR to load malicious code during the boot process. - Changes to Volume Boot Record (VBR): Altering the VBR to redirect boot processes to malicious locations. - Firmware Configuration Changes: Modifying BIOS/UEFI settings such as disabling Secure Boot. - Firmware Image Tampering: Updating firmware with a malicious or unauthorized image. - Logs or Errors Indicating Firmware Changes: Logs showing unauthorized firmware updates or checksum mismatches.
This data component can be collected through the following measures:
- BIOS/UEFI Logs: Enable and monitor BIOS/UEFI logs to capture settings changes or firmware updates. - Firmware Integrity Monitoring: Use tools or firmware security features to detect changes to firmware components. - Endpoint Detection and Response (EDR) Solutions: Many EDR platforms can detect abnormal firmware activity, such as changes to MBR/VBR or unauthorized firmware updates. - File System Monitoring: Monitor changes to MBR/VBR-related files using tools like Sysmon or auditd. - Windows Example (Sysmon): Monitor Event ID 7 (Raw disk access). - Linux Example (auditd): `auditctl -w /dev/sda -p wa -k firmware_modification` - Network Traffic Analysis: Capture firmware updates downloaded over the network, particularly from untrusted sources. Use network monitoring tools like Zeek or Wireshark to analyze firmware-related traffic. - Secure Boot Logs: Collect and analyze Secure Boot logs for signs of tampering or unauthorized configurations. Example: Use PowerShell to retrieve Secure Boot settings on Windows: `Confirm-SecureBootUEFI` - Vendor-Specific Firmware Tools: Many hardware vendors provide tools for firmware integrity checks.Examples: - Intel Platform Firmware Resilience (PFR). - Lenovo UEFI diagnostics.
Analyst context for executives and security teams
Firmware Modification is a high-value evidence source because changes below the operating system can undermine normal endpoint controls and affect whether systems boot safely and reliably. For leaders, the practical question is whether the organization can prove that critical boot components, BIOS/UEFI settings, Secure Boot state, and firmware images have not been altered without authorization.
Executive priority
Prioritize this data component for assets where system integrity and availability matter most, such as critical endpoints, servers, and operationally important systems. It supports incident decision-making by helping determine whether compromise may persist below the OS, and it can provide compliance or assurance evidence that firmware configuration and integrity controls are monitored rather than assumed.
Technical view
SOC, detection engineering, and IR teams should validate whether they collect and can investigate evidence of MBR/VBR changes, BIOS/UEFI configuration changes, firmware image updates, Secure Boot changes, checksum mismatches, and firmware-related logs or errors. The ATT&CK object does not specify platforms or tactics, so coverage should be mapped locally by asset class and firmware capability. Collection examples in the source include BIOS/UEFI logs, firmware integrity monitoring, EDR observations of abnormal firmware activity, file system or raw disk access monitoring, network analysis of firmware downloads, Secure Boot logs, and vendor-specific firmware diagnostics.
Likely telemetry
- BIOS/UEFI logs showing settings changes or firmware updates
- Firmware integrity monitoring results and checksum mismatch alerts
- EDR telemetry related to MBR/VBR modification, raw disk access, or unauthorized firmware update behavior
- File system or device monitoring for boot-related disk changes, including raw disk access where available
- Secure Boot status and tamper-related logs
Detection direction
- Validate whether firmware and boot-integrity telemetry is actually collected, centralized, retained, and searchable; many environments have endpoint logs but limited BIOS/UEFI visibility.
- Tune detections for unauthorized or unexpected MBR/VBR changes, Secure Boot configuration changes, firmware image updates, and checksum mismatches.
- Correlate firmware-change events with approved maintenance windows, vendor update processes, and change-management records to reduce false positives.
- Review whether EDR or system monitoring can observe raw disk access or boot component changes, noting that ATT&CK does not provide a specific official detection analytic for this object.
- Include network context for firmware downloads so analysts can distinguish expected vendor update activity from unusual or untrusted sources.
Mitigation priorities
- Establish an inventory of systems where firmware integrity monitoring and BIOS/UEFI logging are available and enabled.
- Protect firmware configuration baselines, including Secure Boot state where supported, and require documented approval for changes.
- Centralize firmware, Secure Boot, EDR, raw disk access, and vendor diagnostic outputs into SOC workflows where feasible.
- Use vendor-supported firmware integrity or resilience tooling for higher-risk assets.
- Ensure incident response procedures include checks for boot component and firmware changes before declaring a system fully recovered.
Analyst notes and limits
This object is a data component, not a technique, and no relationship context was supplied. The value is therefore in validating observability and investigative readiness rather than inferring a specific adversary behavior chain. The official description includes examples such as MBR/VBR alteration, BIOS/UEFI setting changes, Secure Boot tampering, firmware image tampering, and firmware-related logs or errors.
Platforms, tactics, and official detection logic are not specified in the supplied ATT&CK fields. Any assessment of coverage, risk, or priority must be confirmed against local hardware, firmware capabilities, EDR visibility, logging configuration, and change-management records.
Firmware Modification
Changes made to firmware, which may include its settings, configurations, or underlying data. This can encompass alterations to the Master Boot Record (MBR), Volume Boot Record (VBR), or other firmware components critical to system boot and functionality. Such modifications are often indicators of adversary activity, including malware persistence and system compromise. Examples:
- Changes to Master Boot Record (MBR): Modifying the MBR to load malicious code during the boot process. - Changes to Volume Boot Record (VBR): Altering the VBR to redirect boot processes to malicious locations. - Firmware Configuration Changes: Modifying BIOS/UEFI settings such as disabling Secure Boot. - Firmware Image Tampering: Updating firmware with a malicious or unauthorized image. - Logs or Errors Indicating Firmware Changes: Logs showing unauthorized firmware updates or checksum mismatches.
This data component can be collected through the following measures:
- BIOS/UEFI Logs: Enable and monitor BIOS/UEFI logs to capture settings changes or firmware updates. - Firmware Integrity Monitoring: Use tools or firmware security features to detect changes to firmware components. - Endpoint Detection and Response (EDR) Solutions: Many EDR platforms can detect abnormal firmware activity, such as changes to MBR/VBR or unauthorized firmware updates. - File System Monitoring: Monitor changes to MBR/VBR-related files using tools like Sysmon or auditd. - Windows Example (Sysmon): Monitor Event ID 7 (Raw disk access). - Linux Example (auditd): `auditctl -w /dev/sda -p wa -k firmware_modification` - Network Traffic Analysis: Capture firmware updates downloaded over the network, particularly from untrusted sources. Use network monitoring tools like Zeek or Wireshark to analyze firmware-related traffic. - Secure Boot Logs: Collect and analyze Secure Boot logs for signs of tampering or unauthorized configurations. Example: Use PowerShell to retrieve Secure Boot settings on Windows: `Confirm-SecureBootUEFI` - Vendor-Specific Firmware Tools: Many hardware vendors provide tools for firmware integrity checks.Examples: - Intel Platform Firmware Resilience (PFR). - Lenovo UEFI diagnostics.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | c3edacccd5b4… |
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]
mitre-attack DC0004Open 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.