DET0175: Detection Strategy for T1542.004 Pre-OS Boot: ROMMONkit
DET0175 matters because it points defenders at ROMMONkit behavior: persistence and stealth in the pre-OS boot path of network devices. For leaders, the key...
Analyst context for executives and security teams
DET0175 matters because it points defenders at ROMMONkit behavior: persistence and stealth in the pre-OS boot path of network devices. For leaders, the key risk is not just malware on a server; it is unauthorized firmware or bootloader-level change on infrastructure that may survive resets and make device behavior hard to trust.
Executive priority
Treat this as a resilience and trust-in-infrastructure issue. Ask whether critical network devices have firmware and boot integrity baselines, whether maintenance changes are auditable, and whether incident response can verify or restore device firmware if compromise is suspected. Budget and control priority should favor visibility into network device state, not only endpoint and cloud telemetry.
Technical view
The ATT&CK detection strategy object has no official detection text, so validation should be driven by the related technique: T1542.004 ROMMONkit, associated with stealth and persistence on Network Devices. SOC and IR teams should confirm they can compare device firmware, ROMMON/boot settings, boot images, and reload events against known-good baselines and authorized change records. Detection logic should account for legitimate firmware upgrades and maintenance windows.
Likely telemetry
- Network device firmware and boot image inventory
- ROMMON or bootloader configuration/state where available
- Device configuration change logs and administrative access logs
- Reload, power-cycle, or recovery-mode event logs
- Firmware image transfer or management-plane activity records
Detection direction
- Validate whether network devices are included in centralized monitoring and asset inventory, not just servers and endpoints.
- Alert on unexpected firmware, boot image, ROMMON, or boot variable changes when compared with approved baselines.
- Correlate firmware or boot changes with administrator identity, source location, maintenance tickets, and device reload timing.
- Tune for authorized upgrades, emergency maintenance, and hardware replacement workflows to reduce false positives.
- Identify blind spots where device logs are not retained, management-plane activity is not collected, or firmware integrity cannot be independently verified.
Mitigation priorities
- Establish approved firmware and boot configuration baselines for critical network devices.
- Require documented change control for firmware, ROMMON, boot image, and recovery-mode activity.
- Restrict administrative and management-plane access to authorized personnel and controlled paths.
- Maintain trusted recovery images, configuration backups, and restoration procedures for incident response.
- Include network device firmware verification in resilience testing, compliance evidence collection, and post-incident validation.
Analyst notes and limits
This take is based on DET0175 and its relationship to T1542.004 ROMMONkit. The detection strategy itself does not provide official description, detection logic, platforms, or tactics; the practical guidance is therefore derived conservatively from the related technique context: unauthorized firmware in ROMMON on network devices for persistence and stealth.
Local device models, firmware management processes, logging capabilities, and change-control maturity will determine what can actually be detected. This summary does not assert active exploitation, attribution, or existing coverage.
Detection Strategy for T1542.004 Pre-OS Boot: ROMMONkit
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.
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 | 8903bcc01af0… |
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 DET0175Open 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.