AN1912: Analytic 1912
Monitor for changes made to firmware for unexpected modifications to settings and/or data that may be used by rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Asset management systems should be consulted to understand known-good firmware versions and configurations.
Analyst context for executives and security teams
This analytic is about watching firmware for unexpected changes that could let malicious code hide below normal operating system and application visibility. For executives and security leaders, the practical issue is trust: if firmware integrity is not tracked against known-good versions and configurations, incident responders may not be able to prove whether an asset is clean or safe to return to service.
Executive priority
Prioritize this where firmware-backed devices are important to operational resilience, safety, or recovery confidence. Leaders should ask whether the organization maintains authoritative firmware inventories, known-good baselines, and change records that can support incident decisions and audit evidence. Without that foundation, SOC and IR teams may have limited ability to distinguish approved maintenance from suspicious modification.
Technical view
ATT&CK provides a monitoring objective rather than a full detection rule: monitor for firmware changes, especially unexpected modifications to settings or data that could be used by rootkits to conceal programs, files, network connections, services, drivers, or other components. Detection engineering should validate whether asset management data can identify known-good firmware versions and configurations, then compare observed changes against approved maintenance windows and change records. No platforms, tactics, or relationships are supplied, so implementation must be scoped using local asset criticality and available firmware/asset telemetry.
Likely telemetry
- Asset inventory records with firmware version and configuration details
- Known-good firmware baselines from asset management systems
- Firmware update or configuration change logs where available
- Maintenance and change-management records for approved firmware activity
- Integrity or configuration assessment results that can show drift from expected firmware state
Detection direction
- Validate that firmware versions and configurations are actually collected for relevant assets, not only host operating system or application data.
- Compare firmware state to known-good baselines and approved change records to identify unexpected modifications.
- Tune alerting around authorized maintenance windows to reduce false positives from legitimate firmware updates.
- Treat missing or stale asset-management records as a detection blind spot, because the analytic depends on knowing what firmware state should be expected.
- Use suspicious firmware drift as an investigation trigger, not as standalone proof of malicious activity.
Mitigation priorities
- Establish and maintain known-good firmware version and configuration baselines in asset management systems.
- Tie firmware updates and configuration changes to formal change-management approval and maintenance records.
- Prioritize baseline coverage for assets where loss of trust would affect operational continuity, safety, or incident recovery decisions.
- Ensure incident response procedures include checking firmware integrity when normal endpoint or network evidence does not explain suspicious behavior.
Analyst notes and limits
The supplied ATT&CK object is an ICS detection analytic with a firmware-monitoring description, but no official detection logic, platforms, tactics, labels, aliases, or relationship context. The strongest decision value is in validating whether the organization can prove expected firmware state and detect drift from it.
This take is limited to the official STIX fields and external reference provided. It does not identify specific affected platforms, adversaries, tools, techniques, or active exploitation. Local asset inventory, firmware telemetry, and change-management evidence are required to operationalize the analytic.
Analytic 1912
Monitor for changes made to firmware for unexpected modifications to settings and/or data that may be used by rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Asset management systems should be consulted to understand known-good firmware versions and configurations.
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 | bc6c7a3b94f5… |
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 AN1912Open 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.