AN1922: Analytic 1922
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
This analytic matters because unauthorized or unexpected firmware changes can undermine trust in industrial devices and supporting systems below the operating-system level. For leaders, the key issue is not just malware detection; it is whether the organization can prove what firmware should be present, notice when it changes, and distinguish approved maintenance from suspicious modification.
Executive priority
Prioritize this where firmware integrity affects operational resilience, safety, recovery confidence, or audit evidence. Executives should ask whether asset inventories include known-good firmware versions, whether maintenance windows and patching records can explain firmware changes, and whether incident responders have a repeatable process to validate device, BIOS, or EFI integrity after a suspected compromise.
Technical view
SOC, IR, and OT teams should validate collection and review of operational alarms, device application logs, ICS management protocol activity, and file transfer protocol activity related to firmware changes. Where applicable, teams should compare firmware, BIOS images, and EFI modules against known-good baselines and investigate read/write attempts that do not align with expected patching behavior. The supplied object does not specify platforms or tactics, so local asset scope and device capabilities must drive implementation.
Likely telemetry
- Operational alarms from devices indicating firmware changes
- Device application logs that record firmware changes, where available
- ICS management protocol activity related to firmware update functions
- File transfer protocol activity associated with firmware movement or update processes
- Asset management records of known-good firmware versions
Detection direction
- Validate that firmware-change events are captured from devices that can produce alarms or application logs.
- Correlate firmware-related protocol or file transfer activity with approved maintenance windows and change records.
- Maintain known-good firmware baselines in asset management systems so differences can be assessed rather than treated as standalone alerts.
- Tune investigations to account for legitimate vendor maintenance and patching activity to reduce false positives.
- Identify blind spots where devices do not emit firmware logs or where firmware versions are not tracked in inventory.
Mitigation priorities
- Establish and maintain known-good firmware version records for relevant industrial assets and supporting systems.
- Require firmware changes to be tied to approved maintenance, patching, and change-management evidence.
- Ensure responders can collect and compare firmware, BIOS images, or EFI modules where technically feasible.
- Use firmware integrity assessment approaches such as CHIPSEC where applicable to the system under review.
- Document gaps for devices that cannot log or expose firmware state, and compensate with procedural controls and maintenance verification.
Analyst notes and limits
AN1922 is a detection analytic in the ICS ATT&CK domain focused on monitoring firmware changes and comparing firmware, BIOS, and EFI components to known-good references. The source text references operational alarms, device logs, ICS management and file transfer protocols, asset management baselines, MITRE Copernicus, and CHIPSEC-related materials.
No platforms, tactics, formal detection field, or relationship context were supplied. This take therefore avoids claims about specific technologies, adversaries, active exploitation, or guaranteed detection coverage. Local device capabilities, logging support, and asset inventory quality determine how actionable this analytic is.
Analytic 1922
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.1 | Current bundle | 380803fd652e… |
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 AN1922Open 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.