Block device accessed or a disk-wiping utility run on Linux

Siemphony@siemphonylowT1561.001unverified

Covers both halves of AN0883 on one log source: an auditd PATH record naming a raw block device under /dev, which is what a process overwriting disk content through the storage interface has to open, and an auditd SYSCALL record whose `exe` is one of the utilities that overwrite a device in place. The two legs are ORed rather than combined because auditd splits one execution across records — the tool is on the SYSCALL record and its arguments are on a separate EXECVE record — so `dd if=/dev/urandom of=/dev/sda` cannot be matched as a single event, and each leg is therefore individually loose: the path leg matches a read as readily as a write, and the tool leg matches `dd` whatever it was pointed at. They do catch different things, which is the reason for keeping both: the path leg sees a wipe written directly through a language runtime, where `exe` is python3 or perl and no wipe utility ever executes, while the tool leg still fires when the device path was given relatively — auditd records `name=` exactly as it was passed to the syscall, so `cd /dev && dd of=sda` logs `name="sda"` and no prefix here matches it. The device list is MITRE's `TargetDevices` knob, populated here with the common kernel block-device prefixes rather than taken from MITRE, and it is a prefix match, so partitions such as /dev/sda1 are included. Because auditd records the path as it was passed rather than the resolved target, the udev symlink trees /dev/mapper/ and /dev/disk/by-id, by-uuid and by-path are listed alongside the kernel names — an LVM volume or an encrypted mapping is normally addressed by one of those and never by a /dev/dm- name. MITRE's `EntropyThreshold` knob has no expression here at all: auditd records the syscall, never the bytes written, so a pseudorandom overwrite and a zero-fill are the same event. Two arms of DET0316 are not attempted. AN0882 (Windows) names Security 4673 and Sysmon driver_load, and neither carries a field that can hold a `\\.\PhysicalDrive` path or a sector offset, so its stated observable cannot be written against the sources it names; AN0884 (macOS) offers unifiedlog only, which has no standardised Sigma field names. Tools that destroy the partition table rather than the content — wipefs, sgdisk — are deliberately absent, as that is T1561.002. A wipe run from a busybox or toybox image is also missed, because `exe` is then /bin/busybox. Prerequisite: no distribution audits any of this by default, so the rule returns zero rows until both an execve rule such as `-a always,exit -F arch=b64 -S execve -k exec` and device watches such as `-w /dev/sda -p w -k diskwipe` are loaded — and zero rows reads as quiet when it actually means blind. The watch permission also sets the noise floor: `w` records writes only, while including `r` makes every blkid, lsblk and smartctl scan of the disk match. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0316, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 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

Splunk · SPL

Run this as a search.

index=* ((type="PATH" AND (name="/dev/sd*" OR name="/dev/nvme*" OR name="/dev/vd*" OR name="/dev/xvd*" OR name="/dev/hd*" OR name="/dev/mmcblk*" OR name="/dev/md*" OR name="/dev/dm-*" OR name="/dev/mapper/*" OR name="/dev/disk/*")) OR (type="SYSCALL" AND (exe="*/dd" OR exe="*/shred" OR exe="*/wipe" OR exe="*/nwipe" OR exe="*/scrub" OR exe="*/blkdiscard" OR exe="*/badblocks")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "/dev/sd*" OR TO_LOWER(name) LIKE "/dev/nvme*" OR TO_LOWER(name) LIKE "/dev/vd*" OR TO_LOWER(name) LIKE "/dev/xvd*" OR TO_LOWER(name) LIKE "/dev/hd*" OR TO_LOWER(name) LIKE "/dev/mmcblk*" OR TO_LOWER(name) LIKE "/dev/md*" OR TO_LOWER(name) LIKE "/dev/dm-*" OR TO_LOWER(name) LIKE "/dev/mapper/*" OR TO_LOWER(name) LIKE "/dev/disk/*")) OR (TO_LOWER(type) == "syscall" AND (TO_LOWER(exe) LIKE "*/dd" OR TO_LOWER(exe) LIKE "*/shred" OR TO_LOWER(exe) LIKE "*/wipe" OR TO_LOWER(exe) LIKE "*/nwipe" OR TO_LOWER(exe) LIKE "*/scrub" OR TO_LOWER(exe) LIKE "*/blkdiscard" OR TO_LOWER(exe) LIKE "*/badblocks")))

Wazuh · XML rule

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

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)(^/dev/sd|^/dev/nvme|^/dev/vd|^/dev/xvd|^/dev/hd|^/dev/mmcblk|^/dev/md|^/dev/dm-|^/dev/mapper/|^/dev/disk/)</field>    <description>Block device accessed or a disk-wiping utility run on Linux (1/2)</description>    <mitre>      <id>T1561.001</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^SYSCALL$</field>    <field name="exe" type="pcre2">(?i)(/dd$|/shred$|/wipe$|/nwipe$|/scrub$|/blkdiscard$|/badblocks$)</field>    <description>Block device accessed or a disk-wiping utility run on Linux (2/2)</description>    <mitre>      <id>T1561.001</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: impact_destruction
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 4d51e001-3cf9-44f1-8ecd-6a5db6bdecdb

ATT&CKT1561.001

T1561.001Disk Content Wipe

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.

Lessonimpact destruction

impact destructionAI draft — unreviewed

01 · What this rule detects

Two independent auditd conditions: a PATH record naming a raw block device under /dev, and a SYSCALL record whose exe is a disk-overwriting utility. AN0883 describes the pairing — dd or shred pointed at /dev/sda — but auditd splits one execution across records, the tool on SYSCALL and its arguments on a separate EXECVE, so dd if=/dev/urandom of=/dev/sda cannot be matched as a single event. The rule ORs the halves and accepts that each is individually loose.

02 · Telemetry you need

product: linux / service: auditd, verbatim from AN0883, and raw auditd is the right feed here because the rule reads type, name and exe as auditd emits them. No distribution audits any of this by default. Two audit rules are required: an execve rule such as -a always,exit -F arch=b64 -S execve -k exec for the tool leg, and device watches such as -w /dev/sda -p w -k diskwipe for the path leg. The watch permission sets the noise floor — w records writes only, while adding r makes every blkid, lsblk and smartctl scan match. Pin both to a key: one wipe emits a SYSCALL for the execve plus a SYSCALL/PATH pair for every audited write, so a hit is a burst, not an incident count, and you want to dedupe on key plus PID.

03 · How the logic works

This list is MITRE's TargetDevices knob, populated here by the pipeline — MITRE names the knob and only suggests excluding removable media. It is a prefix match, so partitions such as /dev/sda1 are included. /dev/mapper/ and /dev/disk/ matter more than they look: auditd records name= exactly as passed and never resolves symlinks, so on an LVM or LUKS host the volume is addressed as /dev/mapper/vg0-root and the kernel names alone would match nothing. That same property is the leg's hole — cd /dev && dd of=sda logs name="sda".

The leading slash anchors the binary name. This leg covers the relative-path case the first one misses; the path leg covers the reverse, a wipe written straight through a language runtime where exe is python3 and no wipe utility executes. MITRE's EntropyThreshold knob has nowhere to land: auditd records the syscall, never the bytes, so a zero-fill and a pseudorandom overwrite are the same event.

04 · Common false positives

The dominant source is ordinary dd — swap files, USB installer images, partition backups, benchmarks. The tool leg does not know what dd was pointed at, so all of it matches. Second, provisioning and storage work that opens a device for write with no wipe intended: installer partitioning, cloud-init growing a root partition, mkfs, cryptsetup luksFormat. Third, if the watch carries r, every backup and imaging agent that reads whole devices on a schedule. level: low is the calibration those force.

05 · Detection maturity

tier_1: , and it cannot be higher: UNVERIFIED, derived from DET0316 and never run against a log line.
tier_2: begins by proving the feed exists — load the audit rules, run a harmless dd if=/dev/zero of=/tmp/t bs=1M count=1 and a read of a watched device, and confirm both record shapes arrive with the fields this rule names. Then run read-only through a provisioning cycle and a backup window and convert the survivors into exclusions.
tier_3: is MITRE's correlation, and it lives in your SIEM rather than in this rule.

Tuning & false positivesexperimental · 5 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

Correlate outside Sigma before alerting: join the SYSCALL exe to the PATH
Watch only the devices that matter, and drop r from the watches unless you are
Two gaps no tuning closes: a wipe from a busybox image reports exe of

Declared by the author

Ordinary administrative use of dd, which is a general-purpose copy tool and is almost never pointed at a disk destructively. Creating a swap or test file from /dev/zero, writing an installer image to a USB stick, taking or restoring a partition image, and measuring throughput in a benchmark all execute the same binary, and on any host where someone works at the shell this is the dominant source of hits — which is why this rule is low rather than medium.
Host provisioning and storage maintenance opening the device for write with no wipe intended: installer and kickstart partitioning, cloud-init growing a root partition, LVM and mdadm operations, mkfs creating a filesystem, and cryptsetup luksFormat, which writes over the start of a device as part of setting up encryption.
Backup, imaging and forensic agents that read whole block devices on a schedule — Veeam and Bacula agents, Clonezilla, dump, and snapshot jobs — every one of which produces matching PATH records if the device watch was loaded with the r permission.
Sanctioned decommissioning and media-sanitisation workflows, where shred, nwipe, scrub or blkdiscard is run deliberately against a disk being retired or a lab machine being rebuilt; the command is byte-for-byte what a destructive attack looks like and is separated from it only by change record and timing.
Storage diagnostics: badblocks in its destructive write-mode test, and vendor health scripts that call it, run legitimately when an administrator is qualifying a suspect disk.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 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.

Verification1 run

Not verified

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

Test it yourselfin your browser

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

Recordings of T1561.001, evaluated against their — events.

Share this rule

/u/siemphony/4d51e001-3cf9-44f1-8ecd-6a5db6bdecdb

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.

Block device accessed or a disk-wiping utility run on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it