Ransomware: how to actually defend, not just pay

In the popular imagination, a ransomware attack is the sudden appearance of a ransom note. In reality, encrypting data is the final stage of an operation that usually ran for anywhere from a few days to a few weeks. That’s good news: every stage of this chain is a chance to detect and stop the attack before the worst happens.

Anatomy of a typical attack

Most of the incidents we analyse follow a similar pattern:

1. Entry. Most often through a compromised account (phishing, a password without MFA) or an unpatched service exposed to the internet — VPN, RDP, an application server.
2. Persistence. The attacker establishes mechanisms to return to the network even after a reboot or a password change.
3. Privilege escalation. The goal is a domain administrator account. Active Directory flaws and excessive privileges play a key role here.
4. Reconnaissance and lateral movement. Mapping the network, hunting for backups and critical servers.
5. Data exfiltration. Increasingly, data is stolen first and encrypted afterwards — the double-extortion model.
6. Encryption. Often launched at the weekend or at night, when the response is slowest.

Where to break the chain

Defending against ransomware is not a single tool, but making each of the steps above harder for the attacker.

Limit entry. Enforce multi-factor authentication (MFA) on all remote-access accounts and on email. This single change eliminates most attacks based on stolen passwords. Services like RDP should never be directly exposed to the internet.

Make escalation harder. Regular review of Active Directory for excessive privileges, unused accounts and attack paths (tools like BloodHound) cuts off the attacker’s route to a domain admin account.

Slow lateral movement. Network segmentation means that compromising one workstation does not grant access to the whole infrastructure. Service accounts should have minimal, tightly scoped privileges.

Backups — the last line of defence

Attackers know that backups are their biggest enemy, so they target them first. A backup permanently connected to the network and accessible from an admin account will be encrypted along with everything else.

The 3-2-1 rule works: three copies of the data, on two different media, one in a separated location (offline or immutable). Equally important is regularly testing restores. A backup you have never tried to restore is just an assumption, not a safeguard.

Detection, not only prevention

Since the attack runs for days, there is time to detect it. It’s worth monitoring early-warning signals: unusual administrative logins, mass file operations, the launch of credential-dumping tools or a sudden rise in outbound traffic (a sign of exfiltration). An EDR system and centralised logging give a real advantage here.

Ransomware as a service — who you are really up against

Modern ransomware groups are not lone hackers. It’s a mature RaaS (Ransomware-as-a-Service) ecosystem: malware authors rent their tooling to “affiliates” who run the attacks and share the ransom. Separate initial access brokers sell compromised VPN and RDP accounts on forums — often for a few hundred dollars. That means getting into your network and the encryption itself are usually the work of two different groups, and weeks can pass between the sale of access and the attack.

There is a practical takeaway for defenders: a single leaked password is not a closed incident. If an employee’s VPN account showed up in a breach, you have to assume the access may already have been resold — a password reset without MFA and a log review is not enough.

The extortion model has evolved too. Double extortion (encryption plus the threat of publishing data) is now standard, and some groups practise triple extortion: additionally contacting the victim’s customers and partners, or reporting the breach to regulators. That is exactly why backups alone, though necessary, are not sufficient — they don’t protect against publication of stolen data.

A response plan: what to do while the attack is happening

Even the best prevention can fail, so every organisation should have a rehearsed scenario. The order of actions matters:

1. Isolate, don’t power off. Cut infected machines off from the network (physically or via VLAN), but don’t shut them down — RAM may hold encryption keys and forensic traces.
2. Cut remote access. Block VPN, service accounts and administrative access until you know which accounts are compromised.
3. Secure the backups. Immediately isolate the backup infrastructure — if the attack is still running, backups are target number one.
4. Start crisis communication. Appoint one person to liaise with the board, lawyers and possibly the media. Communicate over a channel independent of company email — it may be compromised.
5. Report the incident. Your national CERT, and where personal data is involved — the data protection authority within 72 hours. Entities covered by NIS2 have additional reporting duties (an early warning within 24 hours).
6. Don’t negotiate on your own. If any communication with the attackers is considered, run it through a specialised firm and lawyers — also because of international sanctions.

Legal requirements: GDPR and NIS2

A ransomware attack is almost always a legal incident too. If personal data was encrypted or stolen, GDPR requires notifying the supervisory authority within 72 hours of establishing the breach, and — where the risk is high — notifying the affected individuals as well. Important and essential entities under NIS2 must submit an early warning within 24 hours and an initial report within 72 hours. Without a working response plan, those deadlines pass before the organisation even knows what happened.

Where to start: five actions with the best return

If we had to sketch a minimal sensible plan for the next quarter, it would look like this:

1. MFA everywhere there is remote access and email — low cost, biggest effect.
2. An inventory of internet-exposed services, closing or patching everything unnecessary or outdated.
3. An immutable backup plus a restore test — with a measured recovery time for key systems.
4. An Active Directory review for escalation paths and over-privileged accounts.
5. A one-hour tabletop exercise with the board: who decides, who communicates, where the emergency contacts are.

Should you pay the ransom?

Paying does not guarantee that you will get your data back or that it won’t be published anyway. It also funds the next attacks. In our experience, organisations that invested in working backups and a response plan in advance almost never face this dilemma — they restore the environment from backup.

Summary

Ransomware is not an attack you cannot defend against. It is a multi-stage attack, which means many opportunities to break it: MFA, Active Directory hardening, segmentation, immutable backups and anomaly detection. If you’d like to see how far an attacker could get in your network, book a penetration test — we’ll run a controlled scenario and point out the weak spots.

Frequently asked questions (FAQ)

How long does a ransomware attack run before encryption starts? Usually from a few days to a few weeks after the initial entry. That is the window in which the attack can be detected and stopped — provided someone is watching logs and EDR alerts. In extreme cases (ready-made access bought from a broker plus an automated attack) the whole operation can close within hours.

Is a small company really a target? Yes — precisely because the attack is automated. Ransomware groups’ scanners don’t check company size, only open ports and vulnerable service versions. Small companies fall victim to less publicised but more frequent “opportunistic” attacks, and the ransom is calibrated to their revenue.

We have a cloud backup. Is that enough? It depends on the configuration. If the copy is synced continuously and accessible from the same accounts as production, it will be encrypted or deleted along with it. What matters is versioning, immutability (object lock), separate credentials and a regular restore test.

Will cyber insurance cover the losses? Increasingly yes, but policies require demonstrating specific controls (MFA, EDR, offline backups) — lacking them can mean a refused payout. Insurance also doesn’t replace a response plan: operational downtime and lost customer trust don’t disappear with the payout.

Where do we start if we have none of the above? With MFA on remote access and email, and one tested backup that cannot be overwritten. Those two steps break the most common scenarios. The next step is a security audit that orders the remaining work by real risk.