Modern ransomware no longer encrypts your server the moment it gets in. First it does something far smarter: it hunts your backups. It knows that if it leaves your history intact, you will restore and not pay. So the right question is not whether you have backups, but whether your own server can touch them.
How a real attack works
The pattern repeats. The attacker gets in through a stolen credential, an unpatched vulnerability or an email attachment. Then, instead of encrypting immediately, it stays quiet for weeks exploring the network: which servers exist, where the important data lives, and above all where the backups are and what credentials reach them.
When it decides to act, the order is always the same: first destroy or encrypt the backup history, then encrypt production data, and only then show you the ransom note. By the time you find out, you have nowhere to go back to.
The design flaw almost everyone has
Here is the point that changes everything. In most installations, the production server holds credentials to write to the backup store, because it is the one pushing the backups. It sounds reasonable, and it is exactly the door.
If the server can write, delete or overwrite at the destination, any attacker who controls that server inherits that capability. They need to discover nothing else: they already have the key, sitting in a configuration file.
The patches that are not enough
Encrypting the backups does not solve this: an attacker does not need to read them, deleting them is enough. A second disk does not help either if it is mounted on the same system. And cloud backups with write credentials stored on the server are just as vulnerable as a local disk.
The model that works: reverse the direction
The defence is conceptually simple: let the backup server come and fetch the data, instead of the production server pushing it.
With that change, the credentials that exist are read-only against your source, and they live on the backup system, not on the exposed server. An attacker who controls your production can wreck the source, but has no route to the history: no credentials, and the firewall prevents any connection being opened in that direction.
The worst that can happen then is losing your live data, which is exactly the scenario backups exist for.
The signals that expose an attack before the ransom
A good backup system is also an early detector, because it sees things administrators do not check daily:
- The most recent backup ages. If the last one is older than 36 hours, something stopped working and nobody noticed.
- Zero new blocks arrive for several days. Data encrypted by an attacker changes completely, so this symptom usually means the backup stopped running, not that nothing changed.
- Used space drops without a scheduled prune. Someone is deleting history.
The last two are classic signatures of an attack in progress, and an attentive provider can warn you before the ransom note appears.
What to review at your place this week
Open your backup configuration and answer honestly: does your production server hold credentials to modify the backup destination? Could a process with admin rights on that server delete the history? Is anyone monitoring that backups keep arriving? When did you last restore something?
If any answer makes you uncomfortable, you know where to start.
Our design
In our backup services we always open the connection, with read-only credentials against your source, and the firewall explicitly denies any connection in the opposite direction. Silent-failure detection is included and watches the three signals above. All inside two data centres of our own in Andorra.