DET0297: Detection Strategy for Disk Structure Wipe via Boot/Partition Overwrite
DET0297 is a MITRE detection strategy for identifying attempts to wipe boot or partition structures, linked to ATT&CK technique T1561.002 Disk Structure Wi...
Analyst context for executives and security teams
DET0297 is a MITRE detection strategy for identifying attempts to wipe boot or partition structures, linked to ATT&CK technique T1561.002 Disk Structure Wipe. For leaders, the practical issue is availability: corruption of boot records or partition tables can make systems unbootable and disrupt access to business, network, or operational resources. Because this object has no official detection text or platform list of its own, teams should treat it as a validation prompt rather than a ready-made rule.
Executive priority
Prioritize this behavior where system availability is critical: domain services, endpoint fleets, servers supporting business operations, network devices, and any environment where rebuild time materially affects continuity. Leadership should ask whether the organization can detect destructive disk-structure activity early, preserve evidence during a wipe incident, and recover systems from known-good backups. This is also relevant to resilience evidence for incident response, disaster recovery, and audit discussions, because the risk is not just compromise but loss of bootability and service availability.
Technical view
The detection strategy object does not provide MITRE-authored detection logic, platforms, or tactics. Its relationship to T1561.002 places the detection objective around impact activity that overwrites or corrupts critical disk structures such as the MBR or partition table. SOC and detection engineering teams should validate whether available telemetry can show unusual low-level disk write behavior, modification of boot or partition data, execution of tools capable of raw disk access, and rapid multi-host patterns that may indicate destructive activity. IR teams should ensure triage procedures preserve volatile and endpoint evidence before rebuild actions erase context.
Likely telemetry
- Endpoint process execution and command-line telemetry for utilities or code accessing raw disks or partition structures
- Operating system security and system logs related to disk, volume, boot, or partition changes
- Endpoint detection telemetry for raw disk writes, boot record modification, or destructive file/device access
- File and device access events involving physical drives, block devices, volumes, or partition tables
- Change records or configuration telemetry for servers, workstations, and network devices where supported
Detection direction
- Confirm whether telemetry exists on the platforms relevant to the related technique: Linux, macOS, Network Devices, and Windows; the detection strategy object itself does not specify platforms.
- Tune for high-risk sequences rather than single events alone: privileged process execution followed by raw disk or partition access, then system instability or reboot failure.
- Separate legitimate administrative disk management from suspicious activity using change windows, approved tooling, privileged account context, host role, and ticket/change evidence.
- Look for scale and timing: similar destructive disk-structure behavior across multiple systems should receive higher priority because the related technique is associated with interruption of availability.
- Validate blind spots around network devices, recovery environments, and systems with limited endpoint telemetry, since disk-structure changes may not be visible through standard application logs.
Mitigation priorities
- Establish and test recovery procedures for systems whose boot or partition structures are corrupted, including known-good backups and rebuild media.
- Restrict and monitor privileged access capable of modifying raw disks, boot records, partitions, or system volumes.
- Harden administrative tooling and change-control processes so legitimate disk-management activity is attributable and distinguishable from unauthorized behavior.
- Ensure endpoint and infrastructure logging is retained long enough to support incident response before systems are reimaged or restored.
- Include destructive disk-structure scenarios in incident response and business continuity exercises, especially for critical servers and network infrastructure.
Analyst notes and limits
This take is based on the DET0297 detection strategy metadata and its relationship to T1561.002 Disk Structure Wipe. The source object has no official description or detection text, so the recommended direction is framed as coverage validation and operational readiness rather than a specific analytic rule.
MITRE did not provide platform, tactic, description, or detection details on the DET0297 object itself. Platform and impact context comes only from the related T1561.002 technique. Local environment evidence is required to determine applicable systems, available telemetry, normal administrative activity, and feasible controls.
Detection Strategy for Disk Structure Wipe via Boot/Partition Overwrite
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 | T1561.002 | Disk Structure Wipe Sub-technique | This object detects Disk Structure Wipe. |
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 | beabfc0c36b2… |
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 DET0297Open 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.