Monday morning, seven o’clock. The person responsible for IT arrives at the office because none of the systems have worked since five. The server screens show a text with a link and a deadline. The first thought is calm: we have backups, we will restore. They open the backup server and find the backup jobs deleted and the repository empty. The cloud storage the backups were uploaded to is empty as well. The last working copy is an external drive that someone took to a safe a year ago.
This scenario is not made up, and it repeats with small variations. Most often the company did have backups. They were simply reachable from the same network, with the same credentials that the attacker had already taken over.
In this article we show how such an attack really unfolds, why the backup server is one of its first targets, and how backups work when the attacker can neither see nor delete them.
An attack is not one file, it is weeks of work
Most people picture ransomware as an email with an attachment that someone opens, after which everything is encrypted. Ten years ago that was true. Today it is the last and shortest step of the attack. Several others come before it, and they are carried out by people, not by a program.
Initial access
The attacker gets into the network in one of several ways: a phishing email that tricks someone into giving up a password, a leaked password that an employee also used on personal sites, unpatched VPN or remote desktop equipment, or a supplier that has access to your systems. At this point nothing is encrypted yet, and nobody notices anything.
Reconnaissance
For days or weeks the attacker explores quietly. Which servers exist, where the domain controller is, where files are kept, which backup system is used and where it writes. The backup server is easy to recognise: by its name, by the software installed on it, and by the large stream of data that flows to it every night.
Taking over credentials
The goal is domain administrator rights. They are often easier to get than it seems: an administrator logged on to an employee’s computer to fix a problem and left a login token behind, or the same password works for both the backup server and the cloud storage. With administrator rights the attacker has everything your IT has.
Destroying the backups
Only now does the part begin that the company does not notice until Monday morning. Backup jobs and the backups themselves are deleted. A NAS mounted as a network drive is formatted or encrypted along with everything else. In cloud storage that the backup server reaches with its own account, objects are deleted, because the same account that can write can usually delete too. Sometimes the backups are left for a few more days so that the ransomware encrypts them as well, but the result is the same.
Encryption
The last step is launched when the backups are gone and the company is least prepared to react: Friday evening, the night before a holiday, the holiday season. Part of the data is often copied out beforehand so that the attacker can threaten to publish it if the ransom is not paid. The encryption itself takes hours, not days, so by the time it is noticed it is too late to stop.
Why a backup server on your network is a target
The attacker’s logic is simple: a company with working backups does not pay. So the backups are destroyed first. A backup server that is a domain member, visible on the network, managed with the same administrator credentials, and writing to storage it can also delete from is not a defence against the attack. It is part of the attack.
Typical gaps we see when performing IT security audits:
- The backup server is joined to the domain, so a domain administrator is automatically a backup administrator too.
- The backup repository is mounted as a shared folder reachable from employee computers.
- The cloud storage access key is kept on the backup server and allows deleting, not just writing.
- There is no immutability, so any backup can be deleted at any moment.
- A single person can destroy all backups alone, with no one else’s approval.
None of these gaps is a flaw in the backup software. They are an architecture problem: the backups were designed as if the only threat were a failed disk, not a person holding your administrator password. That is exactly why a backup report with a green check mark says nothing about resistance to ransomware.
How immutable backups that are invisible from the network work
Immutable backups answer each of these gaps. The principle rests on two properties.
Invisible from the network
The backup storage is not part of your network. It has no address that could be found during reconnaissance, it is not a domain member, and it does not accept connections from your servers. Data reaches it through a one-way channel: your side can only send, and cannot view, change or delete what has already been sent. An attacker who has taken over your entire network sees only that something is being sent somewhere.
Immutable for a set period
In the storage, every backup is locked for a defined period. During that time it cannot be deleted by your administrator, by your IT provider, or by us acting alone. The delete command is simply rejected at the storage level, not in an application whose settings could be changed. The period is chosen to be longer than the time in which a company would realistically notice a breach: in our practice at least 30 days, often more.
Who can start a restore
This is the key difference from ordinary backups. A restore from immutable backups is not started by the backup server or by a domain administrator, but by authorised representatives of your company who were named in advance, through a separate channel unrelated to your network. Their identity is verified in a way agreed beforehand. That way even a fully compromised network cannot be used to reach or destroy the backups. The details are described on the immutable backup service page.
The backups survived. Where do you run them?
The second problem of that Monday morning, which is thought of less often: the backups are intact, but the servers are encrypted and the network cannot be trusted, because nobody knows where else the attacker is. You cannot restore into the same network until it has been cleaned, and that takes days.
That is why we combine immutable backups with PlanB infrastructure recovery: the backups are kept in our cloud, and next to them sits a prepared, isolated environment where servers are started from the backups and the company keeps working while its own infrastructure is investigated and repaired. Recovery time is then measured in hours, not weeks, and does not depend on how quickly the infected network can be cleaned.
Where to start
- Check whether your backup server is a domain member and whether a domain administrator can delete the backups. If so, that is the first thing to change.
- Move at least one copy of your backups to storage that cannot be seen from your network and where the backups are locked for a set period.
- Name two people who can start a restore, and agree how their identity is verified without using company email or the company network.
- Decide where the servers would be started if your network cannot be trusted for several days.
- If you would like us to assess the state of your backups and access rights together with you, get in touch through the contact form. The first conversation usually starts with one question: who can delete your backups today?
