DET0323: Detection Strategy for T1542.002 Pre-OS Boot: Component Firmware
DET0323 is a MITRE detection strategy object for Component Firmware persistence under Pre-OS Boot. The business significance is that malicious changes to f...
Analyst context for executives and security teams
DET0323 is a MITRE detection strategy object for Component Firmware persistence under Pre-OS Boot. The business significance is that malicious changes to firmware on system components can allow code to run outside the normal operating system security stack, making recovery, trust decisions, and incident scoping harder than for ordinary malware. Because the ATT&CK object itself has no official detection text, organizations should treat this as a coverage-validation prompt rather than a ready-made analytic.
Executive priority
Prioritize this as a resilience and trust-boundary issue for high-value Windows, Linux, and macOS assets where firmware compromise would complicate business recovery or evidence integrity. Leaders should ask whether asset inventories include component firmware, whether firmware baselines and update provenance are governed, and whether incident response plans can make a defensible decision about rebuild, reflash, replacement, or isolation when OS-level telemetry is not enough.
Technical view
SOC, detection engineering, and IR teams should validate coverage around T1542.002, which is associated with stealth and persistence. Since the detection strategy has no official analytic details, the practical work is to confirm whether the environment can observe component firmware versions, unexpected firmware changes, device inventory drift, firmware update activity, and host integrity signals across relevant Windows, Linux, and macOS systems. IR playbooks should account for the possibility that normal endpoint logs may not fully explain persistence if execution occurs outside the operating system.
Likely telemetry
- Hardware and component inventory records, including device identifiers and firmware versions
- Firmware update logs or management-platform records where available
- Endpoint device inventory and driver/device enumeration changes
- Host integrity, boot integrity, or attestation evidence where implemented
- Configuration management and vulnerability management records for firmware baselines
Detection direction
- Establish known-good firmware baselines for critical component classes and alert on unexplained version, device, or configuration drift.
- Correlate firmware changes with approved maintenance windows and authorized update mechanisms to reduce false positives from legitimate patching.
- Treat repeated persistence after OS rebuild or endpoint remediation as a trigger to expand scoping beyond the operating system.
- Validate whether telemetry is available before assuming SOC coverage; component firmware may have limited integrity checking compared with main system firmware or BIOS.
- Use relationship context to map detections to stealth and persistence outcomes, not just to isolated firmware-change events.
Mitigation priorities
- Start with asset and firmware inventory for business-critical systems, because detection and response depend on knowing what components and firmware versions exist.
- Define approved firmware update paths, maintenance windows, and evidence requirements for change control.
- Integrate firmware baselines into vulnerability management and configuration governance where tooling supports it.
- Prepare IR decision criteria for when systems require firmware reflash, hardware replacement, or isolation rather than standard OS reimaging alone.
- Prioritize stronger integrity and attestation controls for high-impact systems where firmware-level persistence would create unacceptable recovery uncertainty.
Analyst notes and limits
The supplied MITRE object is a detection strategy for T1542.002 but includes no official description, detection logic, platforms, or tactics of its own. The actionable context comes from its relationship to Component Firmware, which MITRE describes as persistence through modified component firmware and associates with stealth and persistence on Windows, Linux, and macOS.
This take is constrained by sparse ATT&CK fields. It does not assert active exploitation, specific adversaries, vendor exposure, or guaranteed detection. Local hardware models, firmware management capabilities, endpoint tooling, and change-control evidence are required to determine real coverage.
Detection Strategy for T1542.002 Pre-OS Boot: Component 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.002 | Component Firmware Sub-technique | This object detects Component 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 | be00f21d577a… |
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 DET0323Open 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.