Recursive file deletion or secure-overwrite command line

Siemphony@siemphonymediumT1485unverifiedPlaybook · Destructive impact

Detects the command lines MITRE's AN0411 names for data destruction — recursive quiet deletes, cipher's free-space wipe, SDelete overwrites and forced recursive Remove-Item. Every selection matches on `CommandLine` alone so the rule is a single-field OR that all backends render, and the flag combinations use `contains|all` because operators reorder switches freely. The analytic's actual discriminator is volume — MITRE's VolumeThreshold and TimeWindow knobs count unique files destroyed by one process — which Sigma cannot express, so this rule fires on a single destructive invocation and the burst has to be judged by the analyst or a downstream aggregation. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0146, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

1title: Recursive file deletion or secure-overwrite command line2id: 418d91f8-a952-46d8-b5ce-ecafe7b851df3status: experimental4description: |5  Detects the command lines MITRE's AN0411 names for data destruction — recursive6  quiet deletes, cipher's free-space wipe, SDelete overwrites and forced recursive7  Remove-Item. Every selection matches on `CommandLine` alone so the rule is a8  single-field OR that all backends render, and the flag combinations use9  `contains|all` because operators reorder switches freely. The analytic's actual10  discriminator is volume — MITRE's VolumeThreshold and TimeWindow knobs count11  unique files destroyed by one process — which Sigma cannot express, so this rule12  fires on a single destructive invocation and the burst has to be judged by the13  analyst or a downstream aggregation.14  UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0146, not hand-written and not tested by its author. Any lab result is on this rule's own page.15references:16  - https://attack.mitre.org/techniques/T148517  - https://attack.mitre.org/detectionstrategies/DET014618author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)19date: 2026-08-1620tags:21  - attack.impact22  - attack.t148523logsource:24  category: process_creation25  product: windows26detection:27  selection_del:28    CommandLine|contains|all:29      - 'del '30      - '/s'31      - '/q'32  selection_rmdir:33    CommandLine|contains|all:34      - 'rmdir '35      - '/s'36      - '/q'37  selection_cipher_wipe:38    CommandLine|contains|all:39      - 'cipher'40      - '/w'41  selection_sdelete:42    CommandLine|contains:43      - 'sdelete.exe'44      - 'sdelete64.exe'45  selection_powershell_purge:46    CommandLine|contains|all:47      - 'Remove-Item'48      - '-Recurse'49      - '-Force'50  condition: 1 of selection*51falsepositives:52  - "Build, packaging and deployment scripts that clear an output directory with \\\"rmdir /s /q\\\" or \\\"Remove-Item -Recurse -Force\\\" on every run. These are the highest-volume match by a wide margin and are best separated by the TargetFilename thinking behind MITRE's tuning knob — scope the path, since a build tree is not %System32%, Documents or a database directory."53  - "Disk-hygiene and decommissioning routines — \\\"cipher /w\\\" run by an approved sanitisation job before a machine is reimaged or returned, and SDelete used by administrators to shred a specific file. Both are genuine secure-overwrite activity, which is why ProcessCommandLine alone cannot separate them from a wiper; the operator identity and the scheduled window are what distinguish them."54  - "Installer and uninstaller cleanup, which routinely issues quiet recursive deletes against %TEMP% and its own program directory during a normal software servicing window."55  - "Log and cache rotation tasks that call \\\"forfiles\\\" or a cmd one-liner ending in \\\"del /s /q\\\" against an application log directory on a fixed schedule."56level: medium

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where ((ProcessCommandLine contains "del " and ProcessCommandLine contains "/s" and ProcessCommandLine contains "/q") or (ProcessCommandLine contains "rmdir " and ProcessCommandLine contains "/s" and ProcessCommandLine contains "/q") or (ProcessCommandLine contains "cipher" and ProcessCommandLine contains "/w") or (ProcessCommandLine contains "sdelete.exe" or ProcessCommandLine contains "sdelete64.exe") or (ProcessCommandLine contains "Remove-Item" and ProcessCommandLine contains "-Recurse" and ProcessCommandLine contains "-Force"))

Splunk · SPL

Run this as a search.

index=* ((CommandLine="*del *" AND CommandLine="*/s*" AND CommandLine="*/q*") OR (CommandLine="*rmdir *" AND CommandLine="*/s*" AND CommandLine="*/q*") OR (CommandLine="*cipher*" AND CommandLine="*/w*") OR (CommandLine="*sdelete.exe*" OR CommandLine="*sdelete64.exe*") OR (CommandLine="*Remove-Item*" AND CommandLine="*-Recurse*" AND CommandLine="*-Force*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(process.command_line) LIKE "*del *" AND TO_LOWER(process.command_line) LIKE "*/s*" AND TO_LOWER(process.command_line) LIKE "*/q*") OR (TO_LOWER(process.command_line) LIKE "*rmdir *" AND TO_LOWER(process.command_line) LIKE "*/s*" AND TO_LOWER(process.command_line) LIKE "*/q*") OR (TO_LOWER(process.command_line) LIKE "*cipher*" AND TO_LOWER(process.command_line) LIKE "*/w*") OR (TO_LOWER(process.command_line) LIKE "*sdelete.exe*" OR TO_LOWER(process.command_line) LIKE "*sdelete64.exe*") OR (TO_LOWER(process.command_line) LIKE "*remove-item*" AND TO_LOWER(process.command_line) LIKE "*-recurse*" AND TO_LOWER(process.command_line) LIKE "*-force*"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)((?=.*(?:del ))(?=.*(?:/s))(?=.*(?:/q)).*|(?=.*(?:rmdir ))(?=.*(?:/s))(?=.*(?:/q)).*|(?=.*(?:cipher))(?=.*(?:/w)).*|(sdelete\.exe|sdelete64\.exe)|(?=.*(?:Remove-Item))(?=.*(?:-Recurse))(?=.*(?:-Force)).*)</field>    <description>Recursive file deletion or secure-overwrite command line</description>    <mitre>      <id>T1485</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: medium
Category: impact_destruction
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 418d91f8-a952-46d8-b5ce-ecafe7b851df

ATT&CKT1485

T1485Data Destruction

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Evidence

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1485, evaluated against their process_creation events.

Using it

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE's `TargetFilename` knob is the answer the rule's own false-positive
Add 'rd ' and 'erase ' arms.
Add the windash modifier and delimiters so /s stops matching /silent.
Change the conjunction to /s plus one of /q or /f, or drop to /s alone
Knobs that could not be implemented: `VolumeThreshold` and `TimeWindow`

Declared by the author

Build, packaging and deployment scripts that clear an output directory with \"rmdir /s /q\" or \"Remove-Item -Recurse -Force\" on every run. These are the highest-volume match by a wide margin and are best separated by the TargetFilename thinking behind MITRE's tuning knob — scope the path, since a build tree is not %System32%, Documents or a database directory.
Disk-hygiene and decommissioning routines — \"cipher /w\" run by an approved sanitisation job before a machine is reimaged or returned, and SDelete used by administrators to shred a specific file. Both are genuine secure-overwrite activity, which is why ProcessCommandLine alone cannot separate them from a wiper; the operator identity and the scheduled window are what distinguish them.
Installer and uninstaller cleanup, which routinely issues quiet recursive deletes against %TEMP% and its own program directory during a normal software servicing window.
Log and cache rotation tasks that call \"forfiles\" or a cmd one-liner ending in \"del /s /q\" against an application log directory on a fixed schedule.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

Command lines that destroy files in bulk: recursive quiet deletes, cipher's free-space wipe, SDelete, and forced recursive Remove-Item. MITRE's AN0411 describes "command-line tools (e.g., del, cipher /w, SDelete) or scripts to recursively delete or overwrite user/system files ... correlated with abnormal file IO activity." The correlation half is where the technique actually lives: MITRE's VolumeThreshold and TimeWindow knobs count unique files destroyed by one process inside a window. Sigma counts nothing and has no timeframe, so this rule fires on a single destructive invocation and the burst — the thing that distinguishes a wiper from a cleanup script — has to be judged by the analyst or by a downstream aggregation.

02 · Telemetry you need

category: process_creation, product: windows, from AN0411's Sysmon EID 1
One field: CommandLine — and this is the prerequisite that bites. Without
Unused from the brief: file_delete (Sysmon EID 23), which is where deletion

03 · How the logic works

Five selections, OR-ed — there is no AND across selections here, unlike most rules in this corpus:

Why `contains|all` inside each arm. Operators reorder switches freely — del /q /s, del /s /q, del /s C:\x /q. |all requires every term to appear somewhere in the string without fixing their order. That part is right. Why Wazuh refuses this rule. validation.json records the refusal honestly: 1 of selection* is an OR of five AND-groups, and a Wazuh <rule> body is a single conjunction of <field> tests. It would need five separate <rule> blocks. The contract permits this — a correct rule a backend refuses beats a contorted one it accepts — but note the consequence: three backends carry this rule, one does not. Now the three defects, because they are the lesson. 1. The switch terms are unanchored substrings. /s matches /silent, /sync and /scan. /q matches /quiet. /w matches /wait and /warn. selection_cipher_wipe is the weakest arm in the rule: cipher matches any command line containing the word — an OpenSSL --ciphers argument, a directory named Ciphers, a TLS configuration script — so openssl ... -cipher ... /wait satisfies both terms with no wipe involved. Sigma has a windash modifier designed for exactly this, and the rule uses it nowhere. The cheap fixes: include the delimiter ('/s ', '/q ', ' /w') and anchor cipher on cipher.exe or on the pair cipher /w. 2. The two most common forms of the command are missing. rd /s /q C:\Data is the standard cmd alias, shorter to type and used at least as often as the long form — and selection_rmdir requires the literal 'rmdir ', so it matches nothing. erase is the alias of del and is likewise absent. This is not evasion; it is how operators and scripts ordinarily write the command. The rule misses genuinely destructive activity for no gain. 3. `/s` AND `/q` is a conjunction MITRE did not ask for. MITRE's ProcessCommandLine knob names "/w, /q, /s" as alternatives to tune for. del /f /s C:\Users\*.* is fully destructive, recursive and forced — and does not match, because it lacks /q. The quiet flag is cosmetic; it changes console output and nothing else. Requiring it drops real wiper invocations to buy a small amount of noise reduction. One scope note. cipher /w and SDelete overwrite free space and already-deleted remnants. That is anti-forensics — closer to T1070.004 or T1561.001 — rather than destruction of live data, which is what T1485 is. MITRE's AN0411 does name both, so the arms are properly grounded in the brief; just do not read cipher /w as the canonical shape of Data Destruction.

04 · Common false positives

Build, packaging and CI cleanup clearing an output directory with
VDI and roaming-profile logoff cleanup — Citrix/AVD profile teardown,
Approved sanitisation jobs running cipher /w before reimaging, and admins
Installer and uninstaller cleanup against %TEMP%, and scheduled log rotation.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from DET0146 and never executed against a log line. Nothing here has been measured, including the level. To reach
tier_2: enable the command-line audit policy and confirm CommandLine is actually populated, then run the five arms separately over historical data — you will find selection_cipher_wipe and the unanchored /s matching things nobody intended, and you will find rd /s /q in your own scripts that the rule never saw. Fix the anchoring, add the aliases, apply path scoping, then re-level on the observed volume.
tier_3: is the count over a window, which lives in your SIEM's aggregation layer rather than in the rule.

Related detections5 nearby

Ranked by how alike the detection logic reads, computed offline. Proximity is not evidence — each of these carries its own verification state on its own page.

Share this rule

/u/siemphony/418d91f8-a952-46d8-b5ce-ecafe7b851df

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Recursive file deletion or secure-overwrite command line

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it