Ransomware Checklist: Breaking the Attack at Each Stage

Ransomware that encrypts your servers on a Friday night usually got in days or weeks earlier. Today's groups steal data first and encrypt second (double extortion), so even if you restore from backup they still threaten to publish. The good news: every attack has to pass through several stages, and each stage is a chance to stop it.

This checklist follows those stages.

Stage 1: Getting in

Common routes: phishing email, RDP or VPN exposed to the internet without MFA, unpatched firewalls and VPN gateways, and passwords stolen by infostealer malware on personal PCs.

• MFA on email, VPN, remote access and every admin account
• No RDP exposed to the internet. Use VPN with MFA, or ZTNA
• Patch internet-facing firewalls, VPNs and servers within days when a flaw is reported as actively exploited; everything else within 14 days
• Email filtering with sandboxing, and SPF/DKIM/DMARC published
• .iso, .img, .js, .vbs and .hta attachments blocked at the email gateway. Ordinary staff never need them
• Confirm macros in Office files from the internet are blocked (the default in current Microsoft 365, but older Office builds or a Group Policy may have turned it off)

The front door is often the firewall itself

Over the last few years, many ransomware cases started with a flaw in an internet-facing firewall or VPN gateway, not with a user's click. Three habits close most of that door:

• Subscribe to your firewall and VPN vendor's security advisories, and name the person who reads them
• No management interface (web admin, SSH) open to the internet. Manage from inside or over VPN only
• Replace appliances that have reached end of support. A box that no longer receives firmware updates will stay vulnerable forever, however well it is configured

When a critical flaw is published, assume attackers start scanning within days. Patch first, then check the logs for signs that someone got in before you did.

Stage 2: Taking hold and spreading

Once on one machine, the attacker hunts for admin credentials and moves sideways. Make every step hard and noisy.

• EDR on every PC and server, with tamper protection on
• Standard users have no local admin rights
• Windows LAPS so every PC has a unique local admin password
• Admin accounts separate from the accounts used for email and browsing
• VLANs for servers, users, CCTV/NVRs and guests; workstation-to-workstation traffic blocked
• SMBv1 off, PowerShell restricted, script block logging on

Don't forget the hypervisor

More and more attacks skip the individual servers and go straight for the VMware ESXi or Hyper-V host, because encrypting one datastore takes every virtual machine down at once.

• Hypervisor and vCenter management interfaces on their own management VLAN, reachable only from admin workstations
• MFA on vCenter and on any hypervisor management portal
• Think twice before joining ESXi hosts to Active Directory. If you do, review which AD groups get admin rights on the hosts, since a forgotten group can hand an attacker the whole cluster
• SSH on hosts off unless you are working on them, and lockdown mode where your edition supports it
• Only approved remote-support tools allowed. Unknown AnyDesk or similar installs on servers are a classic early sign

Stage 3: Cutting off your way out

Before encrypting, attackers look for backups and delete shadow copies. If your backups survive, you have options. If they don't, you don't.

• Backups follow 3-2-1-1-0: at least one copy immutable or offline, and offsite
• Backup server not domain-joined, with separate credentials and MFA
• Backup storage not mapped as a Windows drive. Anything a user can see, ransomware can encrypt
• Restores tested quarterly, and you know how many hours each critical system takes to restore

Stage 4: Noticing in time

• Logs from firewalls, servers and EDR collected in one place
• Someone actually reads alerts, weekends included. If the in-house team can't, use a SOC service or turn on automatic isolation in the EDR
• Alerts for pre-encryption signals: shadow copy deletion, new admin accounts, network scanning tools on user PCs, large overnight uploads

Worked example: how long would the restore really take?

Backups that exist but take a week to bring back are not much of a plan. Take a 4 TB file server:

That is why we keep the immutable copy local where possible (a hardened backup repository or an appliance with object lock) and the offsite copy for the worst case. Most internet connections in Laos are much slower upstream than downstream and get shared with the whole office, so test how fast a cloud restore actually runs before you rely on it. More detail in our guide to the 3-2-1 backup rule.

Also decide the restore order in advance. Usually: domain controller and DNS first, then the accounting or ERP database, then email if it is on-premises, then file shares. Writing that order down saves hours of arguing on the day.

Priorities by size

The first hour, if it happens

Print this part. On the day, your servers may not be available.

1. Unplug the network cable or turn off Wi-Fi on affected machines. Don't power them off yet; memory evidence will be lost.
2. Call the IT lead and management from the emergency contact list. Use phones or a prepared chat group, not company email.
3. Disconnect backup repositories and check they are intact.
4. Reset admin credentials from a machine you know is clean.
5. Start a timestamped log of every action from the first minute, and call your pre-agreed incident response provider if you have one.

Paying does not guarantee you get your data back, or that stolen data is deleted.

What we keep finding on site

• The NAS used for backup is mapped as a drive on every PC and gets encrypted along with the file server.
• The CCTV NVR sits on the server subnet, still on its default password.
• Backups succeed every night, and nobody has ever tried a restore.
• The backup server has no UPS. A brownout mid-backup at a provincial branch corrupts the repository, and nobody knows until the day they need it.

If you can only start three things this month

MFA on everything reachable from the internet, one immutable offsite backup copy, and EDR with someone watching the alerts. For provincial branches on slow links, back up locally with incrementals and replicate to Vientiane or the cloud overnight. Revisit this checklist every six months; new devices tend to arrive with insecure defaults.

Let us test one restore with you

The most revealing question is this: if your file server were encrypted tonight, where would you restore from, and how many hours would it take? If you're not sure, we'll come in and run a real restore of one system with your team, then work through the checklist above item by item.