If you’re using Windows shadow copies as your backup strategy, I need you to stop what you’re doing and read this. Not because I’m trying to scare you — okay, maybe a little — but because ransomware deletes shadow copies for breakfast, and if that’s your recovery plan, you don’t actually have one.
This blog post summarizes the main points of my latest podcast episode. If you’d like, you can listen to it or watch it at https://www.backupwrapup.com/stop-using-vss-backup-ransomware-deletes-shadow-copies.
What Shadow Copies Actually Are (And What They’re Not)
VSS — the Volume Shadow Copy Service — is a Windows feature that’s been around since Windows Server 2003. It was built to solve a real problem: how do you get a consistent, stable snapshot of a system that’s actively running? When you’ve got SQL Server or Exchange humming along and you need to back it up, you can’t just freeze time. VSS lets backup applications quiesce the app, grab a stable image, and then let everything keep running. It’s a framework. It’s a tool. And it’s genuinely great at what it was designed to do.
What it was NOT designed to do is be your backup system.
But here’s what happens in the real world. Someone sets up Windows. They notice that shadow copies exist, that they can create multiple versions over time, that they can go back and recover files. It feels like a backup. It looks like a backup. So they call it a backup. And then ransomware deletes shadow copies and the whole illusion collapses.
Why Ransomware Deletes Shadow Copies — And Why It’s So Easy
This is where it gets really fun. Or really depressing. Both.
Ransomware doesn’t need any special tools to delete your shadow copies. It uses vssadmin — a perfectly legitimate Windows command-line utility that ships with every version of Windows — to run something like vssadmin delete shadows /all /quiet and wipe every single snapshot you have. This is what we call a living off the land attack. The attacker uses your own tools against you. No custom malware required. Just admin rights and one command.
And here’s the kicker: before ransomware deletes shadow copies, attackers read them. They use vssadmin and WMIC to do reconnaissance. They look at what’s in your shadow copies — QuickBooks data, company files, project names — to figure out if you’re a valuable target. So your shadow copies aren’t just a failed backup. They’re a gift to the attacker.
This is the ultimate sweep-the-leg move. You built your whole recovery strategy on something that’s sitting on the same machine as your data, on the same media, reachable by anyone with local admin rights. And there are a lot of people with local admin rights. Dr. Mike Saylor, our resident cybersecurity expert, will tell you that the local admin problem is everywhere — people get it because they complained about not being able to change their wallpaper, or because they’re an engineer whose tools “require it.” Either way, once someone has local admin, all bets are off.
Why Shadow Copies Are Not a Backup (The 3-2-1 Rule)
I’ve been talking about the 3-2-1 rule for as long as I’ve been doing this — which is over 30 years. Three copies of your data. Two different media types. One copy offsite. Shadow copies fail every single part of this test.
They’re not a separate copy — they’re on the same volume as your production data. They’re not on different media — same disk, same storage. And they are absolutely, positively not offsite. When ransomware deletes shadow copies, it deletes all of them at once because they’re all in the same place. There’s nowhere for them to hide.
On top of that, if you’ve been accumulating shadow copies for 30 days, your system performance is probably in the crapper. VSS uses a copy-on-write snapshot architecture, which means every write to the original data also has to write to the snapshot area. The more copies you have, the worse it gets. So you’re not just doing a bad backup — you’re slowing down your system to do a bad backup.
How to Actually Protect Yourself
Stop using VSS snapshots as your backup. That’s step one. Just stop. If you’re not holding onto shadow copies as a long-term backup mechanism, there are no shadow copies for the attacker to delete. The threat surface shrinks dramatically.
Step two: get a real backup. One that follows the 3-2-1 rule. One that gets your data off the machine, off the network, and ideally to a copy that’s immutable — write once, read many — so that even if an attacker gets admin rights on everything, they can’t touch the backup.
Step three: configure your EDR tools to watch for anomalous VSS activity. Mike walked us through this on the episode. The key word is “anomalous.” vssadmin runs legitimately all the time as part of backup schedules. Your EDR needs to know what’s normal for your environment — when it runs, how often, from what account — so that when ransomware deletes shadow copies outside that window, you get an alert immediately.
This is not a plug-it-in-and-walk-away solution. It takes time to baseline your environment, to teach the tools what normal looks like. But once you’ve done it, you have a real detection capability. And detecting ransomware deleting shadow copies before the encryption starts? That’s your Hail Mary.
VSS is a great tool. I have zero problem with it when it’s doing what it was built for — giving backup applications a stable, consistent image to work from. The problem is when people stop there and call it done. That’s not a backup strategy. That’s a hope strategy. And hope is not a backup plan.
Written by W. Curtis Preston (@wcpreston), four-time O'Reilly author, and host of The Backup Wrap-up podcast. I am now the Technology Evangelist at S2|DATA, which helps companies manage their legacy data
