DET0150: Detection Strategy for File Creation or Modification of Boot Files
DET0150 is a MITRE detection strategy for spotting creation or modification of boot files associated with Bootkit behavior. The business issue is persisten...
Analyst context for executives and security teams
DET0150 is a MITRE detection strategy for spotting creation or modification of boot files associated with Bootkit behavior. The business issue is persistence below or before normal operating system startup: if defenders miss this class of change, remediation and recovery decisions can be harder because the suspected malicious code may survive normal OS-level cleanup.
Executive priority
Treat this as a resilience and incident-response readiness question, not just an alert rule. Leaders should ask whether Windows and Linux systems that matter to operations have auditable evidence of boot-file changes, whether SOC teams know how to escalate suspected bootkit activity, and whether recovery plans account for persistence that may require deeper remediation than standard malware removal.
Technical view
This strategy detects ATT&CK T1542.003 Bootkit, which is associated with stealth and persistence on Linux and Windows. SOC and detection teams should validate whether they collect reliable file creation and modification telemetry for boot-related files and locations, and whether those events are correlated with privileged activity and change-control context. Because the ATT&CK object provides no official detection logic, local engineering is required to define monitored paths, expected baseline changes, and triage criteria.
Likely telemetry
- File creation events for boot-related files or directories
- File modification events for boot-related files or directories
- Endpoint security or EDR file-system telemetry
- Linux and Windows host audit logs where configured to record relevant file changes
- File integrity monitoring records for critical boot-related locations
Detection direction
- Confirm coverage on systems where Bootkit-related persistence would materially affect recovery, especially Linux and Windows assets in critical roles.
- Baseline legitimate boot-file changes caused by operating system updates, bootloader updates, maintenance, imaging, or recovery operations to reduce false positives.
- Prioritize alerts where boot-file changes occur outside approved maintenance windows or lack a matching change record.
- Correlate boot-file changes with privileged user activity, unusual process ancestry, or other persistence signals, while avoiding claims of bootkit activity from a single file event alone.
- Document blind spots where endpoint logging, file integrity monitoring, or audit policy does not cover boot-related locations.
Mitigation priorities
- Establish a clear inventory of systems where boot-file integrity matters most to business continuity.
- Enable or tune file integrity and endpoint monitoring for boot-related files on supported Linux and Windows assets.
- Tie approved OS, bootloader, and system update activity to change-management evidence so SOC teams can distinguish expected from suspicious modification.
- Define an incident response path for suspected bootkit persistence, including escalation beyond routine malware cleanup when boot-layer compromise is plausible.
- Use ATT&CK T1542.003 mapping as compliance and audit evidence for persistence monitoring, while clearly noting any telemetry gaps.
Analyst notes and limits
The supplied ATT&CK detection-strategy object is sparse: it has a name, external reference, and a relationship showing it detects T1542.003 Bootkit. The practical value comes from validating whether boot-file change evidence exists and whether the SOC can interpret it in the context of stealth and persistence.
No official MITRE description or detection text was supplied for DET0150, and the detection strategy itself has no specified platforms or tactics. Platform and tactic context is taken only from the related Bootkit technique. Local path lists, logging capabilities, update processes, and asset criticality are required before this can become an operational detection.
Detection Strategy for File Creation or Modification of Boot Files
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 | 9d7ae0439669… |
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 DET0150Open 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.