Ransomware Defence: Before, During and After

How a modern ransomware attack actually unfolds, which controls genuinely stop it, and what to do in the first hours once it has happened.

Ransomware today is not a random infection but a business model. Attackers select victims deliberately, spend weeks inside the network before encrypting anything, and exfiltrate data first so that having backups does not save the victim from paying. This article is about where that chain can be broken.

How it actually unfolds

Encryption is the last step of the attack, not the first. What happens before it typically takes weeks, and that is the window in which it can be stopped.

Phase What happens Typical duration
Entry Phishing, stolen VPN credential, exposed RDP, vulnerable edge device minutes
Foothold Establishing remote access, scheduled task, use of legitimate tooling hours
Discovery Mapping network, domain, backups, valuable data 1 to 7 days
Privilege escalation Obtaining domain administrator 1 to 3 days
Backup destruction Reaching the backup server, deleting snapshots hours
Data theft Exfiltrating hundreds of gigabytes 1 to 5 days
Encryption All at once, typically at a weekend or holiday dawn 1 to 4 hours

The lesson: an organisation typically has one to two weeks to notice something. The attack is not a lightning strike but slow infiltration that most victims simply do not see.

The four controls that genuinely stop it

Many things can be done, but analysis of real incidents shows four controls form the backbone of defence.

1. MFA on everything reachable from outside

The overwhelming majority of entries come through stolen credentials. VPN, remote desktop, webmail, cloud services: if any of these is single-factor, that is the front door.

Eliminating exceptions matters. A single service account or legacy protocol without MFA is enough to bypass the whole thing. A phishing-resistant method (FIDO2 hardware key) is strongest, but number-matched push is still orders of magnitude better than nothing.

2. Isolated, tested backups

This is the difference between a few days and several months of recovery. Three requirements:

  • Backups must not be reachable with the same credentials as production. If the backup server is a domain member and the attacker is domain admin, you have no backup.
  • Keep an immutable or offline copy. Object lock or tape remains relevant today.
  • Test restoration regularly. The existence of a backup is not evidence. A real restore drill each quarter is the only proof.

3. Segmentation

Encryption hurts so much because on a flat network it reaches everything at once. If critical systems sit in separate segments with strict ingress, the damage is a fraction.

Minimum: domain controllers, backup infrastructure and financial systems in their own segments. Add client isolation so one workstation cannot reach another's administrative ports.

4. Detection during the discovery phase

While reconnoitring, the attacker does things nobody does in normal operation: bulk domain queries, sweeping network shares, privilege escalation attempts, running suspicious tooling.

These are detectable if log collection exists and somebody watches the alerts. An EDR that is not enabled, or that nobody monitors, is worth exactly nothing.

The most commonly missing link is not technology but attention. Many victims discover afterwards that the alert did fire, but nobody looked at it, or there was no procedure for what to do with it at night or at a weekend.

What to do in the first hours

Once it has happened, sequence matters.

Do not power off machines. Traces in memory are lost, and in some cases the encryption key is there too. Do disconnect them from the network.

Isolate the network, but not hastily. In industrial environments disconnecting a segment can halt the process, so the decision must be made jointly with operations.

Do not overwrite anything. Logs, memory images and disk images are the basis of the investigation. The "let us just rebuild quickly" reflex is the most common mistake, because afterwards nobody can say how they got in, so the attacker will return.

Report. Under NIS2 the early warning deadline is 24 hours. If personal data is affected, the GDPR 72-hour notification obligation applies too.

Do not pay prematurely. Payment does not guarantee restoration, does not guarantee deletion of stolen data, and in several cases makes the organisation a repeat target. The decision should only be taken after assessing recovery capability.

We covered this in detail in our article on the first 24 hours of an incident.

What to do afterwards

Recovery does not end with restoring systems.

  • Root cause analysis. If the entry point is not identified, the restored system remains equally vulnerable.
  • Full credential rotation. Every password, service account, API key and certificate, including domain keys.
  • Handling the stolen data. Notification obligations, informing data subjects, legal consequences.
  • Closing the missing controls. The incident showed what was absent. This is the rare moment when the organisation is willing to invest.

A realistic expectation

No control offers one hundred percent protection. The goal is not to make attack impossible but to make it detectable before encryption, and to ensure the organisation can recover without paying.

Both capabilities are measurable. The first by a penetration test and alert handling exercises, the second by a real restore drill. Doing these two once a year puts you ahead of most organisations.

We covered backup strategy and network segmentation in separate articles.

Back to Insights
Related content

Related content

Questions on this topic?

Our specialists are happy to discuss what this means in your organisation's environment.