How T1561 disk wipe destroys recovery before the damage is noticed
T1561 Disk wipe lets an adversary under the Impact tactic (TA0040) erase or corrupt the data on a storage device so that the affected host or device cannot be used or restored as it was. It can appear late in an intrusion, after access has been gained and the environment has been explored, because wiping removes the evidence and the means of recovery at the same time. This mapping targets Enterprise ATT&CK 20.0. Confirm that version against the MITRE ATT&CK updates before you rely on technique IDs in detection content, because releases can rename, deprecate or revoke techniques. The tactic description frames Impact as manipulating, interrupting or destroying systems and data.
ATT&CK divides T1561 into two sub-techniques. T1561.001 (Disk Content Wipe) covers overwriting or erasing the data held on a disk, so files, applications and user data on the volume are lost. T1561.002 (Disk Structure Wipe) covers damaging the structures that describe how a disk is organized, such as partition tables or boot records. A structure wipe can look like a boot failure or a hardware fault at first, even though the underlying data may still be present. A content wipe is more likely to surface as missing or unreadable files. Your triage playbooks should handle both cases, and you should confirm the exact sub-technique scope in the Enterprise 20.0 data before writing mappings.
The decision that matters most is whether a wipe on one host can also reach the copies you would use to recover. Ask your platform and backup owners which backup repositories, snapshots and replication targets can be reached with the credentials, network paths or management interfaces that a compromised host already has. Then confirm how long a restore from each source takes and whether that restore has been exercised on the current platform version. Those answers, not the detection alone, set how much damage a late alert can still prevent. Record them as explicit assumptions so they can be tested in the cyber range exercise described later on this page.
Which telemetry reveals disk wipe activity across platforms
This table maps the telemetry that exposes T1561 activity on Windows, Linux, macOS and network devices to the open-source collector that gathers it. Read each row as a signal to alert on, paired with the collector that must be deployed before the alert can fire. The main takeaway is that disk wipe is usually visible in process and command records, while file deletion and network device logs confirm the scope of the damage.
| Platform | Signal to look for | Open-source collector |
|---|---|---|
| Windows | Disk-level utilities or scripted commands invoked against physical drives or volume handles, followed by mass file or partition changes | Sysmon-style process creation logging forwarded by Wazuh agents |
| Linux | Raw block device write tools run by an unexpected user, or overwrite commands targeting whole device paths rather than files | Wazuh agent audit and command execution records, with Velociraptor for hunting across hosts |
| macOS | Command execution against disk identifiers or erase operations launched outside change windows | Wazuh agent unified logging and process records, with Velociraptor artifacts for process history |
| Network devices | Administrative sessions followed by configuration or firmware storage writes, and changes to user authentication records | Syslog from devices into Wazuh, with Zeek and Suricata for session context on management traffic |
| File deletion evidence (all platforms) | Rapid bulk deletion or overwrite of files across many directories in a short window, often after a privileged process starts | File integrity monitoring in Wazuh, with Velociraptor for file deletion timelines |
| Authentication context (all platforms) | Privileged logons immediately before destructive process activity, especially from accounts not used for administration | Wazuh collection of authentication logs from endpoints and directory services |
| Network traffic and application logs (network devices) | Unusual management protocol sessions or large transfers to devices before storage changes; application logs showing failed or interrupted configuration jobs | Zeek and Suricata for network content, with Wazuh ingesting device application logs |
Detection logic for disk wipe that SOC teams can tune
Disk wipe activity is rare on most hosts, which makes even small deviations worth reviewing. The cards below pair each detection idea with the telemetry it depends on, the thresholds to start from, and the benign tools that will trigger it, so analysts can tune each rule against their own estate before relying on it.
Destructive process activity on one host
Process Creation telemetry can show a single host launching multiple utilities whose names or arguments relate to partitioning, formatting or zeroing devices within a short window. The logic is a count over a rolling interval, grouped by host and user, rather than a single event match. Start with a low count and a short window, then raise thresholds for hosts that run disk management routinely. Review the parent process and the account context, not only the binary. Expect false positives from imaging, provisioning and storage administration jobs, which should be allow-listed by host group and change ticket.
Writes to raw device paths
Command Execution and file activity can reveal processes that open block device paths directly, which ordinary applications rarely do. The check is whether the writing process belongs to a storage, backup, virtualization or database role on that host. Tune by building an expected-process list per server role, then alert on writes from anything outside it, especially when the target is a boot or system device. Backup agents, RAID and volume managers, and forensic imaging tools are the main sources of benign matches, so record their expected device paths before enabling the rule.
Authentication anomalies before mass overwrite
User Account Authentication events often precede destructive activity by a short interval, for example a privileged logon from an unusual source followed by process activity on storage. Correlate logons with later Process Creation events on the same host within a window you define, and weight privileged or first-seen accounts higher. Thresholds should reflect how often administrators log on to each system class. Administrative jump boxes, scheduled maintenance and vendor support sessions are frequent false positives and should be tagged by source address and account type.
Sudden file deletion or overwrite volume
File Deletion and File Creation telemetry can show an unusual number of files removed or replaced on a volume in a short period, a pattern that can accompany wiping of data areas. The logic compares the rate per host and per path against a baseline, and alerts when a path that is normally stable changes sharply. Tune by excluding known cleanup jobs, build pipelines and log rotation, which can produce similar bursts. Confirm retention of endpoint file telemetry so the baseline is long enough to be meaningful.
Network device configuration wipes
On network devices, Command Execution and Application Log Content can show configuration erase or reload commands issued outside a change window. The detection compares the source account, the management session origin and the time against approved maintenance records. Tune by listing the management addresses and administrators allowed to perform these actions, then alert on any exception. Scheduled configuration restores and lab resets are common benign triggers, so they should be recorded as approved events with ticket references.
How to validate that a disk wipe detection fires
This sequence proves that a disk wipe detection fires on telemetry that actually reaches the SIEM, within a measured latency, with alerts an analyst can act on. It produces a versioned detection record that a reviewer can audit and repeat after every ATT&CK release.
Define the lab scope and boundaries
The detection owner and the cyber range lead agree which operating systems, network devices and log sources are in scope for T1561 Disk Wipe, including the Linux, macOS, Windows and Network Devices platforms listed for the technique. The lab must be an isolated private range with no route to production storage, backups or identity systems. This step is done when the scope document names every host image, log source and SIEM index involved, and the owner signs it.
Agree rules of engagement in writing
The security lead, system owners and the range operator sign rules of engagement that state what may be exercised, which hosts are sacrosanct, who can halt the exercise, and how the team will be told the difference between an exercise artifact and a real incident. Include the escalation path to the incident response lead and the criteria for an immediate stop. The step closes when the signed document is filed with the detection record and every participant has a copy.
Select an approved emulation method
Choose an emulation approach from a reviewed library or a vendor-neutral test plan that maps to the Impact tactic and to the technique and sub-technique IDs in scope. The plan describes the behavior and expected artifacts in words, such as a bulk overwrite of file content on a disk-level target inside the range, without publishing operational commands in the page or the ticket. Record the ATT&CK version the plan targets. The step is done when the approved plan states its expected telemetry, so the reviewer can judge the result against it.
Confirm telemetry arrives in the SIEM
Before the emulation runs, the detection engineer checks that the data components the strategy depends on, such as Process Creation, Command Execution and File Creation for the platform in scope, are collected, parsed and searchable in the SIEM. Confirm the agent or sensor versions, the time synchronization of the hosts, and that the events carry the fields the rule expects. The check passes when a benign test event produces a searchable record in the expected index within the window the team has agreed, and the result is captured with a screenshot or query export.
Run the emulation and capture timestamps
The range operator executes the approved plan on the in-scope hosts while a second person records the start and end times of each action in the exercise log. The observer does not interact with the detection tooling during the run. Capture the source event time, the ingest time and the alert time for each detection, so latency can be calculated later. The step closes when the exercise log, host snapshots and raw SIEM events are preserved together under the exercise identifier.
Measure latency and alert fidelity
The detection engineer compares the source timestamps with the ingest and alert timestamps to measure detection latency for each rule. Alert fidelity is judged by whether the alert fired on the emulated activity, whether it fired on unrelated benign activity during the same window, and whether the fields are enough to triage it. Record false positives and false negatives separately. The step is done when a results table lists each rule, its latency, its fidelity result and any gaps, and the owner has reviewed it.
Record analyst notes and tune the rule
The analyst who triaged the alert writes notes on what the alert showed, which fields helped, what was missing, and what the response steps would have been. The detection engineer turns confirmed gaps into tuning changes or new data requests and re-runs the emulation to confirm the change. Keep the analyst notes with the detection record. The step closes when each open finding has an owner and a status in the tracker.
Version the detection against the ATT&CK release
Store the rule, the emulation plan, the telemetry checks and the results under a version that names the ATT&CK release the detection targets, such as the Enterprise ATT&CK 20.0 release, and the STIX bundle used to map the technique and its sub-techniques. Review the mapping whenever MITRE publishes a new release, because releases can rename, deprecate or revoke techniques and change detection strategies. Re-run the validation after each mapping change. The step is complete when the record shows the target release, the mapping date and the last successful validation run.
Preventive controls that limit disk wipe impact
Disk wipe is destructive by design, so prevention focuses on making wiped systems recoverable, limiting which accounts and hosts can reach raw disks, and keeping people alert to early warning signs. The five mitigations below work together: backups give you something to restore, account and permission controls narrow who can wipe, and segmentation keeps a single compromised host from reaching the rest of the estate.
Data backup with offline copies
Backups are the mitigation that decides whether a wipe becomes an outage or a loss. For T1561, the relevant question is whether the backup set includes the boot records, partition layout and system images of each host, not only application data. Confirm that at least one copy is isolated from the production administrative domain, so an attacker with domain rights cannot delete or overwrite it. Also confirm that restores of bare-metal or full-disk images are rehearsed, not just assumed, and that the restore time measured in exercises matches the recovery targets agreed with the business.
Least privilege for administrative accounts
Disk wipe normally requires elevated rights on the host, so the number of accounts that hold those rights is a direct control. Review which users, service accounts and automation identities can reach raw block devices or run disk management tools on servers and workstations. Remove standing administrative rights where just-in-time elevation is workable, and alert on any new membership in privileged groups. Confirm that break-glass accounts are stored securely, monitored, and tested, because they are a common route to privileged access during an incident.
Restricted file and directory permissions
Permissions on device files, boot partitions and critical system directories determine which processes can write to them. On Linux, check that raw device nodes are owned by root and not writable by service or user groups. On Windows, confirm that access to physical drives and boot configuration data is limited to administrators and that application-level write access to system volumes is removed. Test these settings against your own baseline, because a permission that is correct on a golden image can drift on hosts that were built by hand.
Network segmentation around recovery assets
Segmentation limits how far a wiping action can spread through remote administration paths. Place backup repositories, hypervisor management interfaces and domain controllers in zones that only designated management hosts can reach. Confirm that administrative protocols such as remote shells and remote management ports are not open between general workstation and server subnets. Verify the segmentation by testing it from a compromised-host position inside your cyber range, and record which flows were blocked and which were unexpectedly allowed.
User training on destructive warning signs
Training helps administrators and help desk staff recognize the pre-conditions for a disk wipe, such as unexpected requests to run disk utilities, unfamiliar scripts placed on servers, or urgent instructions to reimage hosts outside the change process. Staff should know who to contact to verify a request through a second channel. Confirm that the training covers privileged users specifically, since they are the people who can run destructive tools legitimately, and that exercises include a simulated request to wipe or reimage a host so the escalation path is practiced.
What to do in the first hour after a disk wipe alert
The first hour after a disk wipe alert is about deciding whether the alert is real, containing the damage, and protecting the evidence before anyone reboots, reimages or rebuilds a host. Start by confirming the signal against the raw telemetry rather than the alert summary: check the Process Creation and Command Execution records that triggered it, identify the account and parent process involved, and confirm whether the target is a system volume, a data volume or a device configuration. Isolate affected Linux, macOS and Windows hosts at the network layer where possible, and for network devices, restrict management access and freeze configuration changes while keeping the device powered. Powering a host off can destroy volatile memory, so ask the incident lead to decide on that step explicitly and record who made it and when.
Preserve evidence in the order the responders need it. Capture volatile state first where the tooling allows, then image the affected disks or take forensic copies of the relevant volumes, and log every hash and custody step. Keep Application Log Content and authentication records from the affected hosts and from the identity provider, since they show which account made the change and from where. Then check backup integrity before anyone plans a restore: confirm that the most recent backup sets are not reachable from the compromised credentials, that they predate the wipe, and that a restore has been tested on a non-production system. Confirm the restore path with the backup platform owner and the data owners, and do not assume a backup is clean because it exists. Identify scope across every platform in the estate, including containers, cloud images and network device configurations, because a wipe often reaches more than one class of system.
Coordinate early. The incident commander should own the decision log, while legal counsel decides how evidence and notifications are handled and communications leads hold any external statement until facts are confirmed. Engage external incident responders when the organization lacks forensic capacity on the affected platforms, when credentials or backup systems may be compromised, or when regulatory notification clocks may be running; confirm the retainer terms, notification duties and jurisdictional requirements in advance rather than during the incident. Write the first-hour decisions, their owners and their open questions into one shared record so that later responders do not repeat or undo containment steps.
Rehearsing T1561 detection in a private cyber range
The range for Linux and macOS hosts should mirror your production fleet: the same distributions and macOS versions, the same endpoint agent and logging configuration, and a representative mix of servers, workstations and build hosts. Use disposable virtual machines with snapshots so the team can reset quickly after each run. Plan injects that exercise the process and file activity a destructive tool would generate, described in words only, and keep the scenario on the test network with no path to production storage.
- Topology: isolated subnet with a log collector, a SIEM and at least one host per operating system family in use, plus a backup target that the wipe scenario must not reach.
- Injects: an unexpected privileged process running on a host with unusual disk-level activity, followed by file deletion across a data volume, with and without a prior admin session.
- Detection in the SIEM: alerts that combine process creation, command execution and file deletion events within a short window, mapped to the Impact tactic and the T1561 detection strategy for the ATT&CK version you target.
- Response in the runbook: isolate the host from the network, preserve memory and disk evidence, confirm the backup chain is intact, and rebuild from a known-good image.
- Tuning check: confirm that routine maintenance jobs, such as disk formatting during provisioning, do not flood analysts with false positives.
Before relying on these alerts, confirm with your platform team that the endpoint agent captures the fields your rules need on each operating system version.
Windows endpoints need their own range because the event sources, administrative tooling and recovery paths differ from Linux and macOS. Build the range from the same Windows images, group policy and endpoint configuration used in production, and include domain-joined workstations and at least one server running a business application. Keep the scenario inside the range domain, with a separate test backup repository and no trust relationship to production Active Directory.
- Topology: isolated Active Directory test domain, a Windows event forwarding or agent-based collector into the SIEM, and a file server holding synthetic business data.
- Injects: an administrative session performing bulk deletion or low-level disk operations on a file server, followed by attempts to alter volume structures, with the account used either privileged or compromised.
- Detection in the SIEM: correlation of process creation with command execution and user account authentication events, so analysts see who ran what, from where, and under which account.
- Response in the runbook: disable the account, block the source host, isolate the server, verify the last good backup, and restore to a clean system while preserving logs for review.
- Coverage check: confirm that process auditing and command line capture are enabled on every tested build, since missing fields are a common reason detections silently fail.
Ask your team to document which Windows event IDs and audit policies were verified in the range, because those settings vary between hardening baselines.
Network devices present a different problem: a destructive action on a switch, router or firewall may appear as a configuration change, a management session or a reboot rather than as file activity. The range should include representative devices or virtual appliances, a syslog or flow collector, and a management network separated from user traffic. Use lab hardware or virtual images from the vendor you run in production, and keep the wipe scenario confined to the lab management plane.
- Topology: management VLAN with two or three devices, centralized syslog and configuration change logging, and a configuration backup server outside the management plane.
- Injects: an unexpected administrative login followed by a configuration erase or firmware-level change, timed outside a change window.
- Detection in the SIEM: alerts on authentication events from unusual sources, configuration change messages, and loss of the device's configuration backup job, correlated with the change calendar.
- Response in the runbook: revoke the administrative credential, isolate the management segment, restore the last verified configuration from the backup server, and confirm routing and access policies before returning the device to service.
- Vendor check: confirm with each vendor which log messages record configuration erase events, because message formats differ by model and firmware.
If your devices cannot produce these logs in a lab, document the gap and treat it as a finding rather than assuming coverage.
Questions SOC leads ask about detecting T1561 Disk wipe
How do we separate a disk wipe from legitimate disk imaging or reprovisioning?
The difference usually sits in context rather than in the tool alone: who initiated the activity, whether it followed an approved change ticket, which host and disk were touched, and whether the device was scheduled for rebuild. Imaging and reprovisioning normally run through known deployment services under named accounts during maintenance windows, while a wipe by an intruder tends to appear on hosts outside that pattern, under unexpected accounts, or alongside other suspicious activity. Build an allow list of sanctioned imaging workflows in your detection content, and review every exception with the change record in hand. Confirm with your own imaging and endpoint teams which signals they can export before you rely on them.
What can we realistically detect on network devices with limited logging?
Coverage on network devices depends mostly on what the platform sends off the box, so the first task is an inventory of the logging options each device family supports. Where native logs are thin, focus on authentication events, configuration and file-system change records, and management-plane access from unexpected sources, and forward them to your collector. Where a vendor offers no suitable telemetry, record that as a documented gap and compensate with out-of-band configuration backups and integrity checks. Confirm the supported log types with each vendor before you commit to a detection set.
How do we tell the sub-techniques apart when an alert fires?
ATT&CK splits T1561 into a sub-technique for the disk structure and one for the file system, so an alert should record which layer was affected. Disk-structure activity usually shows up as changes to partition or boot records, while file-system activity shows up as mass deletion or overwrite of file content. Your triage playbook should ask the analyst to confirm which layer was touched before escalation, because the containment and recovery steps differ. Verify the current sub-technique names and IDs in the ATT&CK version your rules target, since releases can rename or restructure techniques.
How often should we retest our disk wipe detections against new ATT&CK versions?
Retest whenever you adopt a new ATT&CK release, and also after material changes to your endpoint, logging or backup estate. MITRE publishes releases several times a year, and its update notes state that techniques can be renamed, deprecated or revoked, so a detection mapped to an older version can quietly lose its meaning. Record the ATT&CK version each rule targets, keep a change log of mapping updates, and rerun your validation exercises after each change. The exact cadence should be agreed with your governance team and written into your detection lifecycle policy.
What evidence should we keep to show the detection works?
Keep evidence that links each detection to its technique, its data sources and the validation result that proved it fired. In practice this means the rule text, the ATT&CK version and technique ID it targets, the log sources it depends on, and dated records from exercises showing the alert, triage notes and response timing. Store the exercise scope, the test accounts and hosts used, and any gaps you accepted, because auditors and internal reviewers ask about exceptions as often as successes. Ask your assessor which evidence format they expect before you build the archive, since DeployOpen prepares evidence for assessments but does not issue audit opinions.
What drives the cost of building this detection and rehearsing it?
Costs fall into one-time work, such as log source onboarding, rule development and cyber range build, and recurring work, such as tuning, retesting against new ATT&CK versions and maintaining backups. The main drivers are the number of platforms in scope, how much logging already exists, how many network device families need custom handling, and how frequently you want to rerun exercises. Ask any provider for a written scope that lists platforms, data sources, exercise count and deliverables, so the quote can be compared line by line. DeployOpen works from a written scope and does not publish a price list.
Can our own team run this detection program without an outside partner?
Many teams can run parts of it internally, especially monitoring and triage, once rules and data sources are in place. Building telemetry pipelines across Linux, Windows, macOS and network devices, and keeping validation current as ATT&CK changes, usually requires skills that are scarce in a SOC. Assess your team against the detection, logging and cyber range tasks and decide which parts to keep in-house and which to scope externally. DeployOpen plans, implements and supports open-source platforms inside your own infrastructure, and ongoing support is available as a retainer.
How DeployOpen builds disk wipe detections and cyber range exercises
DeployOpen approaches T1561 Disk wipe as a scoped implementation and testing engagement inside your own infrastructure. We agree the platforms, telemetry and exercises in writing, then build and document the detections so your team can run and maintain them.
How we scope
- Confirm which of the Linux, macOS, Windows and network device estates fall inside the written scope for T1561 Disk wipe.
- Agree which telemetry sources, such as process creation and command execution logs, the detections will read from.
- Record the ATT&CK version the detection mapping targets, since releases can rename or deprecate techniques.
How we build
- Deploy open-source logging and detection components, such as Wazuh and Sigma rules, inside your own environment.
- Map detection logic for both T1561 sub-techniques to the telemetry you already collect, and tune it against your baseline.
- Confirm that Data Backup controls are in place and reachable so the response path does not depend on a single host.
How we hand over
- Deliver the detection rules, configuration and validation results as documented artifacts your team owns.
- Provide a cyber range exercise runbook that replays disk wipe behavior in a private lab and records detection outcomes.
- Walk your operations and incident response staff through alert triage, escalation and evidence collection steps.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing for T1561 detections are available as a retainer.
- Ask any provider to confirm how detections will be updated when ATT&CK releases change technique mappings.
