AN1864: Analytic 1864
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 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] Monitor ICS management protocols / file transfer protocols for protocol functions related to firmware changes.
Analyst context for executives and security teams
AN1864 is a detection analytic focused on identifying unexpected firmware changes, including changes visible through device alarms, device application logs, firmware image comparison, BIOS read/write activity, EFI module comparison, and ICS management or file-transfer protocol activity related to firmware updates. Its business significance is that firmware integrity is a low-level trust issue: if organizations cannot prove what firmware is running on critical devices, they may struggle to validate system integrity during incidents, maintenance windows, audits, or operational recovery.
Executive priority
Treat this as an assurance and resilience priority rather than a simple log rule. Leaders should ask whether critical assets have known-good firmware baselines, whether firmware changes are tied to approved maintenance, and whether incident responders can validate firmware integrity after suspicious activity. This matters for operational continuity, compliance evidence, and cyber-physical risk where device firmware affects industrial operations.
Technical view
SOC, detection engineering, and IR teams should validate whether they can observe firmware-change indicators from available device alarms, device application logs, asset management records, BIOS or firmware image comparisons, BIOS read/write events, EFI module collection, and ICS management or file-transfer protocol monitoring. Because ATT&CK does not provide a specific detection rule or platform list for this analytic, implementation should be based on local device capabilities, approved patching workflows, and known-good firmware inventories.
Likely telemetry
- Operational alarms from devices that may indicate firmware changes
- Device application logs, where available, that record firmware update activity
- Asset management records identifying approved and known-good firmware versions
- Firmware, BIOS, or EFI image collection and comparison results
- Logs or audit records for BIOS read/write attempts
Detection direction
- Baseline expected firmware versions for critical assets and compare observed versions against approved asset management records.
- Correlate firmware-change alarms or logs with authorized maintenance windows and patching records to reduce false positives.
- Monitor for BIOS read/write attempts and compare them with known patching behavior where such telemetry is available.
- Collect and compare EFI modules or firmware images against known-clean references when local tooling and system access permit.
- Review ICS management and file-transfer protocol activity for functions related to firmware changes, especially when not matched to approved change control.
Mitigation priorities
- Establish and maintain known-good firmware inventories for critical devices.
- Integrate firmware updates into formal change control and maintenance approval processes.
- Prioritize telemetry enablement for devices where firmware changes can affect safety, availability, or recovery confidence.
- Prepare incident response procedures for firmware integrity validation, including image comparison or specialized assessment tooling where appropriate.
- Use asset management and patching records as evidence for audit, compliance, and post-incident integrity decisions.
Analyst notes and limits
The supplied object is an ICS ATT&CK detection analytic with no tactics, platforms, or relationship context provided. The official description points to monitoring firmware changes through alarms, logs, asset management comparison, BIOS/EFI inspection, BIOS read/write monitoring, CHIPSEC-style analysis, and ICS management or file-transfer protocol monitoring. External references support firmware assessment and comparison concepts but do not provide environment-specific coverage guarantees.
Official detection content is not provided, and no related techniques, groups, software, mitigations, platforms, or tactics were supplied. Actual feasibility depends on device logging support, access to firmware images, asset inventory quality, approved maintenance records, and whether ICS management or file-transfer protocol telemetry is collected in the local environment.
Analytic 1864
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 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] Monitor ICS management protocols / file transfer protocols for protocol functions related to firmware changes.
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.1 | Current bundle | 20113b191270… |
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 AN1864Open 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.