Worked Example: Redesigning a Noisy wmic shadowcopy Rule

This lesson walks through a complete detection redesign: from an existing noisy rule to a precision-improved, higher-robustness alternative. We apply the precision/recall/robustness framework from Lesson 1, the robustness design principles from Lesson 2, the evasion awareness from Lesson 3, and the alert context requirements from Lesson 4.

🔍 Score the original rule before reading the redesign

Here is the rule we’ll redesign:

detection:
  selection:
    Image|endswith: '\wmic.exe'
    CommandLine|contains: 'shadowcopy'
  condition: selection

Before reading further, score it:

Precision: what legitimate tools would trigger this?
Recall: what attack variants would NOT trigger this?
Robustness: what’s the minimum attacker change to evade?
Alert context: what fields does an analyst need to triage this?

Attempt this before reading on. Getting stuck is the point.

Step 1: Understand the Technique

ATT&CK T1490 — Inhibit System Recovery

Volume Shadow Copies (VSS) are Windows’s built-in point-in-time backup mechanism. Ransomware deletes them to prevent file recovery without paying the ransom. The canonical commands:

# vssadmin variant:
vssadmin.exe delete shadows /all /quiet

# wmic variant:
wmic.exe shadowcopy delete

# PowerShell variant:
Get-WmiObject Win32_ShadowCopy | Remove-WmiObject

# Direct WMI API (no external binary):
$shadow = [wmiclass]"Win32_ShadowCopy"
$shadow.Delete()

All four accomplish the same goal. A rule that only covers one misses three.

Step 2: Score the Original Rule

detection:
  selection:
    Image|endswith: '\wmic.exe'
    CommandLine|contains: 'shadowcopy'
  condition: selection

Precision analysis:

What legitimate tools use wmic.exe ... shadowcopy?

Backup software querying VSS status: wmic shadowcopy list brief
IT monitoring tools checking snapshot counts
Help desk scripts verifying backup health: wmic shadowcopy get Status
Sysadmin one-liners for maintenance: wmic shadowcopy list

The word “shadowcopy” alone triggers on all VSS read operations, not just deletions. Precision: Low.

Recall analysis:

Misses:

vssadmin.exe delete shadows /all /quiet (different binary)
PowerShell Get-WmiObject Win32_ShadowCopy | Remove-WmiObject (PowerShell, not wmic)
Direct WMI COM API call in C# malware (no external binary at all)
wbadmin delete catalog (deletes Windows backup catalog — same technique, different mechanism)

Recall: Low (covers 1 of 4+ common attack variants)

Robustness analysis:

Evaded by: using any tool other than wmic.exe for the same operation. Robustness: L1 (tool-specific, same implementation, single binary)

Alert context:

CommandLine is present (the keyword that triggered). No parent process, no user context, no asset tier. Alert context: Poor.

Step 3: Define the Target State

Before redesigning, define what “good” looks like:

Dimension	Target
Precision	> 90% — fire only when actual deletion occurs
Recall	Cover all 4+ common T1490 attack variants
Robustness	L3 — fire on any VSS deletion regardless of tool
Alert context	Include: user, host tier, parent process, full CommandLine

Step 4: Redesign the Detection

Layer 1: Precise wmic detection (fix precision first)

The original rule fires on any VSS query. Add the delete keyword to require deletion:

detection:
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains:
      - 'shadowcopy delete'
      - 'delete shadows'    # catches alternate syntax
  condition: selection_wmic

Precision improvement: Now only fires on deletion commands, not VSS queries.

Layer 2: Add vssadmin coverage (fix recall)

  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'resize shadowstorage'   # setting to low/0 also prevents new snapshots

Layer 3: Add PowerShell WMI coverage (fix recall further)

  selection_ps:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains:
      - 'Win32_ShadowCopy'
      - 'Remove-WmiObject'
      - 'Win32_Volume'

Note: Script Block Logging (Event 4104) is a better source for PowerShell detection — the command line may be obfuscated.

Layer 4: L3 — Win32_ShadowCopy deletion via WMI (any tool)

Sysmon Event 20 (WMI Activity — Operation) fires when a WMI query or method is executed. We can detect the WMI method call regardless of what process invoked it:

logsource:
  product: windows
  category: wmi_event

detection:
  selection_wmi:
    EventType: 'Operation'
    OperationName|contains: 'Win32_ShadowCopy'

This fires for direct WMI API calls from C# malware, PowerShell, or wmic.exe — any WMI consumer.

Final Combined Rule

title: Inhibit System Recovery — Shadow Copy Deletion (T1490)
id: 7f5d3c4a-1e2b-4f8a-9d6c-5a3b7e8f2d1c
status: test
description: >
  Detects deletion of Volume Shadow Copies via multiple mechanisms. VSS deletion
  is a common ransomware pre-encryption step. Covers wmic, vssadmin, PowerShell,
  and direct WMI invocation.
references:
  - https://attack.mitre.org/techniques/T1490/
author: TDL Detection Team
date: 2026/05/20
tags:
  - attack.impact
  - attack.t1490
  - attack.defense_evasion
  - attack.t1047
logsource:
  product: windows
  category: process_creation
detection:
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains:
      - 'shadowcopy delete'
      - 'delete shadows'

  selection_vssadmin:
    Image|endswith: '\vssadmin.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'resize shadowstorage'

  selection_ps:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
    CommandLine|contains|all:
      - 'Win32_ShadowCopy'
      - 'Delete'

  selection_wbadmin:
    Image|endswith: '\wbadmin.exe'
    CommandLine|contains: 'delete catalog'

  condition: 1 of selection_*

falsepositives:
  - Legitimate backup software deletion of old snapshots (rare — filter by parent process)
  - IT disaster recovery testing (coordinate with infra team on test windows)

level: high

fields:
  - Image
  - CommandLine
  - ParentImage
  - ParentCommandLine
  - User
  - ComputerName

Step 5: Score the Redesigned Rule

Dimension	Original	Redesigned	Delta
Precision	Low	High	Improved — `delete` keyword required, no VSS read-only matches
Recall	Low (1 variant)	Medium-High (4 variants)	Improved — covers wmic/vssadmin/PowerShell/wbadmin
Robustness	L1	L2-L3	Improved — multiple tools covered; WMI layer in separate rule
Alert context	Poor	Good	`fields` section covers all triage-relevant data

Remaining gaps (blind spots):

Custom C# malware calling WMI COM API directly (no process creation event)
Attacker using a signed third-party backup binary to delete shadows
bcdedit /set {default} recoveryenabled No (disables Recovery mode — same technique, different mechanism)

Document these in the ADS blind spots section and create separate rules for each.

Step 6: Deploy and Baseline

Before pushing to production:

Run the rule against 30 days of historical logs — count fires per day
Sample 20 alerts — classify as TP or FP
Calculate precision: TP / (TP + FP)
If precision < 80%, identify the FP sources and add targeted exclusions
Run the true-positive test: wmic shadowcopy delete in a test VM, verify alert fires
Run false-positive test: wmic shadowcopy list brief in a test VM, verify no alert

T1490: Inhibit System Recovery— MITRE ATT&CK SigmaHQ: VSSAdmin Delete Shadows— SigmaHQ GitHub

Retrieval Practice

After deploying the redesigned rule, you see 3 alerts per week from a backup agent that runs `wmic shadowcopy delete` to clean up old snapshots before creating new ones. The ParentImage is `C:\Program Files\BackupAgent\agent.exe`. How do you add a targeted exclusion without creating a blind spot?

Reveal answer

Add a filter block using FULL PATH for both the backup agent and the expected command pattern: `filter_backup: ParentImage: 'C:\\Program Files\\BackupAgent\\agent.exe'` and extend the condition: `... and not filter_backup`. CRITICAL: use the full path, not just 'agent.exe' — an attacker could name their process agent.exe. Optionally: also filter on the specific CommandLine pattern that the backup agent uses (e.g., `'shadowcopy delete /Oldest'`) so the filter doesn't suppress any wmic shadowcopy delete command, only the agent's specific one. Document in the ADS: 'BackupAgent v3.x creates then deletes shadows during backup cycle — filtered by full ParentImage path. Verify this exclusion quarterly when BackupAgent is updated.'

Retrieval Practice

The rule fires on a host running Veeam Backup. Investigation shows Veeam deletes old VSS snapshots as part of its backup rotation. You add ParentImage|contains: 'Veeam' as an exclusion. What is wrong with this exclusion?

Reveal answer

Two problems: (1) `contains: 'Veeam'` matches any process with 'Veeam' anywhere in its path — an attacker could name their malware C:\\Users\\Public\\Veeam\\evil.exe and evade the filter. Use `ParentImage|startswith: 'C:\\Program Files\\Veeam\\'` or the full path to a specific Veeam binary. (2) The exclusion doesn't verify that the Veeam process is actually Veeam. Use OriginalFileName from the PE header, or require the Veeam service account (a specific service account user) in the User field. Defense-in-depth: path filter + expected user account is much harder to spoof than a path filter alone.