Guide · Security
Ransomware: backups that survive an attack
In short: modern attackers look for and destroy the backups first, before they encrypt. Only a backup that cannot be deleted from the company network – locked on a separate backup server, off-site or offline – and whose restore has been rehearsed beforehand will survive the attack.
How an attack on the backups unfolds
- Getting in: via a phishing email, a vulnerability or stolen credentials.
- Spreading: the attackers collect administrator rights, often unnoticed for weeks.
- Finding the backups: backup servers, NAS shares, shadow copies and cloud accounts are searched for.
- Destroying the backups: deleted or encrypted along with everything else, using the stolen rights.
- Encrypting and extorting: only now does the attack become visible – usually at night or at the weekend.
It follows that any backup an administrator of the company network can delete can also be deleted by an attacker with those rights.
Five measures that really help
| Measure | What it achieves |
|---|---|
| Immutable copy | Backups are locked against changes and deletion until a set date – even for the computers being backed up and their credentials |
| Separate backup server | Its own credentials, not a member of the Windows domain, only the necessary ports open |
| Off-site copy | A second copy at another location, with different credentials |
| Offline copy | A regular export to USB disk or tape, then kept disconnected from the network |
| Rehearsed restore | Regular check restores show that the backups are clean and complete |
Protecting the backup server itself
A retention lock is only as strong as the server that enforces it. For the backup server this means: a separate operating system account for administration, no domain membership, no logins with the same passwords as in the rest of the network, timely updates, access only via the necessary interfaces. Anyone who also keeps an offline copy has a reserve even for the worst case.
After the attack: restoring cleanly
- Choose the right version: attackers are often in the network weeks before the encryption. Many retained versions make it possible to go back to a point in time before the intrusion.
- Check first, then restore: start restored systems in isolation first and examine them, so that the malware does not come back with them.
- Know the order: first the directory service and network, then the business applications – practised, not improvised.
How AegisGrid protects against ransomware
AegisGrid encrypts the data on the system being backed up and writes it to up to eight destinations in one run. On WORM storage of the backup server, every backup is locked against changes and deletion until its lock expires: the backup server enforces the lock against all computers being backed up and all interfaces, and their access keys apply only to their own directories. On the server itself, data processing runs under a separate, unprivileged account. For the offline copy, AegisGrid exports individual backups as an archive to USB disk or tape. Check restores start restored VMs in an isolated environment without any outside connection and read every file in the backup: if seemingly encrypted files or ransom notes pile up, the backup server reports this while clean versions are still available. Every deletion is recorded in the signed evidence log.
Frequently asked questions about backup and ransomware
Are shadow copies and a NAS enough against ransomware?
Usually not. Ransomware with administrator rights deletes shadow copies in seconds, and a NAS share that can be written to from the network is encrypted as well. What is needed is at least one copy that cannot be deleted with the rights available in the company network.
How long should the lock last?
Longer than an attack can remain unnoticed – in practice at least 14 to 30 days for the daily backup, plus older monthly versions with a longer lock. What matters is that several older versions are kept.
Does AegisGrid notice if ransomware is already in the backup?
The backup server's check restore reads every file of the restored backup and looks for signs of encryption: content that does not match its file extension or looks like random data, typical extensions of ransomware and ransom notes. If there are clearly more than at the last check, an alert is raised – so an attack is noticed before the last clean backup expires. For file backups, the agent itself checks every run: if unusually many files change or many typical extensions appear, the run is marked, a message goes out and the older versions are not cleaned up for a set period. If desired, the check restore also scans the backups for viruses with ClamAV and names the last backup without the finding. This does not replace antivirus protection on the systems.
Does encrypting the backup help against ransomware?
It protects confidentiality: stolen backups give nothing away. It does not protect against deletion or renewed encryption – that requires the immutable and the offline copy.
Would your backup withstand an attack?
We check with you whether your backups would survive an attack.