S0114: BOOTRASH
Analyst context for executives and security teams
BOOTRASH matters because it operates below the normal Windows operating system as a bootkit, making it a persistence and stealth concern rather than just another removable malware file. For leaders, the practical issue is whether the organization can recognize and recover from compromise that may survive normal endpoint cleanup. Its reported financial-sector targeting in the cited ATT&CK sources makes it especially relevant to organizations where trusted endpoints, transaction integrity, and rapid restoration are business-critical.
Executive priority
Prioritize this as a resilience and incident-response readiness question: can the organization prove it has controls, telemetry, and recovery procedures for malware that modifies boot-related areas or hides activity outside normal file-system views? This is important for business continuity, audit evidence, and incident decision-making because incomplete remediation of boot-level persistence can lead to repeated compromise or unnecessary confidence in rebuilt systems.
Technical view
ATT&CK links BOOTRASH to Bootkit behavior and Hidden File System behavior on Windows. SOC, detection engineering, and IR teams should validate whether endpoint tooling can inspect or alert on boot record, volume boot record, disk-sector, and abnormal hidden storage activity, not only user-mode files and processes. Because ATT&CK provides no official detection text for BOOTRASH, coverage should be assessed through the related techniques: T1542.003 for bootkit persistence and T1564.005 for concealed file-system activity.
Likely telemetry
- Endpoint security alerts involving boot record, MBR, VBR, or low-level disk modification on Windows systems
- Disk and volume metadata, including unexpected boot-sector changes or anomalous sector usage
- Forensic disk images or triage artifacts capable of examining areas outside normal file-system paths
- Secure boot, boot integrity, or firmware/boot-chain validation events where available
- Endpoint process and driver activity associated with raw disk access or unusual volume access
Detection direction
- Validate coverage against T1542.003 Bootkit rather than relying only on standard file, process, and registry monitoring.
- Confirm whether tools can inspect boot sectors and hidden file-system structures; normal EDR visibility may be incomplete for activity below the operating system.
- Tune detections for legitimate administrative, backup, disk encryption, imaging, and recovery tools that may also access raw disk or boot areas.
- Use relationship context to combine suspicious boot-area modification with evidence of concealed storage or hidden file-system behavior.
- Because no official BOOTRASH detection guidance is supplied, treat detections as technique-driven hypotheses that require local baselining and forensic confirmation.
Mitigation priorities
- Establish IR procedures that explicitly check for bootkit persistence before declaring Windows hosts remediated.
- Prioritize boot integrity controls, hardened endpoint configurations, and change monitoring for systems where business impact would be high.
- Maintain trusted reimaging and recovery processes that can replace compromised boot areas, not only remove files from the operating system.
- Ensure incident responders have access to disk forensic tooling and clean recovery media when boot-level compromise is suspected.
- For financial or transaction-critical environments, include bootkit scenarios in tabletop exercises and evidence collection plans.
Analyst notes and limits
The supplied ATT&CK object identifies BOOTRASH as a Windows bootkit and relates it to Bootkit and Hidden File System techniques. The strongest defensive value is in validating low-level persistence detection and remediation readiness. The financial-sector reference should be treated as historical source context from ATT&CK citations, not as evidence of current activity or specific exposure.
ATT&CK provides no official detection text, no explicit tactics on the malware object itself, and limited operational detail. This take therefore relies on the supplied description, external references, and relationships to T1542.003 and T1564.005. Local telemetry, endpoint architecture, boot configuration, and IR tooling determine actual coverage.
BOOTRASH
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 | T1564.005 | Hidden File System Sub-technique | BOOTRASH has used unallocated disk space between partitions for a hidden file system that stores components of the Nemesis bootkit.CitationFireEye Bootkits |
| Enterprise | T1542.003 | Bootkit Sub-technique | BOOTRASH is a Volume Boot Record (VBR) bootkit that uses the VBR to maintain persistence.CitationMandiant M Trends 2016CitationFireEye BootkitsCitationFireEye BOOTRASH SANS |
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.1 | Current bundle | f74d96907e7f… |
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]
Mandiant M Trends 2016
Mandiant. (2016, February 25). Mandiant M-Trends 2016. Retrieved November 17, 2024.
Open source URL -
[2]
FireEye Bootkits
Andonov, D., et al. (2015, December 7). Thriving Beyond The Operating System: Financial Threat Group Targets Volume Boot Record. Retrieved May 13, 2016.
Open source URL -
[3]
FireEye BOOTRASH SANS
Glyer, C.. (2017, June 22). Boot What?. Retrieved November 17, 2024.
Open source URL -
[4]
mitre-attack S0114Open 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.