T1561

Disk Wipe

Impact Last updated:

Adversaries may wipe or corrupt raw disk data on specific systems or across a network to interrupt availability to system and network resources. With direct write access to a disk, adversaries may attempt to overwrite arbitrary portions of disk data or target critical disk structures such as the Master Boot Record (MBR) or Volume Boot Record (VBR). A complete wipe of all disk sectors may be attempted using built-in OS utilities, third-party tools, or custom malware. Real-world destructive campaigns using this technique include Shamoon (Saudi Aramco, 2012), WhisperGate (Ukraine, 2022), HermeticWiper (Ukraine, 2022), and Destover (Sony, 2014). Wiper malware frequently chains multiple TA0040 techniques: disabling VSS/recovery first, then overwriting disk content, then corrupting disk structure, to maximize recovery difficulty.

What is T1561 Disk Wipe?

Disk Wipe (T1561) maps to the Impact tactic — the adversary is trying to manipulate, interrupt, or destroy your systems and data in MITRE ATT&CK.

This page provides production-ready detection logic for Disk Wipe, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated critical severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Impact
Technique
T1561 Disk Wipe
Canonical reference
https://attack.mitre.org/techniques/T1561/
Microsoft Sentinel / Defender
kusto 
let KnownWipingTools = dynamic([
  "dd.exe", "diskpart.exe", "format.exe", "cipher.exe", "sdelete.exe",
  "wipe.exe", "eraser.exe", "nwipe.exe", "hdderase.exe", "killdisk.exe",
  "bcdedit.exe", "vssadmin.exe", "wevtutil.exe"
]);
let RawDiskPatterns = dynamic([
  "\\\\.\\PhysicalDrive", "\\\\.\\HarddiskVolume", "\\\\.\\GLOBALROOT",
  "if=/dev/zero", "if=/dev/random", "if=/dev/urandom",
  "of=/dev/sd", "of=/dev/hd", "of=/dev/nvme"
]);
let WipeCommandPatterns = dynamic([
  "clean all", "/p:1", "/p:2", "/p:3", "/p:4", "/p:5", "/p:6", "/p:7",
  "cipher /w", "cipher /W", "-z ", "-zd ", "-c ",
  "delete shadows", "shadowcopy delete", "Delete Shadows /All",
  "recoveryenabled No", "recoveryenabled no",
  "bcdedit /set", "wevtutil cl ", "wevtutil.exe cl"
]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where (FileName in~ (KnownWipingTools) and ProcessCommandLine has_any (WipeCommandPatterns))
    or ProcessCommandLine has_any (RawDiskPatterns)
| extend RawDiskAccess = ProcessCommandLine has_any ("\\\\.\\PhysicalDrive", "\\\\.\\HarddiskVolume", "if=/dev/zero", "if=/dev/random")
| extend DiskPartWipe = FileName =~ "diskpart.exe" and ProcessCommandLine has "clean"
| extend FormatSecureWipe = FileName =~ "format.exe" and ProcessCommandLine matches regex @"/p:[1-9]"
| extend CipherWipe = FileName =~ "cipher.exe" and (ProcessCommandLine has "/w" or ProcessCommandLine has "/W")
| extend SDeleteWipe = FileName =~ "sdelete.exe" and ProcessCommandLine has_any ("-z", "-zd", "-c", "/z", "/c")
| extend VSSDelete = ProcessCommandLine has_any ("delete shadows", "shadowcopy delete", "Delete Shadows /All", "Delete Shadows /all")
| extend BootRecoveryDisable = FileName =~ "bcdedit.exe" and ProcessCommandLine has "recoveryenabled"
| extend AuditLogClear = FileName =~ "wevtutil.exe" and ProcessCommandLine has_any ("cl ", "clear-log")
| extend WipeScore = toint(RawDiskAccess) + toint(DiskPartWipe) + toint(FormatSecureWipe) + toint(CipherWipe) + toint(SDeleteWipe) + toint(VSSDelete) + toint(BootRecoveryDisable) + toint(AuditLogClear)
| where WipeScore > 0
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         RawDiskAccess, DiskPartWipe, FormatSecureWipe, CipherWipe, SDeleteWipe,
         VSSDelete, BootRecoveryDisable, AuditLogClear, WipeScore
| sort by WipeScore desc, Timestamp desc

Detects disk wiping activity using Microsoft Defender for Endpoint DeviceProcessEvents. Identifies execution of known wiping tools (diskpart, dd, sdelete, cipher, format) with destructive flags, raw disk device path access (\\PhysicalDrive, \\HarddiskVolume), Volume Shadow Copy deletion (precursor to wiping), boot recovery disabling via bcdedit, and audit log clearing. A composite WipeScore is computed per event to prioritize detections with multiple co-occurring indicators, which is characteristic of multi-stage destructive malware campaigns.

critical severity high confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • IT operations using diskpart clean or format /p: for decommissioning hardware before asset disposal or reimaging
  • Security teams running SDelete or cipher /w as part of data sanitization workflows on endpoints being retired
  • Backup and disaster recovery software (Acronis, Veeam) that accesses raw PhysicalDrive handles during bare-metal restore operations
  • Forensic tools (FTK Imager, dd for Windows) used by incident responders that access \\PhysicalDrive paths for imaging
  • System administrators using vssadmin delete shadows as part of scheduled disk space reclamation on servers with large VSS allocations

Sigma rule & cross-platform mapping

The detection logic for Disk Wipe (T1561) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1561 Sigma rules on detection.fyi

Platform-specific guides for T1561

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-20 Research depth: deep
References (11)

Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1VSS Shadow Copy Deletion via vssadmin (Pre-Wipe Preparation)

    Expected signal: Sysmon Event ID 1: Process Create with Image=vssadmin.exe, CommandLine='vssadmin delete shadows /all /quiet'. Security Event ID 4688 (if command line auditing enabled). No Sysmon Event ID 3 expected (local operation). Parent process will be cmd.exe or powershell.exe in test context.

  2. Test 2Boot Recovery Disable via bcdedit (Pre-Wipe Preparation)

    Expected signal: Sysmon Event ID 1: two Process Create events for bcdedit.exe — first with CommandLine containing 'recoveryenabled No', second with 'bootstatuspolicy ignoreallfailures'. Security Event ID 4688 for both (if command line auditing enabled). No network events expected.

  3. Test 3Secure Free Space Overwrite via cipher /w

    Expected signal: Sysmon Event ID 1: Process Create with Image=cipher.exe, CommandLine='cipher /w:C:\Users\...\AppData\Local\Temp' (path will be expanded). Sysmon Event ID 11: multiple temporary file creation events (EFSTMPWP.tmp files) in the target directory as cipher creates temporary overwrite files. Process will run for several seconds to minutes depending on free space.

  4. Test 4Diskpart Disk Clean via Script File (Simulated — Uses Virtual Disk)

    Expected signal: Sysmon Event ID 1: two Process Create events for diskpart.exe — first with /s dp_create.txt (VHD creation), second with /s dp_wipe.txt (clean all). Sysmon Event ID 11: file creation events for the .vhd and .txt script files in %TEMP%. The actual 'clean all' command is in the script file, not the command line, so analysts should correlate with file creation of the script files.

  5. Test 5Linux Raw Disk Overwrite Simulation via dd (File Target — Safe)

    Expected signal: Linux auditd EXECVE record with comm=dd, a0=if=/dev/zero, a1=of=/tmp/argus_wipe_test.bin. Syslog process creation record. If Falco is deployed: process_started rule matching dd with if=/dev/zero pattern. The command generates 40MB written to disk — watch for I/O spike in monitoring. Note: real wiper uses of=/dev/sda or similar block device path.

Response Playbook

Triage

  1. Immediately check the WipeScore — any score of 3 or higher indicates multi-stage destructive activity and warrants emergency escalation without waiting for further triage steps
  2. Identify whether the detection is pre-wipe (VSS deletion, bcdedit recovery disable) or active-wipe (raw disk access, diskpart clean all, format /p:N). Pre-wipe detections give you a narrow containment window before data destruction begins
  3. Check the initiating process — wiper malware commonly spawns from LOLBins (cmd.exe, wscript.exe, mshta.exe), dropped executables in %TEMP% or %APPDATA%, or service-based execution. Legitimate disk sanitization is run interactively from admin shells or managed tools
  4. Verify the user context — disk wiping operations require SYSTEM or local administrator privileges. A standard user account executing these commands indicates credential abuse or privilege escalation has already occurred
  5. Check for lateral propagation indicators — query DeviceNetworkEvents and DeviceLogonEvents for the same device and account in the past 24 hours. Wiper campaigns often use SMB/admin shares (T1021.002) or WMI to propagate before triggering
  6. Run concurrent check: `Get-WmiObject Win32_ShadowCopy | Select-Object ID, VolumeName, InstallDate` on the affected host to determine if VSS snapshots still exist (recovery window still open) or have already been deleted
  7. Check audit log integrity on the affected host: query Security Event ID 1102 (Security log cleared) and System log for Event ID 104 (System log cleared). Wiper malware frequently clears logs to impede forensics

Containment

  1. IMMEDIATELY isolate the affected host from the network using EDR network isolation or emergency VLAN change — disk wiping is irreversible once sector overwriting begins, and worm-propagation to other hosts must be stopped
  2. If the detection is pre-wipe (VSS deletion detected but no raw disk access yet): suspend the offending process (do not kill — preserve memory forensics) and initiate emergency backup of critical data before proceeding
  3. Disable the compromised account in Active Directory immediately and revoke all active Kerberos tickets: `net user <username> /active:no` and force KRBTGT double-reset if domain admin credentials were involved
  4. If wiper propagation via SMB is suspected, block TCP/445 at the perimeter and between network segments via emergency ACL or firewall rule change. Identify all hosts the compromised account has authenticated to in the past 4 hours
  5. Do NOT reboot the affected system until memory acquisition is complete — volatile evidence (injected code, in-memory encryption keys) will be lost
  6. Preserve disk state immediately: if disk wiping is in progress, a forensic image of unaffected sectors may still be recoverable. Engage incident response team for emergency triage imaging before the wipe process completes
  7. Revoke any service account credentials on the affected host that may have been cached — mimikatz-style credential harvesting (T1003) typically precedes networked wiper deployment

Evidence Collection

  1. Memory acquisition (priority #1 if process is still running): use WinPmem, Magnet RAM Capture, or EDR memory dump capability. In-memory wiper code may contain C2 addresses, decryption keys, or target lists not present on disk
  2. Disk image: full forensic image of PhysicalDrive0 (and additional drives) using dd, FTK Imager, or dc3dd. Even partially overwritten disks may contain recoverable file fragments in non-targeted sectors
  3. Sysmon Event ID 1 (Process Create): full command line of all wiping tool executions with parent process chain
  4. Sysmon Event ID 3 (Network Connection): any outbound connections from the wiping process or its parent — may reveal C2 infrastructure
  5. Sysmon Event ID 11 (File Create): any payload files dropped before execution — note paths in %TEMP%, %APPDATA%, C:\Windows\Temp
  6. Security Event ID 4688 (Process Create with command line auditing): corroborates Sysmon process data, captures processes missed by Sysmon
  7. Security Event ID 1102 / System Event ID 104: audit log cleared events confirm attacker attempted evidence destruction
  8. Security Event ID 4672: special privilege logon — identifies when high-privilege accounts were used to initiate wiping
  9. Security Event ID 4648 (explicit credentials logon): may show credential relay used for lateral movement before wiping
  10. VSS status: `vssadmin list shadows` — document which snapshots still exist and their creation timestamps
  11. Prefetch files: C:\Windows\Prefetch\ for any wiping tool executables — timestamps reveal first/last execution
  12. Network captures (if available): PCAP for the 30 minutes preceding the alert — SMB connections indicate propagation path

Escalation Criteria

  • ! WipeScore of 3 or higher — multi-stage destructive activity (VSS deletion + recovery disable + disk wipe) is a confirmed destructive campaign, not a false positive
  • ! Raw disk device access (\\PhysicalDrive or \\HarddiskVolume) detected — any direct sector-level write to a physical disk in a non-IT-decom context is an automatic critical escalation
  • ! Evidence of lateral propagation: same wiper indicators observed on 2 or more hosts within a 30-minute window indicates active worm propagation and requires immediate enterprise-wide response
  • ! Domain controller or backup server affected: loss of AD or backup infrastructure multiplies recovery complexity by orders of magnitude
  • ! VSS deletion confirmed with no corresponding change ticket or IT operation — pre-wipe preparation is underway and action window is minutes
  • ! SYSTEM-context execution of wiping tools from a non-service executable path (e.g., from %TEMP% or a user profile directory) — indicates payload delivery and privilege escalation have already succeeded

Investigation Guide

Forensic Artifacts

  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services — any newly created services with suspicious binary paths may be the wiper installation mechanism
  • > Registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks — scheduled tasks used to trigger wiper at a specific time or on reboot
  • > File System: C:\Windows\Prefetch\ — prefetch entries for dd.exe, diskpart.exe, sdelete.exe, format.exe reveal execution timestamps and frequency
  • > File System: %TEMP%, %APPDATA%\Roaming, C:\Windows\Temp — common drop locations for wiper payloads; check for executables, batch files, and scripts created near the incident time
  • > Windows Event Log: Security Event ID 1102 (audit log cleared) and System Event ID 104 (system log cleared) — timestamps relative to wipe activity
  • > Windows Event Log: Security Event ID 7045/4697 (new service installed) — wiper deployed as a service
  • > Windows Event Log: Security Event ID 4688 (process creation) — requires command line auditing enabled (GPO: Audit Process Creation -> Include command line)
  • > Volume Shadow Copies: vssadmin list shadows output (if run before deletion) documents pre-wipe state; absence of shadows confirms T1490 execution
  • > MFT (Master File Table): even on partially wiped disks, the MFT may contain directory entries and file metadata for deleted files, useful for reconstructing what was targeted
  • > USN Journal ($UsnJrnl:$J): records file change operations including deletions and overwrites; timestamps help reconstruct the sequence of destruction
  • > Sysmon operational log: Microsoft-Windows-Sysmon/Operational — Event IDs 1, 3, 11, 12, 13 for process/network/file/registry telemetry around the incident
  • > Network: DNS query logs for the affected host in the 24 hours prior — C2 infrastructure lookups typically precede wiper deployment

Tuning Guidance

The highest-fidelity signal for T1561 is raw disk device access (\\PhysicalDrive, \\HarddiskVolume) combined with a non-system user context — legitimate disk management at this level is almost exclusively done by SYSTEM-context services or kernel drivers, not interactive users. Build an allowlist of specific IT decommission workflows (asset disposal scripts, imaging pipelines) by capturing their exact process lineage (parent process + command line + user account + source host) and excluding those combinations. For VSS deletion detections, create a change management integration: if a vssadmin delete shadows or wmic shadowcopy delete command is not accompanied by a same-day change ticket for the affected host, treat it as suspicious. Tune the WipeScore threshold based on your environment — most enterprises should alert at score ≥ 1 for raw disk access (no legitimate scenario), score ≥ 2 for tool combinations (some IT ops false positives), and escalate immediately at score ≥ 3 (confirmed multi-stage destructive sequence). On file servers and domain controllers, consider alerting at any score ≥ 1 regardless of context. For Linux environments, supplement with auditd rules watching for dd, shred, and wipefs process creation and for write system calls to raw block device paths (/dev/sd*, /dev/hd*, /dev/nvme*).

Hunting Queries

Hunt for multi-stage destructive preparation sequences on a single host within a 60-minute window. Real wiper malware chains VSS deletion, recovery disabling, and log clearing in rapid succession. Two or more distinct preparation stages from the same host and account in under an hour is a high-fidelity indicator of an active destructive campaign, distinct from single-stage legitimate IT operations.

Hunting — KQL
kql 
let LookbackWindow = 7d;
DeviceProcessEvents
| where Timestamp > ago(LookbackWindow)
| where ProcessCommandLine has_any ("delete shadows", "shadowcopy delete", "Delete Shadows /All", "recoveryenabled No", "wevtutil cl ", "cipher /w", "diskpart", "clean all")
| summarize
    Commands=make_set(ProcessCommandLine),
    Tools=make_set(FileName),
    FirstSeen=min(Timestamp),
    LastSeen=max(Timestamp),
    EventCount=count()
  by DeviceName, AccountName
| where array_length(Tools) >= 2
| extend TimespanMinutes = datetime_diff('minute', LastSeen, FirstSeen)
| where TimespanMinutes <= 60
| sort by EventCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 earliest=-7d
  (CommandLine="*delete shadows*" OR CommandLine="*shadowcopy delete*" OR CommandLine="*recoveryenabled No*"
   OR CommandLine="*wevtutil cl*" OR CommandLine="*cipher /w*" OR CommandLine="*diskpart*" OR CommandLine="*clean all*")
| eval cmd_type=case(
    match(CommandLine,"(?i)delete shadows|shadowcopy delete"), "VSS_Delete",
    match(CommandLine,"(?i)recoveryenabled"), "RecoveryDisable",
    match(CommandLine,"(?i)wevtutil\\s+cl"), "LogClear",
    match(CommandLine,"(?i)cipher\\s+/w"), "FreeSpaceWipe",
    match(CommandLine,"(?i)diskpart"), "Diskpart",
    true(), "Other")
| stats dc(cmd_type) as UniqueStages, values(cmd_type) as Stages, values(CommandLine) as Commands, earliest(_time) as First, latest(_time) as Last by host, User
| where UniqueStages >= 2
| eval DurationMinutes=round((Last-First)/60,1)
| where DurationMinutes <= 60
| sort - UniqueStages

Hunt for any process accessing raw physical disk device paths outside of known legitimate system contexts. Direct \\PhysicalDrive access by user-context processes or unexpected parent processes is anomalous and indicates either a disk wiping tool or a forensic tool running in an unauthorized context. Filters out known-legitimate system processes (MsMpEng for Windows Defender, services.exe, winlogon) to reduce noise from OS-level disk operations.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("\\\\.\\PhysicalDrive", "\\\\.\\HarddiskVolume0", "\\\\.\\HarddiskVolume1", "\\\\.\\HarddiskVolume2")
| where AccountName !in~ ("SYSTEM", "Administrator") or InitiatingProcessFileName !in~ ("services.exe", "svchost.exe", "MsMpEng.exe", "winlogon.exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 earliest=-7d
  (CommandLine="*\\\\.\\PhysicalDrive*" OR CommandLine="*\\\\.\\HarddiskVolume*")
  NOT (User="NT AUTHORITY\\SYSTEM" AND (ParentImage="*\\services.exe" OR ParentImage="*\\MsMpEng.exe" OR ParentImage="*\\winlogon.exe"))
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time

Hunt for hosts where VSS/recovery deletion was observed, then look for orchestration activity from those same hosts — unusual volumes of child process spawning from command interpreters. This pattern identifies the orchestration layer of wiper malware that automates multiple destruction tasks via cmd.exe or PowerShell after disabling recovery mechanisms.

Hunting — KQL
kql 
let SuspectHosts = DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("delete shadows", "shadowcopy delete", "recoveryenabled No")
| distinct DeviceName;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName in (SuspectHosts)
| where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe")
| summarize
    ChildProcesses=make_set(FileName),
    Commands=make_set(ProcessCommandLine),
    Count=count()
  by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| where Count > 10
| sort by Count desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 earliest=-7d
  (CommandLine="*delete shadows*" OR CommandLine="*shadowcopy delete*" OR CommandLine="*recoveryenabled No*")
| stats values(host) as AffectedHosts by _time
| fields AffectedHosts
| mvexpand AffectedHosts
| rename AffectedHosts as host
| join type=inner host
    [search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 earliest=-7d
     (Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe")
    | stats count as ChildCount, values(Image) as ChildImages, values(CommandLine) as ChildCmds by host, ParentImage, User]
| where ChildCount > 10
| table host, User, ParentImage, ChildCount, ChildImages, ChildCmds
| sort - ChildCount

Atomic Red Team Tests

Test 1 VSS Shadow Copy Deletion via vssadmin (Pre-Wipe Preparation)
windows

Deletes all Volume Shadow Copies using vssadmin — the most common first step executed by wiper malware (Shamoon, WhisperGate, HermeticWiper) to prevent recovery from snapshots. This test requires administrator privileges and will delete actual VSS snapshots on the test system. Run only in a disposable VM.

Command

powershell 
vssadmin delete shadows /all /quiet

Cleanup

powershell 
REM VSS snapshots cannot be restored after deletion. Ensure test is run in a VM with no important snapshots.

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=vssadmin.exe, CommandLine='vssadmin delete shadows /all /quiet'. Security Event ID 4688 (if command line auditing enabled). No Sysmon Event ID 3 expected (local operation). Parent process will be cmd.exe or powershell.exe in test context.

Expected Detection

KQL: VSSDelete=true, WipeScore >= 1. SPL: VSSDelete=1, WipeScore >= 1. Alert severity: high. Maps to T1490 (Inhibit System Recovery) as a co-occurring precursor technique.

Test 2 Boot Recovery Disable via bcdedit (Pre-Wipe Preparation)
windows

Disables Windows Recovery Environment and automatic repair using bcdedit — prevents the OS from booting into recovery mode after the wiper corrupts the disk. Used by ransomware and wiper malware to prevent recovery. Requires administrator privileges.

Command

powershell 
bcdedit /set {default} recoveryenabled No && bcdedit /set {default} bootstatuspolicy ignoreallfailures

Cleanup

powershell 
bcdedit /set {default} recoveryenabled Yes && bcdedit /deletevalue {default} bootstatuspolicy

Expected Telemetry

Sysmon Event ID 1: two Process Create events for bcdedit.exe — first with CommandLine containing 'recoveryenabled No', second with 'bootstatuspolicy ignoreallfailures'. Security Event ID 4688 for both (if command line auditing enabled). No network events expected.

Expected Detection

KQL: BootRecoveryDisable=true, WipeScore >= 1. SPL: BootRecoveryDisable=1. The two-command sequence within seconds of each other strengthens confidence. Combined with VSSDelete from Test 1, WipeScore reaches 2.

Test 3 Secure Free Space Overwrite via cipher /w
windows

Uses Windows built-in cipher.exe with the /w flag to overwrite free disk space on a specified path with three passes (zeros, 0xFF, random). While cipher /w is a legitimate data sanitization tool, it is also used by wiper malware to overwrite free space containing previously deleted sensitive files. This test targets a temp directory to limit scope.

Command

powershell 
cipher /w:%TEMP%

Cleanup

powershell 
REM No cleanup needed — cipher /w only overwrites free space, does not modify existing files.

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=cipher.exe, CommandLine='cipher /w:C:\Users\...\AppData\Local\Temp' (path will be expanded). Sysmon Event ID 11: multiple temporary file creation events (EFSTMPWP.tmp files) in the target directory as cipher creates temporary overwrite files. Process will run for several seconds to minutes depending on free space.

Expected Detection

KQL: CipherWipe=true, WipeScore >= 1. SPL: CipherWipe=1. The combination of cipher.exe process creation + temporary file creation events provides corroborating telemetry. In production, correlate with other wipe indicators for higher confidence.

Test 4 Diskpart Disk Clean via Script File (Simulated — Uses Virtual Disk)
windows

Creates a VHD (Virtual Hard Disk) using diskpart, then runs 'clean all' against it to simulate the disk wiping command used by destructive malware. Uses a virtual disk to prevent any impact on the physical drive. The 'clean all' command overwrites all sectors with zeros. Requires administrator privileges.

Command

powershell 
echo create vdisk file="%TEMP%\argus_test.vhd" maximum=50 type=fixed > %TEMP%\dp_create.txt && echo select vdisk file="%TEMP%\argus_test.vhd" >> %TEMP%\dp_create.txt && echo attach vdisk >> %TEMP%\dp_create.txt && diskpart /s %TEMP%\dp_create.txt && echo select vdisk file="%TEMP%\argus_test.vhd" > %TEMP%\dp_wipe.txt && echo clean all >> %TEMP%\dp_wipe.txt && diskpart /s %TEMP%\dp_wipe.txt

Cleanup

powershell 
echo select vdisk file="%TEMP%\argus_test.vhd" > %TEMP%\dp_cleanup.txt && echo detach vdisk >> %TEMP%\dp_cleanup.txt && diskpart /s %TEMP%\dp_cleanup.txt && del /f %TEMP%\dp_create.txt %TEMP%\dp_wipe.txt %TEMP%\dp_cleanup.txt %TEMP%\argus_test.vhd

Expected Telemetry

Sysmon Event ID 1: two Process Create events for diskpart.exe — first with /s dp_create.txt (VHD creation), second with /s dp_wipe.txt (clean all). Sysmon Event ID 11: file creation events for the .vhd and .txt script files in %TEMP%. The actual 'clean all' command is in the script file, not the command line, so analysts should correlate with file creation of the script files.

Expected Detection

KQL: DiskPartWipe detection fires if 'clean' appears in ProcessCommandLine — note: in this test it will be in the script file content, not the command line. The process creation itself (diskpart.exe from %TEMP% script files) is anomalous and will be flagged. Hunting Query 1 will catch this via the multi-stage pattern. SPL: same behavior — diskpart.exe from unusual parent (cmd.exe in interactive session) is suspicious.

Test 5 Linux Raw Disk Overwrite Simulation via dd (File Target — Safe)
linux

Simulates the dd-based disk wiping technique used by Linux wiper malware by writing /dev/zero to a file rather than a real block device. This generates the same process telemetry (dd with if=/dev/zero) that detection rules target, without any risk to the filesystem. On Linux systems, this is commonly used to test auditd or Falco rules for T1561.

Command

bash 
dd if=/dev/zero of=/tmp/argus_wipe_test.bin bs=4M count=10 status=progress

Cleanup

bash 
rm -f /tmp/argus_wipe_test.bin

Expected Telemetry

Linux auditd EXECVE record with comm=dd, a0=if=/dev/zero, a1=of=/tmp/argus_wipe_test.bin. Syslog process creation record. If Falco is deployed: process_started rule matching dd with if=/dev/zero pattern. The command generates 40MB written to disk — watch for I/O spike in monitoring. Note: real wiper uses of=/dev/sda or similar block device path.

Expected Detection

KQL (if Linux via Sysmon for Linux or Defender for Endpoint Linux): ProcessCommandLine contains 'if=/dev/zero'. SPL (syslog/auditd sourcetype): rex extracts the dd command arguments and matches if=/dev/zero pattern. Custom Falco rule: `evt.type=execve and proc.name=dd and proc.cmdline contains 'if=/dev/zero'` fires with critical priority.

Related Detections

Tactic Hub

TA0040Impact

Sub-techniques (2)

Related Techniques

T1561.001Disk Content WipeT1561.002Disk Structure WipeT1485Data DestructionT1490Inhibit System RecoveryT1070.001Clear Windows Event LogsT1003OS Credential DumpingT1021.002SMB/Windows Admin SharesT1569.002Service ExecutionT1078Valid AccountsT1059.001PowerShell

Same Tactic: Impact

Popular Detections