Detecting T1485 Data destruction

How T1485 data destruction shows up in intrusions

For a SOC lead, the uncomfortable fact about T1485 Data destruction is that it is usually the last step of an intrusion. By the time destructive activity is visible, the attacker has already done the work to reach the data and the systems that hold it, so detection has to fire on the earlier signals or on the first destructive action, not on the loss itself. The MITRE ATT&CK tactic TA0040 (Impact) describes the adversary's goal as trying to manipulate, interrupt, or destroy your systems and data. T1485 is the technique that covers destroying data directly, as opposed to encrypting it for ransom or stopping services, which are separate techniques in the same tactic.

In practice, T1485 can appear on several platform types the way this page's topic scope lists them: containers, VMware ESXi hosts, IaaS workloads and storage, and Linux systems. The ATT&CK entry has one sub-technique. The decisions that matter most are which of these platforms hold your most critical data, which administrative paths can delete it, and whether a deletion on those paths would generate an event your team actually reviews. Confirm with your platform owners where backups, snapshots and object versioning live, because those controls determine whether destruction is recoverable at all.

All mappings in this section target Enterprise ATT&CK version 20.0, which MITRE released on 2026-10-13. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, so any detection rule or coverage record you build should name the version it targets and be re-checked when a new release arrives. Confirm the current technique and sub-technique identifiers against the ATT&CK site before you finalize mappings in your own detection catalog.

Which telemetry reveals data destruction

This table maps each ATT&CK data component referenced for T1485 to the signal it gives and the open-source collector that typically gathers it. Read it as a coverage checklist: host agent signals show what ran and what was removed on a system, while network sensor signals show transfers and traffic patterns that accompany destruction. Confirm each collector's coverage on your own platforms before relying on it.

Data component	Signal for data destruction	Typical open-source collector	Collection point
Process Creation (DC0032)	Shell or utility launched with arguments that target bulk deletion, overwrite or wipe of directories or volumes	Wazuh, auditd, Velociraptor	Host agent
Command Execution (DC0064)	Recorded commands run through interpreters or management consoles, useful for reconstructing a destructive sequence	Velociraptor, auditd, Wazuh	Host agent
File Creation (DC0039)	Many new files appearing with ransom-style or placeholder names, or overwritten copies created in bulk	Wazuh file integrity monitoring, Velociraptor	Host agent
File Deletion (DC0040)	High rates of removal across user data, backup or log paths within a short window	Wazuh file integrity monitoring, auditd	Host agent
Application Log Content (DC0038)	Database, storage or application errors and audit entries showing mass record or object removal by one identity	Wazuh log collection, Security Onion log pipelines	Host agent or log forwarder
Network Traffic Content (DC0085)	Unusual bulk transfers to external destinations or to backup targets shortly before or during deletion	Zeek, Suricata, Security Onion	Network sensor
Host status and availability	Sudden loss of file shares, mount points or volumes visible to monitoring agents	Wazuh agent status, Velociraptor hunts	Host agent

Detection ideas for destructive file activity

The four detection concepts below share one goal: separate destructive intent from routine housekeeping that produces the same file events. Each card names the signal, a tuning starting point to validate in your own environment, the benign sources that will trigger it, and how to allowlist those sources without blinding the rule.

Mass deletion or overwrite by one process

Alert when a single process creates, overwrites or deletes an unusually high number of files in a short window, especially across directories it rarely touches. Use File Creation and File Deletion telemetry from Wazuh or Zeek-adjacent file monitoring, and set the threshold per host role after a baseline period. Cleanup jobs, log rotation, build pipelines and package managers are the usual false positives. Allowlist by signed binary and parent job identity, not by directory alone, so a compromised cleanup tool still raises an alert.

Destruction in container and hypervisor datastores

Watch for bulk removal of virtual disks, snapshots or container volumes outside the change windows your platform team records. Process Creation and Command Execution on ESXi hosts and container nodes, combined with datastore file events, show whether a management command is removing VM files. Scheduled snapshot consolidation, image pruning and orchestrator garbage collection generate similar events. Allowlist the specific service accounts and maintenance tasks, and confirm each vendor's logging coverage before relying on it.

Unexpected deletion of backup stores

Treat any delete or modify action against backup repositories, backup catalogs or retention settings as high priority, since destroying recovery points is a common precursor to impact. Monitor File Deletion events on backup targets and audit logs from the backup platform for retention changes. Backup rotation and retention enforcement are the main benign sources, so tune the rule to fire on deletions that fall outside the scheduled retention policy. Allowlist the backup software's service identity and its documented pruning window only.

Destructive commands from unusual parents

Flag destructive commands such as recursive removal or disk overwrite utilities when launched by parents that normally do not spawn them, for example a web service, a database process or a document viewer. Process Creation records with parent process lineage and Command Execution logs make this visible in Wazuh or Security Onion. Administrators running maintenance from a shell, configuration management runs and CI runners can match the pattern. Allowlist known management parents with their expected users and hosts, and review every exception quarterly.

How to validate that the T1485 detection fires

This sequence proves that each T1485 detection rule fires on a controlled, non-production destructive file event, at the expected time and with the expected fields. It also produces a dated record of gaps and of the ATT&CK version the team tested against.

Agree scope and rules of engagement
The detection owner, the platform owner and the cyber range lead agree in writing which non-production hosts, container nodes and test accounts are in scope, which destructive file actions are permitted, and when the exercise runs. They also agree who can stop the exercise and how the SOC will be told it is a planned test so analysts do not treat it as a live incident. The step is done when the signed scope note lists the assets, the actions and the stop conditions.
Record the ATT&CK version under test
Before any emulation, the team records the Enterprise ATT&CK version the rules map to, the T1485 entry they target, and the data components they rely on, such as Process Creation, Command Execution and File Creation. Because releases can rename, deprecate or revoke techniques, this record lets the team explain later exactly which mapping was tested. The step is done when the mapping sheet carries a version label and a date.
Run a controlled destructive file emulation
A tester runs a scripted emulation of destructive file activity against the agreed non-production assets, using a predefined set of test files and a known start time. The run is logged by the tester with the host, the account, the time window and the files affected, so every event can be matched to the telemetry later. The step is done when the run log is complete and the test files show the expected state on the target hosts.
Confirm expected alerts in the SIEM
The SOC lead checks the SIEM, such as the Wazuh dashboard or the Security Onion case view, for alerts tied to the test window and the test hosts. The check confirms that the expected rule names and ATT&CK tags appear and that the event fields needed for triage are present. The step is done when each expected alert is either found with its fields or logged as missing.
Measure firing and timing per rule
For each rule, the analyst compares the time of the emulated action with the time the alert was created and notes whether the rule fired at all, fired once or repeatedly, and fired on the right host. Large or inconsistent delays are recorded as findings, not explained away. The step is done when a per-rule table shows fired, time to alert and host match for every emulated action.
Record gaps and open findings
The detection team lists every rule that did not fire, fired late, fired on the wrong asset or produced noise, and assigns each item an owner and a status in the detection backlog. Gaps tied to missing telemetry are routed to the platform team, since no rule can fire on data that is not collected. The step is done when each gap has a ticket reference and a status.
Retest after every rule change
Each time a rule is edited, a data source is added or the ATT&CK mapping is updated, the team repeats the relevant emulation and compares the results with the previous run. The retest confirms that the change did not break existing coverage and that the version label in the mapping sheet still matches what was tested. The step is done when the new results are stored beside the previous run for audit review.

Preventive controls that limit the damage

These controls work together. Isolated backups and tested restores decide whether destruction becomes a short outage or a lasting loss. Scoped accounts, file permissions and network segmentation decide how easily an attacker can reach production data and its recovery points in the first place.

Isolated backup copies

Keep at least one copy of critical data that production administrator accounts cannot reach or change. Place backup repositories in a separate account, tenant or network zone, with separate credentials and write-once retention where the platform supports it. Check whether a production admin login can delete snapshots, shorten retention or open the backup console. Illustrative example: a hypervisor admin token that also deletes backup jobs gives an attacker a direct path to remove recovery points. Confirm each capability with your backup vendor's documentation, because support differs by product.

Tested restore procedures

A backup that has never been restored is an assumption, not a recovery plan. Schedule restores of representative systems, including databases, container volumes and hypervisor configurations, into an isolated recovery environment or a cyber range. Record how long each restore takes, which dependencies break, and whether the data matches the point in time you expect. Feed those results into incident runbooks so responders know which copy to use first. Ask your implementer for restore evidence, not only backup job success reports.

Scoped privileged accounts

Mitigation M1018, User Account Management, limits who can run the actions that destroy data. Review standing administrator groups on hypervisors, Kubernetes clusters, cloud accounts and Linux hosts, and remove any account that does not need delete rights on production storage. Separate backup administration from system administration so that one compromised login cannot both alter data and erase its recovery points. Assign a named owner to every privileged group and review membership on a fixed schedule.

Restricted file and directory permissions

Mitigation M1022, Restrict File and Directory Permissions, is a supporting control for T1485. Make backup target directories, database data files and configuration stores writable only by the service accounts that must write them. Remove general write and delete rights from interactive users and shared mounts. After every upgrade or restore, confirm that ownership and file modes were not reset to defaults. Permission drift is easy to miss, so verify it with the same tooling you use for detection.

Network segmentation for recovery

Mitigation M1030, Network Segmentation, keeps the path to backups narrow. Place backup servers, object storage endpoints and management interfaces in zones that only the backup service can reach, and deny interactive sessions from user workstations. Alert on new network flows into the backup zone. This limits both direct destruction and the lateral movement that usually comes before it. Confirm the segmentation with a test from a workstation subnet, not only by reading the firewall policy.

Triage and response when destruction is detected

When a T1485 alert fires, the first decision is whether it reflects real destruction or a benign administrative action such as a scheduled purge, a storage migration or a backup rotation job. Confirm the alert against the raw Process Creation, Command Execution and File Creation events on the affected host or workload, and check the change calendar and the owning team's runbooks before escalating. Once destruction is confirmed, isolate the affected hosts, workloads or cloud identities first so the activity stops, but do not power off or reimage systems yet, because that erases the volatile state and the artifacts you need. Use network controls or account suspension rather than teardown, and record each isolation step with a timestamp in your incident log.

Preserve evidence before anyone attempts recovery. Snapshot or image affected volumes and export the relevant log sources (host, container runtime, hypervisor, cloud control plane and identity provider) to write-once storage, then record the current state of each dataset, including file counts, object counts and volume metadata, so you can later measure what was lost. Identify the account and process involved by tracing the session that issued the deletion or overwrite commands back to its authentication event. Assess the scope by mapping each destroyed dataset to its owner, its recovery point objective and its most recent verified backup. Confirm the integrity of those backups in an isolated restore before using them, since destruction campaigns frequently target backup repositories too.

Decide early on credential rotation. If the initiating account is a privileged or shared service identity, rotate its credentials and revoke active sessions, then review what else that identity could reach, because the same credentials may have been used elsewhere. Agree on communication roles before the incident grows: who briefs executives, who speaks to regulators or customers if your obligations require it, and who approves restoring from backup. Recovery steps should be rehearsed in advance in your cyber range so the team already knows the restore order, the access needed and the verification checks. Ask your backup and platform owners to confirm, in writing, how long a restore takes for each critical dataset in your environment.

Rehearsing T1485 detection in a private cyber range

A Linux range should mirror production hosts that hold business data, with the same logging agents, file integrity monitoring and backup agent the production estate runs. Place a small set of data-bearing hosts behind a segmented management network, and keep a separate collector for the SIEM so the exercise does not depend on the systems under test. Injects should describe destructive file activity in abstract terms, such as a burst of file removals or overwrites against a designated dataset directory outside normal maintenance windows, rather than as scripts or commands.

Topology: Two or three data hosts, one SIEM or Wazuh manager, one backup target and one jump host, all isolated from corporate networks.
Injects: Mass deletion or overwrite of a seeded dataset, performed by a designated service account, timed to fall outside change windows.
Detection: Alerts on Process Creation and Command Execution from unexpected parents, plus File Deletion or File Creation volume spikes on protected paths, correlated to the account.
Response: Isolate the host, freeze the account, preserve the evidence and confirm which backup set is the last known good copy before any restore starts.
Communication: Record who is notified, in what order, and how the incident commander decides when the business owner is informed.

Check that the exercise records the time from first alert to isolation and the time from declaration to a verified restore, and compare both against the response plan your organization has documented.

Questions SOC leads ask about T1485 detection

How do I tell destructive deletion apart from routine cleanup?

Judge the deletion by context, not by the delete event alone. Routine cleanup usually follows a schedule, runs under a known service identity, touches temporary or expired paths, and leaves logs and backups intact. Destructive deletion tends to hit business data directory trees in bulk, run from an unexpected parent process or interactive session, come shortly after an unusual logon, and often coincides with attempts to remove backups or logs. Build your Sigma or Wazuh rules to score these attributes together, and maintain an allowlist of approved maintenance jobs with owners and change tickets. Review the allowlist after each ATT&CK version update, because the detection strategies and data components that inform your logic can change between releases.

Which data sources should a SOC onboard first for T1485?

Start with the data components that ATT&CK most often references for Impact techniques: Process Creation (DC0032), Command Execution (DC0064) and File Deletion (DC0040), with File Creation (DC0039) to catch overwrite-style activity. Add Application Log Content (DC0038) for audit trails from hosts, hypervisors and cloud control planes, and Network Traffic Content (DC0085) where you can inspect it legally and technically. Confirm the coverage of each source in your own environment before you write rules. Telemetry from backup systems and file server audit logs is often the most useful evidence of scale, so verify that those logs are forwarded and retained long enough to investigate.

How do I validate T1485 detections without risking production data?

Validate in a private cyber range that mirrors your production logging pipeline, not in production. Use synthetic datasets, dedicated test shares and disposable virtual machines, and confirm that each event reaches your SIEM with the fields your rules expect. Record what you ran, when, and which rule fired, so the result can be replayed after a tuning change. Measure both detection and false positives against your allowlist. DeployOpen can plan and run this kind of exercise inside your environment as a fixed-scope engagement, with scope and deliverables agreed in writing before work starts.

How should we version ATT&CK mappings across releases?

Record the ATT&CK version each detection targets in the rule metadata, and treat that version as part of the rule's identity. ATT&CK releases can rename, deprecate or revoke techniques, and v18 changed how detections are presented in technique pages by introducing detection strategies and analytics. Keep a changelog that lists the technique, sub-technique, detection strategy and data component IDs each rule relies on. When a new version is published, diff the mappings against the STIX bundle for that version and retest affected rules in the range. Confirm the exact release notes with MITRE before you change mappings.

How do backups change the response to T1485?

Verified, isolated backups turn data destruction from an unrecoverable event into a bounded recovery task, which is why ATT&CK maps Data Backup (M1053) to this technique. Your response runbook should confirm the age and integrity of the last clean backup, check whether backup credentials or repositories were reachable from the affected systems, and decide the restore point based on the timeline of deletions. Test restores on a schedule so the recovery time is known rather than assumed. Backups that share credentials or network paths with production may also be destroyed, so verify separation during design and rehearsal.

How does User Account Management limit data destruction?

User Account Management (M1018) reduces the set of identities that can delete data at scale. Map which accounts hold delete or administrative rights on file shares, hypervisors, containers and cloud storage, and remove standing privileges that no longer have a business need. Use separate accounts for administration and daily work, and alert on new or dormant accounts that gain delete rights. Review these permissions on a regular cadence and after organizational changes, and keep the evidence for your access review.

What should a cyber range rehearsal of T1485 prove?

A rehearsal should prove three things: that the telemetry is present, that the detection fires with an acceptable false positive rate, and that the responders can act on the alert within your documented procedures. Script the scenario so each step has a known expected event, then compare what your SIEM recorded against that expectation. Include a backup-recovery drill so the team checks the restore path, not only the alert. Capture gaps as tickets with owners, and rerun the scenario after each fix. Confirm the rehearsal scope with your legal and change management teams before you start.

How DeployOpen engineers this detection

DeployOpen builds the T1485 Data destruction detection as a set of open-source rules that are tied to specific telemetry: process creation and command execution on Linux and container hosts, file creation and file deletion on the storage paths that hold your critical data, and the ESXi and IaaS audit trails that record administrative actions against datastores and volumes. Each rule is written against the ATT&CK version the client agrees to, because technique IDs, detection strategies and data component IDs can change between releases. The first decision is which of your backup repositories, shares and hypervisor datastores are treated as high-value, since that choice determines which file deletion events generate an alert and which are only logged for hunting.

Tuning starts with your own baseline rather than a generic threshold. DeployOpen reviews normal backup rotation, log archiving, build artifact cleanup and storage maintenance jobs with your operations team, then builds allowlists that match named service accounts, schedules and host groups. Purple team exercises then run the agreed scenarios in a private cyber range, with the blue team watching alerts in the same Wazuh, Security Onion or other SIEM stack used in production. The output is a written record of which events fired, how long triage took, and which gaps remain, so you can judge whether the detection is ready for production. Ask for that record to be part of every deliverable.

Range scenarios are designed in writing before any work begins. The scope names the platforms in play, the data classes involved, the roles that may approve a test, and the stop conditions that end an exercise. Scenarios use isolated copies of your systems, never production data, and each one maps to the detection it is meant to exercise. Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing with a quote that follows from that scope. Confirm with DeployOpen which tooling versions, access levels and retention periods the work will assume, and whether ongoing tuning is needed after go-live under a separate retainer.

How DeployOpen builds T1485 detections and range exercises

DeployOpen works on T1485 Data destruction as a fixed-scope engagement inside the client's own infrastructure, with the scope agreed in writing before any work starts. The work covers detection content, telemetry, response steps and rehearsal in a private cyber range, documented so the client's own teams can run and maintain it.

How we scope

Confirm which platforms in your estate hold data that a destructive actor could target, such as Linux hosts, containers, ESXi and IaaS workloads.
Agree which telemetry sources exist today for Process Creation, Command Execution and File Creation, and where gaps need closing.
Record the ATT&CK version the detection mapping targets, and the mitigations in scope, including Data Backup and User Account Management.

How we build

Implement detection logic for T1485 in open-source tooling such as Wazuh, Sigma rules and Security Onion, mapped to the agreed data components.
Tune rules against your normal administrative activity, such as scheduled jobs and backup tooling, to reduce false positives before handover.
Validate that the required logs reach the SIEM with the fields the detections depend on, and document any gaps that remain.

How we hand over

Deliver written runbooks for triage, escalation and containment of suspected data destruction events, with named owners in your team.
Run rehearsal exercises in a private cyber range so your responders practice the detections and response steps before a real incident.
Provide documentation and evidence of detection tests so your compliance and audit teams can review how the controls operate.

How we support

Ongoing support, upgrades and continuous testing of the T1485 detections are available as a retainer after the fixed-scope work ends.
Re-check detection mappings when MITRE ATT&CK releases rename, deprecate or revoke techniques, and record each change in the documentation.
Confirm with your team which backup and recovery owners need to be involved in future rehearsals, and schedule them in the agreed scope.

T1485 Data destruction