AN1036: Analytic 1036
Monitors for hardware or firmware tampering by correlating system boot logs, hardware inventory changes, and secure boot/firmware verification failures. Behavioral chain: (1) UEFI/BIOS version drift; (2) secure boot disabled or signature verification errors; (3) unexpected modules or hardware devices enumerated at boot; (4) new device firmware images loaded from non-approved sources.
Analyst context for executives and security teams
AN1036 is a Linux-focused detection analytic for spotting possible hardware or firmware tampering by correlating boot-time evidence, hardware inventory changes, and secure boot or firmware verification failures. Its business value is resilience: firmware and hardware changes can sit below normal operating-system controls, so leaders should know whether their teams can prove that trusted boot and device state have not drifted unexpectedly.
Executive priority
Prioritize this analytic where Linux systems support critical services, regulated workloads, or cyber-physical operations. The key executive question is not simply whether secure boot exists, but whether the organization can produce timely evidence of BIOS/UEFI drift, disabled secure boot, signature verification failures, unexpected boot-enumerated devices, or firmware loaded from unapproved sources. This supports incident triage, audit evidence, asset integrity, and recovery decisions after suspected low-level compromise or unauthorized hardware change.
Technical view
SOC, detection engineering, and IR teams should validate whether Linux boot logs, firmware or secure boot verification results, and hardware inventory records can be correlated over time. The behavioral chain in the ATT&CK object points to four signals to test: UEFI/BIOS version drift, secure boot disabled or signature verification errors, unexpected modules or hardware devices at boot, and new device firmware images from non-approved sources. Because ATT&CK does not provide a separate detection procedure or related techniques here, local baselining is essential to distinguish legitimate maintenance, kernel or firmware updates, and hardware refresh activity from suspicious drift.
Likely telemetry
- Linux system boot logs
- UEFI/BIOS version and firmware state records
- Secure boot status and signature verification failure events
- Hardware inventory and device enumeration changes observed at boot
- Kernel/module or device firmware load records
Detection direction
- Establish baselines for expected BIOS/UEFI versions, secure boot state, boot-enumerated devices, modules, and approved firmware sources on Linux systems.
- Correlate multiple weak signals rather than alerting on a single change; the described analytic is strongest when version drift, verification failure, unexpected devices, or unapproved firmware sources appear together.
- Tune for planned maintenance, hardware replacement, firmware updates, and authorized configuration changes to reduce false positives.
- Validate collection coverage before relying on the analytic; many environments lack consistent firmware, secure boot, or boot-time hardware telemetry.
- Document gaps where Linux assets do not expose secure boot status, firmware verification events, or reliable hardware inventory history.
Mitigation priorities
- Maintain authoritative hardware and firmware inventories for Linux systems that matter to operations or compliance.
- Define approved firmware sources and require change records for BIOS/UEFI, device firmware, and hardware changes.
- Enable and monitor secure boot or firmware verification capabilities where supported by the platform and operational requirements.
- Integrate boot integrity and hardware inventory evidence into incident response procedures so responders can assess low-level tampering during investigations.
- Review critical Linux systems for telemetry gaps before treating this analytic as a dependable control.
Analyst notes and limits
This object is a detection analytic, not a technique, and the supplied ATT&CK fields list Linux as the only platform with no tactic or relationship context. The strongest practical use is as a coverage validation checklist for firmware and hardware integrity monitoring rather than a standalone alert rule.
Official detection text and relationship context were not supplied. Conclusions must be validated against local Linux platform capabilities, firmware configuration, asset inventory quality, and change-management records. This summary does not imply active exploitation, attribution, or guaranteed detection coverage.
Analytic 1036
Monitors for hardware or firmware tampering by correlating system boot logs, hardware inventory changes, and secure boot/firmware verification failures. Behavioral chain: (1) UEFI/BIOS version drift; (2) secure boot disabled or signature verification errors; (3) unexpected modules or hardware devices enumerated at boot; (4) new device firmware images loaded from non-approved sources.
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 | 3b1594e65ad9… |
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 AN1036Open 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.