Ransomware: what really happens, and what would have stopped it

Ransomware is not a lightning strike. It is a chain of steps, and a chain breaks at any of its links. Understanding the sequence shows where to intervene — and, incidentally, reveals that the effective measures are few and within any organisation's reach.

This article describes a mechanism. It gives no actionable method, tells no client story, and does not end on “call us”: it should be useful to you without us.

Link 1 — entry

Three doors, and they are almost always the same.

An attachment or a link. A credible message, often a reply within a real conversation, with a document to open. The person who clicks is neither careless nor negligent: the message was plausible, and opening it was their job.

A reused password. An outside service suffers a leak; the address-and-password pair ends up in a list. If the same combination opens your mail or your remote access, entry requires no particular skill.

An exposed, unpatched service. Remote access, a file server, a management tool reachable from the internet, whose flaw has been public and fixed for months. The scanning is automatic and permanent.

Link 2 — silent spread

This is the stage nobody pictures, and it is the longest: several days, sometimes weeks. Nothing visible happens. Machines run normally, nobody reports slowness.

Meanwhile the access obtained is used to look around: which servers exist, where the data that matters sits, which accounts hold broad rights, and — the decisive point — where the backups are and how they are connected.

This phase explains why conventional detection often misses it: there is no attack under way, only an open session doing ordinary things with legitimate credentials.

Link 3 — privilege escalation

An ordinary account is enough to get in, not to encrypt everything. The next step is therefore to obtain an administrative account, often by recovering credentials left in memory on a machine, or by using a service account whose password has not changed in years.

This is the link that justifies a simple and often neglected rule: nobody works day to day with an administrative account. The broad-rights account is used for operations that require it, and nothing else.

Link 4 — encryption

It fires all at once, usually at night or on a Friday evening, and it targets first whatever would block a return to normal: file servers, databases, and reachable backups.

That last point is what turns an incident into a shutdown. An organisation whose backups are encrypted alongside production has not suffered an outage: it has lost its means of recovery.

Link 5 — the demand

It arrives with a countdown and, increasingly, with a second threat: the data was copied before being encrypted, and will be published unless payment is made. This is known as double extortion, and it changes the nature of the problem — restoring your servers makes nothing disappear.

Should you pay?

The honest answer rests on three observations, with no moral posturing.

• Payment does not buy a guarantee. It buys the hope of a decryption key, which sometimes turns out to be slow, incomplete, or ineffective on certain files.
• It does not make copied data disappear. Nothing allows you to verify a promise of deletion.
• It does not protect against a second demand. An organisation that has paid is an organisation known to pay.

The decision belongs to the leadership, often under pressure and within hours. Which is exactly why it should have been discussed calmly, beforehand.

The three measures that break the chain

They require neither a large budget nor a dedicated team. Each breaks a different link, and their combination is what protects.

1. A tested offline backup

It breaks link 4. A copy no machine on the network can alter — a medium unplugged between backups, or write-once remote storage — stays standing when the rest falls. And it only counts if it has been restored at least once: the procedure is in our article on testing backups.

2. Two-factor authentication

It breaks link 1. A stolen or reused password is no longer enough to get in. Enable it first on email, remote access and administrative accounts — in that order, since email is the recovery door for everything else.

3. Patching

It also breaks link 1, through the other door. What matters is not speed but completeness: you first need a list of what is exposed to the internet. You cannot patch what you do not know exists, and the omissions almost always sit in a tool installed years ago for a one-off need.

None of these three is sufficient alone. Together they impose three independent obstacles — already a lot for an automated operation looking for the easiest way through.

The day-one plan

One page is enough, but it must exist, and it must be printed: it will be unreachable if it lives on the encrypted network.

1. Who decides. A named person, and a deputy. Without that, the first hours go on finding who has authority to shut systems down.
2. Who unplugs what. Isolating does not mean powering off: a machine switched off loses traces useful for analysis. Disconnect the network, yes; cut the power only on instruction.
3. Who notifies whom. Leadership, the IT vendor, the insurer, and — if personal data is involved — the competent authority, within the deadline set by the applicable regulation.
4. What must keep running. Which activities have to work even without systems, and how. That is the part nobody writes and the one that serves best.

What to take away

The scenario is mechanical and well known; nothing about it is unstoppable. A tested offline backup, two-factor authentication on sensitive access, and an up-to-date inventory of what is exposed remove most of the risk, at a cost bearing no comparison with that of a shutdown.

Our Cybersecurity and DevOps & Cloud pages cover protection and infrastructure. But the three measures above can be put in place without us, and that is where to start.