Ransomware

Why small servers are in scope

A ransomware attack does not need a large target. Any server that holds data someone needs, and can be reached through a weak password, an exposed service or an unpatched flaw, is a candidate. Attackers also look for backups, because CISA warns that many ransomware variants attempt to find and subsequently delete or encrypt accessible backups.

What actually reduces the risk

The defences are ordinary hygiene done consistently: patching, closing exposed services, strong SSH authentication, limited privileges and backups that an attacker cannot delete. Our ransomware protection guide for small VPS servers walks through them in order, and the backup strategy guide covers the recovery side.

A five-minute read-only triage on a suspect server

If something feels wrong, start with checks that change nothing. A bulk encryption run touches a very large number of files in a short time, so count what changed recently in directories that normally stay quiet, then look at scheduled jobs and live connections:

sudo find /var/www /srv /home -xdev -type f -mmin -60 | wc -l
systemctl list-timers
sudo ss -tnp

The find manual page defines -mmin -60 as modified less than 60 minutes ago and -xdev as staying on one filesystem. A count far above what you normally see is the signal, and so are unexpected timers, since systemctl list-timers shows what runs on a schedule, and outbound connections you cannot explain. Look at the backup job too: a stopped or failing job is often the earliest visible symptom.

If the signs are real, do not reboot or wipe the machine. The CISA #StopRansomware Guide says to power devices down only if they cannot be disconnected, because that loses volatile memory evidence, and, for cloud resources, to snapshot volumes for later forensic review. Isolate through your provider's firewall or console and continue with the first hour section of our ransomware guide.

Double extortion: restoring is only half of recovery

CISA describes double extortion as encrypting data and also stealing it, then threatening to publish it to pressure the victim. It adds that some actors use data theft alone, with no encryption at all. That changes what "recovered" means. A clean restore returns your service but does nothing about copies already taken, so make an inventory early: what personal, customer or credential data lived on this server, and what do your logs say left it?

The same guide warns that actors may monitor communications and could spread further if they notice the response, so coordinate out of band. Do not discuss the incident over email, chat or a ticket system hosted on the affected server. Keep notes of times, commands and findings, because you will need them for the restore, for any insurer and for regulators.

CISA also recommends reporting to the authorities. In the United States that means CISA (cisa.gov/report), your local FBI field office or the FBI's IC3 (ic3.gov). Elsewhere, contact your national CERT or police cybercrime unit, and ask counsel which notification duties apply to the data involved. After eradication, rebuild from a clean image and rotate every credential that lived on the host. The breach response guide covers the full sequence.

Related terms: Backup rule (3-2-1), Incident response, Least privilege, Patch management, RPO and RTO, Object Lock.