AN2047: Analytic 2047
Monitor for firmware changes which may be observable via operational alarms from devices.
Monitor device application logs for firmware changes, although not all devices will produce such logs.
Monitor ICS management protocols / file transfer protocols for protocol functions related to firmware changes.
Monitor firmware for unexpected changes. Asset management systems should be consulted to understand known-good firmware versions. Dump and inspect BIOS images on vulnerable systems and compare against known good images.[1] Analyze differences to determine if malicious changes have occurred. Log attempts to read/write to BIOS and compare against known patching behavior. Likewise, EFI modules can be collected and compared against a known-clean list of EFI executable binaries to detect potentially malicious modules. The CHIPSEC framework can be used for analysis to determine if firmware modifications have been performed.[2][3][4]
Analyst context for executives and security teams
AN2047 is about validating whether firmware has changed unexpectedly, especially in ICS environments where unauthorized firmware changes can undermine trust in devices and complicate recovery. For leaders, the practical issue is not just “can we detect malware,” but whether operations, security, and asset owners can prove that critical device firmware and BIOS/EFI components match known-good versions after maintenance, incidents, or suspicious alarms.
Executive priority
Treat this as a resilience and assurance control for high-value operational assets. Firmware integrity affects incident decision-making, recovery confidence, and compliance evidence because standard endpoint or network monitoring may not be enough to show whether low-level device software was altered. Executives should ask whether firmware baselines exist, who owns them, how changes are approved, and whether SOC/IR teams can distinguish authorized patching from unexpected modification.
Technical view
SOC, detection engineering, and IR teams should validate collection and review paths for firmware-change evidence across ICS device alarms, device application logs where available, ICS management protocols, file-transfer activity, and direct firmware/BIOS/EFI inspection. The ATT&CK object notes that not all devices produce firmware-change logs, so coverage should not be assumed. Asset management data should be used to compare observed firmware against known-good versions, and BIOS/EFI images or modules may need offline or specialized inspection using approaches referenced by MITRE, including CHIPSEC-style analysis where applicable.
Likely telemetry
- Operational alarms from ICS devices indicating firmware changes
- Device application logs that record firmware update or firmware change events, where supported
- ICS management protocol activity related to firmware operations
- File-transfer protocol activity associated with firmware movement or updates
- Asset management records of known-good firmware versions
Detection direction
- Inventory which devices can and cannot emit firmware-change logs; document blind spots explicitly.
- Correlate firmware-change alarms or protocol functions with approved maintenance windows and patching records to reduce false positives.
- Monitor ICS management and file-transfer protocol usage for firmware-related functions, then validate whether observed activity maps to authorized change processes.
- Compare firmware, BIOS, and EFI components against known-good baselines rather than relying only on runtime security alerts.
- For systems where BIOS/EFI inspection is feasible, analyze image or module differences to determine whether changes are expected, benign, or suspicious.
Mitigation priorities
- Establish and maintain authoritative firmware baselines in asset management systems for critical ICS and supporting systems.
- Require change approval and maintenance records for firmware updates so detection teams can separate authorized patching from unexpected modification.
- Ensure operational alarms, device logs, management protocol logs, and file-transfer records are retained where devices and infrastructure support them.
- Define an IR procedure for firmware integrity validation, including when to dump and compare BIOS/EFI or firmware images.
- Prioritize coverage for systems where firmware compromise would materially affect safety, availability, recovery confidence, or regulatory evidence.
Analyst notes and limits
This analytic is most valuable as an assurance and validation pattern: firmware integrity cannot be treated as covered simply because endpoint or network monitoring exists. The object references operational alarms, device logs, ICS management protocols, file transfer, asset baselines, BIOS/EFI comparison, and CHIPSEC-related analysis as relevant evidence sources.
The supplied ATT&CK object has no official detection field, no platforms, no tactics, and no relationship context. It also states that not all devices produce firmware-change logs. Local device capabilities, asset inventory quality, maintenance records, and firmware inspection feasibility are required to determine practical coverage.
Analytic 2047
Monitor for firmware changes which may be observable via operational alarms from devices.
Monitor device application logs for firmware changes, although not all devices will produce such logs.
Monitor ICS management protocols / file transfer protocols for protocol functions related to firmware changes.
Monitor firmware for unexpected changes. Asset management systems should be consulted to understand known-good firmware versions. Dump and inspect BIOS images on vulnerable systems and compare against known good images.[1] Analyze differences to determine if malicious changes have occurred. Log attempts to read/write to BIOS and compare against known patching behavior. Likewise, EFI modules can be collected and compared against a known-clean list of EFI executable binaries to detect potentially malicious modules. The CHIPSEC framework can be used for analysis to determine if firmware modifications have been performed.[2][3][4]
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 | 1.0 | Current bundle | c428937defb8… |
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 Copernicus
Butterworth, J. (2013, July 30). Copernicus: Question Your Assumptions about BIOS Security. Retrieved December 11, 2015.
Open source URL -
[2]
McAfee CHIPSEC Blog
Beek, C., Samani, R. (2017, March 8). CHIPSEC Support Against Vault 7 Disclosure Scanning. Retrieved March 13, 2017.
Open source URL -
[3]
Github CHIPSEC
Intel. (2017, March 18). CHIPSEC Platform Security Assessment Framework. Retrieved March 20, 2017.
Open source URL -
[4]
Intel HackingTeam UEFI Rootkit
Intel Security. (2005, July 16). HackingTeam's UEFI Rootkit Details. Retrieved November 17, 2024.
Open source URL -
[5]
mitre-attack AN2047Open 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.