Mitigating Ransomware Attacks on Linux

For years, ransomware was a Windows problem, and Linux administrators could afford to be a little smug about it. That ended when the gangs did the math. A Windows laptop holds one person's files. A Linux server holds the company's database. And an ESXi or KVM host holds forty virtual machines whose disks are just files, which can all be encrypted at once.

Every major ransomware operation now ships a Linux build, usually aimed squarely at hypervisors.

What attacks on Linux actually look like

The examples are recent and instructive:

  • ESXiArgs, February 2023. Thousands of VMware ESXi hosts exposed to the internet, unpatched for a two-year-old vulnerability, had their virtual machine disks encrypted within days.
  • Cerber, late 2023. Attackers exploited a critical flaw in Atlassian Confluence and deployed a Linux ransomware build on the servers running it.
  • LockBit, the most prolific group until police took down its infrastructure in February, and most of its competitors, all maintain Linux and ESXi encryptors.

Notice what's missing from that list: clever Linux-specific malware breaking in through some exotic kernel flaw. Ransomware gets onto Linux the boring ways:

  1. An unpatched, internet-facing service. A VPN appliance, a wiki, a file-transfer server, a hypervisor management interface.
  2. Stolen credentials. SSH passwords guessed or bought, keys copied from a compromised workstation, cloud API keys leaked in a repository.
  3. The Windows side first. Attackers take over Active Directory, then use it to reach the Linux servers and hypervisors joined to it, or just read the administrators' saved passwords.

Then they spend days or weeks inside, quietly. They find the backups and delete them, steal the data so they can extort you even if you restore, and only then encrypt everything at once.

The defense that matters most: backups they can't touch

If you do one thing after reading this, make it this one. Good backups turn a ransomware attack from a catastrophe into a very bad week.

The key word is immutable. Attackers go after backups first, so a backup that the compromised server can delete isn't a backup.

  • Pull, don't push. A backup server that connects to production and pulls data is much safer than production servers pushing to it with credentials that could also delete everything.
  • Append-only storage. Restic with rest-server --append-only and Borg in append-only mode let a client add backups but not delete them. Pruning happens separately, from a trusted machine.
  • Object lock. S3-compatible storage with Object Lock in compliance mode won't let anyone delete a backup before its retention date. Not you, not the attacker, not the provider's support desk.
  • Snapshots on a separate system. ZFS or Btrfs snapshots are great, but only if they're replicated to a machine with different credentials.
  • The 3-2-1 rule, plus one. Three copies, on two kinds of media, one off-site, and one that's offline or immutable.
  • Test restores. On a schedule, for real, timed. A backup you've never restored is a hope.

Make getting in hard

  • Patch internet-facing systems first, and fast. CISA's Known Exploited Vulnerabilities catalog tells you which bugs are actually being used. Anything on it that you expose to the internet gets patched in days, not at the next maintenance window.
  • Never expose management interfaces. ESXi, vCenter, Proxmox, iDRAC, iLO and Kubernetes dashboards belong on a management network reachable only through a VPN or an identity-aware proxy.
  • SSH: keys only. Set PasswordAuthentication no, disable root login, and use a bastion or a mesh VPN rather than exposing port 22 everywhere. Protect the private keys on your administrators' laptops like the master keys they are.
  • MFA for every admin path, including the hypervisor console and the cloud account.
  • Least privilege. Separate admin accounts, scoped sudo, and service accounts that can't log in interactively. More on that in the least privilege principle.
  • Keep hypervisors off your main directory, or at least out of reach of the ordinary domain admin group. If one compromised AD account can log into every host, so can the attacker.

Make spreading and encrypting noisy

  • Segment the network. Workstations shouldn't be able to reach hypervisor management, and web servers shouldn't be able to reach backup servers.
  • Restrict outbound traffic. Servers that only need to talk to your package mirror shouldn't be able to upload a terabyte to an arbitrary address. That catches data theft, which is half of modern ransomware.
  • Log centrally. auditd and the journal, shipped somewhere the attacker can't edit. Watch for new admin accounts, new SSH keys, mass file renames and sudden spikes in disk writes.
  • Runtime detection with tools like Falco or Wazuh can flag suspicious process behavior on Linux hosts and containers.

And keep your expectations of antivirus realistic. ClamAV is useful for scanning mail and uploads. It won't stop an operator who has your root password and runs a fresh encryptor at 2 a.m.

When it happens anyway

  • Isolate, don't power off. Disconnect affected machines from the network, but leave them running if you can. Memory holds evidence, and sometimes keys.
  • Assume they're still in. Rotate every credential the attackers could have seen, starting with domain admin, hypervisor and backup credentials, before you restore.
  • Restore to clean, patched systems, from a backup taken before the intrusion began. That's often weeks earlier than the encryption.
  • Call for help. Your cyber insurance provider, an incident response firm and, in the US, the FBI or CISA. Paying the ransom funds the next attack and doesn't guarantee you'll get your data back. Whether to pay is a decision for leadership and lawyers, and it's much easier when good backups mean you don't have to.
  • Write it up. The postmortem is how next time doesn't happen.

The short version

Patch what faces the internet, lock down admin access, segment the network, and keep backups the attacker can't delete. None of it is exotic. All of it is work. It's still a lot cheaper than the alternative.

Since then

Added October 2026. Later in July 2024, Microsoft reported several ransomware groups exploiting an ESXi flaw that gave full admin rights to any member of an Active Directory group named "ESX Admins." If an attacker could create that group in the domain, they owned every joined hypervisor. It's the third point in the access list above, made real.