Inhibit System Recovery

Before or during a destructive attack, an adversary often deliberately disables the victim's own ability to recover, deleting backup copies, disabling system restore points, and removing the built-in recovery mechanisms an operating system normally provides. The goal is simple: make sure that even if the primary attack (like ransomware) doesn't work perfectly, the victim still can't just roll back and undo the damage.

This is almost always paired with another, more visible impact technique, most commonly ransomware, since destroying recovery options only matters if there's something to recover from in the first place.

Windows keeps automatic backup snapshots called Volume Shadow Copies specifically so a system can be restored after something goes wrong, exactly the kind of safety net an attacker wants gone before they do real damage. The built-in tool for managing these, vssadmin, can also delete them entirely with a single command, and attackers use it, or equivalent tools like wmic or diskshadow, to strip out every shadow copy before or during an encryption event.

This step often happens in the same short window as the destructive act itself, sometimes seconds apart, since there's little reason for an attacker to inhibit recovery long before actually causing the damage that recovery would have undone.

Data source: endpoint process-creation telemetry (Sysmon Event ID 1) whose command line carries the delete arguments, and the shadow-copy service's own start milliseconds later

{
  "host": {
    "name": "FILE01"
  },
  "event": {
    "code": "1",
    "action": "start"
  },
  "process": {
    "name": "vssadmin.exe",
    "command_line": "vssadmin.exe delete shadows /all /quiet"
  }
}

Prebuilt Elastic rule: Volume Shadow Copy Deleted or Resized via VssAdmin

Filter process-creation events for vssadmin.exe (or its WMIC/PowerShell/diskshadow equivalents) with command-line arguments referencing shadow copy deletion. Given how tightly this technique is usually paired with a destructive follow-on, the real value of finding it is as an early-warning signal: check what else that same host, or the same user, did in the minutes immediately before and after, since a shadow-copy deletion with nothing else around it is unusual, and a shadow-copy deletion followed by mass file changes is close to a confirmed case.

Legitimate system administration does sometimes involve managing shadow copies deliberately, freeing up disk space, adjusting retention policy, or troubleshooting backup software, so the command alone isn't automatically malicious.

The distinguishing signal is context: a scheduled, expected administrative task run by IT staff during a normal maintenance window reads very differently from an unscheduled deletion run by an unexpected account, especially one that's part of a broader sequence of suspicious activity on the same host around the same time.

• MITRE ATT&CK T1490: Inhibit System Recovery
• Elastic Security: Volume Shadow Copy Deleted or Resized via VssAdmin

1 scenario in this catalog covers T1490. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →