It is 2am and a file server that has been idle for hours starts writing hard — .docx to .docx.locked, one file after another, as fast as the disk will go. Somewhere in that list is the folder your backup job finished writing to earlier that night.
Nothing in that sequence was aimed at your backup. It was simply reachable.
That distinction matters, because it is the whole reason "we have backups" so often turns out to be true and useless on the same morning. In the incident write-ups I've read over the years, the backup is almost never destroyed in a separate, dramatic second act. It goes down in the first pass, as ordinary traffic, and nobody notices until someone tries to restore.
It follows paths that are already open, not files that are important
Ransomware doesn't know your file names. It enumerates what the machine can see: local volumes, mapped drives, network shares with a stored credential, cloud sync folders running as the logged-in user. Then it encrypts in bulk. Priority is not "the crown jewels", it's "whatever this account can write to, fastest first".
That is why a backup drive is such an easy target. It isn't attacked as a backup. It's attacked as a folder.
A mapped drive is not a separate system
A drive letter is a convenience for humans. To the operating system, Z: is a path like any other, resolved through the same API, subject to the same permissions. If your backup software writes to it, so can anything else running as you — including something that arrived twenty minutes ago in an email attachment.
The same goes for the NAS in the corner. If the machine holds a saved credential for it, the share is not remote in any sense that matters. It's a folder, reached slightly slower.
The first casualty is whatever would have undone the damage
Before the encryption starts, a lot of these runs do the cleanup, because it's cheap and it's well documented:
- delete the volume shadow copies that would let you roll back
- wipe restore points
- disable or delete the local backup catalogue
- clear the recycle bin
- in some cases, spend time hunting for backup agents and their repositories
This is the part I'd underline. It isn't collateral damage. Recovery tooling is a target, and it's attacked first, while the encryption is still running.
The credentials travel with the malware
If your nightly job runs as a service account with write access to the repository, then any process running with enough privilege can borrow that access. Backup repositories that require a password are not protected by the password if the password is sitting in a config file on the same box, in plaintext or trivially reversible form.
This is why "the repository is on another machine" answers the wrong question. The right question is: from this compromised host, with these credentials, what can I still write to and delete?
What survived in the write-ups was never online
Strip out the vendor names and the surviving copies tend to fall into three shapes:
- Physically disconnected. Tape on a shelf, a USB drive in a drawer, a drive that only exists during the backup window. No mount, no credentials, no API.
- Immutable. Object storage with versioning and a retention lock, or an append-only repository where deletion requires a separate authority the compromised account doesn't have.
- Off the domain and off the network. A copy that never authenticated with the same directory, so the stolen credentials are worthless against it.
Everything else — the second NAS, the mirrored drive, the sync folder, the replica in the same rack — shares fate with the original more often than people expect, because it shares the same reachability.
The decision is made before the incident, not during it
You cannot add an air gap at 2am. By the time you're reading the ransom note, the shape of your recovery is already fixed: it's whatever your setup did automatically, at 1am, without anyone thinking about it.
So the useful question isn't "do we have backups". It's: if this host were fully compromised right now — every credential on it, every mounted share — what would still be intact tomorrow?
If the answer is "the copy that was unplugged", that's a backup. If the answer is "nothing", you don't need more storage. You need distance.
Three things worth doing this week:
- Run the backup, then make the destination unreachable — physically or by policy — before you walk away.
- Turn on versioning or object lock on at least one copy, so a delete doesn't propagate.
- Check what the backup account can actually do. If it can delete, it can be used to delete.
— Mario
I write about backups, self-hosting and keeping systems alive. I also build RansomShield (getransomshield.com), the air-gapped backup tool described above.
