DET0099: Detection Strategy for T1542.001 Pre-OS Boot: System Firmware
DET0099 is a MITRE detection strategy object for firmware-level persistence under T1542.001 System Firmware. Even though MITRE has not supplied detection t...
Analyst context for executives and security teams
DET0099 is a MITRE detection strategy object for firmware-level persistence under T1542.001 System Firmware. Even though MITRE has not supplied detection text for this strategy, the related behavior matters because firmware sits below the operating system; if it is modified, normal endpoint rebuilds, OS monitoring, and application controls may not be enough to restore trust.
Executive priority
Treat this as a resilience and assurance issue, not only a malware-detection issue. Leaders should ask whether Windows systems and network devices have firmware inventory, change control, integrity validation, and incident response procedures that account for pre-OS persistence. The priority is highest where business continuity depends on trusted hardware states, audit evidence for secure configuration, or rapid recovery after compromise.
Technical view
SOC, detection engineering, and IR teams should validate coverage against the related ATT&CK technique T1542.001, which is associated with persistence and stealth on Windows and network devices. Because the ATT&CK detection strategy has no official detection guidance, teams should map local controls to evidence that can show authorized versus unexpected firmware state changes, boot-chain anomalies, and firmware version/configuration drift. IR playbooks should explicitly address that an OS-level reinstall may not prove device trust if firmware integrity is in question.
Likely telemetry
- Firmware version and configuration inventory for Windows systems and network devices
- Records of approved firmware updates, maintenance windows, and administrative change tickets
- Boot and platform integrity events where available
- Endpoint, device-management, or asset-management evidence showing firmware state drift
- Network device configuration and firmware audit logs
Detection direction
- Start with asset coverage: confirm which Windows systems and network devices have observable firmware state and which do not.
- Baseline expected firmware versions and configurations, then alert or review unexpected changes outside approved maintenance activity.
- Tune for false positives from legitimate vendor updates, hardware replacement, patch cycles, and administrative remediation.
- Correlate firmware drift with persistence or stealth investigations rather than treating it as a routine patching signal only.
- Document blind spots where telemetry begins only after OS boot or where network devices lack centralized firmware logging.
Mitigation priorities
- Establish firmware ownership, inventory, and approved update processes for affected device classes.
- Require change control and evidence retention for firmware updates and device maintenance.
- Prioritize integrity validation and recovery procedures for systems where firmware trust affects business operations.
- Ensure IR runbooks include escalation paths for suspected firmware modification, including device isolation and hardware-level validation.
- Use compliance and audit programs to verify that firmware baselines, exceptions, and remediation decisions are documented.
Analyst notes and limits
The supplied MITRE object is a detection strategy placeholder for DET0099 and detects T1542.001 System Firmware. The relationship context provides the meaningful defensive anchor: firmware modification can support stealth and persistence on Windows and network devices. Local architecture, device models, and management tooling will determine practical detection depth.
MITRE provided no official description, no official detection text, no tactics, and no platforms directly on the DET0099 object. Platform and tactic context comes only from the relationship to T1542.001. This take does not assert active exploitation, actor use, or guaranteed detection coverage.
Detection Strategy for T1542.001 Pre-OS Boot: System Firmware
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1542.001 | System Firmware Sub-technique | This object detects System Firmware. |
All related ATT&CK context
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 | e0d0c28472fc… |
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 DET0099Open 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.