Destructive file wipe
A command was run whose purpose is to make data unrecoverable rather than merely to delete it.
What it detects
A command was run whose purpose is to make data unrecoverable rather than merely to delete it. Three shapes, all of them deliberate:
* shred — overwrites a file's blocks before unlinking it, so the content cannot be carved back off the disk. * rm --no-preserve-root — the flag exists only to defeat the guard that stops rm -rf /. Nobody types it by accident; it is typed to remove the safety. * dd writing from /dev/zero or /dev/urandom over a target — the classic wipe, and the same primitive used to blank a disk or a partition.
This is destruction, not cleanup, and in an intrusion it is usually either anti-forensics (destroying the logs and tooling that would explain the breach) or the impact stage itself.
MITRE ATT&CK mapping
- T1485Data Destruction· Impact
False positives and triage
There are legitimate uses and they are recognisable:
* Secure decommissioning. Wiping a disk before returning or reselling hardware is dd if=/dev/zero of=/dev/sdX or shred /dev/sdX — a whole DEVICE, run by an administrator, usually on a host that is being retired. * Benchmarking and file creation. dd if=/dev/zero of=testfile bs=1M count=1024 creates a large file rather than destroying one; the giveaway is that the target did not exist before. * Compliance tooling. Some data-retention jobs shred files on a schedule. If yours does, suppress that specific path and user, not the rule.
Escalate immediately when the target is a log directory, a backup, a database file, or a block device on a live system, and when it follows other suspicious activity on the same host — a wipe late in an intrusion is the attacker closing the door behind them, and the surrounding evidence is what you have left.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/linux/destructive_wipe.yaml, licensed under the Apache License 2.0.
id: linux.impact.destructive_file_wipe
version: 1.0.0
status: stable
severity: critical
platforms: [linux]
confidence: 0.75
mitre_techniques: [T1485]
description: |
A command was run whose purpose is to make data unrecoverable rather than merely
to delete it. Three shapes, all of them deliberate:
* `shred` — overwrites a file's blocks before unlinking it, so the content cannot
be carved back off the disk.
* `rm --no-preserve-root` — the flag exists only to defeat the guard that stops
`rm -rf /`. Nobody types it by accident; it is typed to remove the safety.
* `dd` writing from `/dev/zero` or `/dev/urandom` over a target — the classic wipe,
and the same primitive used to blank a disk or a partition.
This is destruction, not cleanup, and in an intrusion it is usually either
anti-forensics (destroying the logs and tooling that would explain the breach) or
the impact stage itself.
match:
command_line_regex: '(?i)(\bshred\b|--no-preserve-root|\bdd\b[^\n]*\bif=/dev/(zero|u?random)\b)'
false_positive_guidance: |
There are legitimate uses and they are recognisable:
* Secure decommissioning. Wiping a disk before returning or reselling hardware is
`dd if=/dev/zero of=/dev/sdX` or `shred /dev/sdX` — a whole DEVICE, run by an
administrator, usually on a host that is being retired.
* Benchmarking and file creation. `dd if=/dev/zero of=testfile bs=1M count=1024`
creates a large file rather than destroying one; the giveaway is that the target
did not exist before.
* Compliance tooling. Some data-retention jobs shred files on a schedule. If yours
does, suppress that specific path and user, not the rule.
Escalate immediately when the target is a log directory, a backup, a database file,
or a block device on a live system, and when it follows other suspicious activity
on the same host — a wipe late in an intrusion is the attacker closing the door
behind them, and the surrounding evidence is what you have left.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.