The Detection Gap: MITRE ATT&CK T1490

• This technique shows up right before the damage becomes irreversible, when deleting shadow copies removes one of the last recovery options available. 
• Backup admins also delete shadow copies routinely for legitimate storage-management reasons. The command is identical either way.
• By the time this technique runs, the window to stop an incident has narrowed dramatically, making catching the pattern matter more than catching the command itself.

The Detection Gap is a breakdown for security practitioners who have to make quick calls under tight time constraints. In each post, we walk through what one MITRE ATT&CK technique looks like when it's legitimate activity vs. when it's actually an attacker in your environment.

The command that means it's already too late

When you first look at this command, nothing looks wrong. Meanwhile it’s quietly deleting every volume shadow copy on a machine. There’s no encryption in sight, and no ransom note. But if you're watching for this specific command and you catch it, you're looking at one of the last clean opportunities to stop what's coming next before it becomes unrecoverable.

Inhibiting system recovery isn't the goal of a ransomware attack. It's the setup. Encryption is what actually damages a victim, but encryption alone is survivable if backups exist. What makes a ransomware attack actually work (what forces the conversation toward paying instead of restoring) is removing the recovery path first. That's why this technique shows up as a near-universal precursor across ransomware families, from WannaCry to Olympic Destroyer to a long list of more recent operators. Rarely optional for the attacker, it clears the way for everything that follows.

The tooling involved is entirely native to Windows, which is exactly the pattern this series keeps returning to. vssadmin.exe can wipe every shadow copy on a system directly. wmic shadowcopy delete does the same thing through Windows Management Instrumentation, the same infrastructure we covered previously. wbadmin.exe can delete the Windows Backup Catalog outright. And bcdedit.exe can subtly disable Windows' automatic recovery behavior by modifying boot configuration data, so even if something does trigger a recovery attempt, it won't run. None of these tools are actually malware. All of them ship standard, signed, and expected.

The legitimate case

Shadow copy and backup management happens as routine IT work, and it happens more often than most security teams think.

Here’s how to recognize normal: 

• Actor: A backup or storage admin, or an automated backup solution running as a scheduled task under a known service account.
• Scope: Typically resizing shadow storage allocation to manage disk space, or removing specific outdated snapshots as part of a defined retention policy, rather than a full wipe of every shadow copy on the box.
• Context: Tied to a documented backup or storage management schedule, it stays consistent across your fleet and traceable to a known change or maintenance process.
• Surrounding activity: Isolated; nothing else unusual precedes or follows it. 

The malicious case

Identical tooling, in many cases even the same commands, but a radically different shape around it.

It’ll look more like this:

• Actor: A process with no legitimate reason to be touching backup infrastructure, and often traces back to a compromised account or a process chain that started with a much earlier stage of the same intrusion.
• Scope: Total, vssadmin.exe delete shadows /all /quiet or wmic shadowcopy delete targets everything on the system, not a scoped cleanup. 
• Context: No ticket, no backup schedule, and no storage management history to explain it; it's frequently paired with bcdedit.exe disabling recovery options or wbadmin.exe wiping the backup catalog in the same general timeframe.
• Surrounding activity: Almost never an isolated event, it typically sits at the tail end of a much longer chain: initial access, credential theft, lateral movement, and this very technique showing up right before encryption starts. If you're seeing this command with no earlier chain behind it, either your earlier detection missed something, or you're looking at the very last warning you're going to get.

The command line itself often gives it away just as clearly as the surrounding chain. /all /quiet is a scope-and-intent combination a routine storage cleanup rarely needs. Legitimate administration tends to be targeted and visible. When malicious, this technique is built to remove recovery options completely and silently. 

Where the signals come together

Manually, catching this means watching for a fairly narrow set of native binaries, including vssadmin, wmic, wbadmin, bcdedit, diskshadow, and correlating their execution against whether there's any legitimate backup or maintenance activity that would explain it. On its own, that's a relatively fast check. What makes it hard is that a shadow copy deletion, seen in isolation, is genuinely ambiguous. The real signal isn't the command; it's everything that happened on that machine in the hours before it.

This is where Threat Tracer proves it’s worth its salt, even more so than it already has in past techniques. Because this action so rarely happens alone, analysts need to see the full chain that led to it. A shadow copy deletion that traces back through a suspicious LSASS access, or a WMI-spawned process with no business justification, tells an entirely different story than the same command running as an isolated event from a known backup service account. Threat Tracer surfaces that lineage so you can evaluate the sequence without reconstructing it from a single alert lacking context.

What to look for in Threat Tracer

Start by tracing backward from the shadow copy deletion itself. Not just at the command, but at what process ran it and what that process's own history looks like. A known backup service account with a clean, repeatable pattern reads nothing like a process chain that includes credential access or lateral movement earlier in the timeline. 

Then, check the scope and pairing. A full, unscoped deletion paired with bcdedit recovery changes or wbadmin catalog deletion within a short window pretty much never has an innocent explanation. Investigate immediately. Lastly, look backward in the timeline. If no earlier chain is visible, treat that gap itself as a red flag. It likely means the chain exists and simply predates what you're currently looking at.

A quick posture check

Before you close out, consider these questions about your own environment.

1. Do you know what your organization's legitimate shadow copy and backup management activity actually looks like, well enough to separate it instantly from a full, unscoped deletion?
2. If this command ran on an endpoint right now with no earlier alerts in your queue, would you treat it as the start of an investigation, or as evidence that an earlier stage may have gone undetected?
3. Are your backups themselves isolated from the credentials and systems an attacker would already have if they've made it this far, or could compromising the environment also give an attacker access to the recovery path?

Now, that third question may carry the biggest weight. Detecting this technique fast is valuable. Not needing to detect it at all (because your recovery infrastructure was never reachable from the compromised path in the first place) is better.

Next up, we'll look at another ATT&CK technique using the same approach: what's normal, what's not, and what can help you make that distinction faster.

To see how Symantec CBX and Threat Tracer helps analysts see the full attack chain in seconds, request a 1:1 demo.