Ransomware on Linux servers rarely arrives as a single binary on one host: it usually follows stolen SSH access, spreads with the same keys and service accounts the estate trusts, and encrypts application data, databases and NFS shares that many other systems depend on. This playbook covers how a Linux ransomware incident shows up, the triage questions that decide scope, containment in priority order, the persistence to hunt for (SSH authorised keys, cron, systemd units, preload libraries), the auditd and journal evidence to secure before anything is rebuilt, and how to check backups and rebuild with confidence. It is written for Linux administrators, incident responders and SOC teams handling general purpose Linux hosts such as Ubuntu, Debian, RHEL and their derivatives. Hypervisor incidents are covered separately in the ESXi Ransomware Playbook, and the cross-platform response method is in the Ransomware Response and Recovery Guide; this page stays on what is specific to Linux.
Key takeaways
- Disconnect, do not power off. CISA's ransomware checklist says to power devices down only if you cannot disconnect them, because shutting down loses volatile memory evidence.
- Treat SSH keys as the blast radius. Any private key or agent socket on an affected host, and any
authorized_keysfile it could write, must be assumed compromised until reviewed. - Collect logs off the host early. The auditd log in
/var/log/audit/, the systemd journal andauth.logorsecureare the timeline, and an attacker with root can delete them. - Rebuild rather than clean. Root level compromise means you cannot trust the installed system; restore data onto freshly built hosts from known-good images and configuration management.
- Prove backups before you need them. Check that backups were not reachable with the same credentials, confirm their timestamps predate the intrusion, and test a restore on an isolated host.
How the incident shows up
Linux encryption tends to be noticed by applications failing rather than by a desktop ransom screen. Typical signals:
| Signal | Where you see it | What to check next |
|---|---|---|
| Files renamed with a new extension, ransom note text files in many directories | Application errors, users of NFS or SMB shares | Which mount points and hosts hold renamed files; earliest modification time |
| Databases or services failing to start | Monitoring, systemctl status, application logs | Whether data files were encrypted or deleted (T1486, T1485) |
| CPU and disk I/O spikes across many hosts at once | Monitoring, hypervisor metrics | A mass encryption run; identify the process and parent |
| Unexpected SSH logins, often as root or a service account, from internal hosts | /var/log/auth.log or /var/log/secure, journal | Lateral movement over SSH (T1021.004) |
| Snapshots, backup jobs or LVM volumes deleted | Backup console, storage logs | Inhibit System Recovery (T1490): encryption is usually next or already done |
| Large outbound transfers before encryption | Firewall, NetFlow, proxy logs | Data theft for double extortion |
| auditd stopped, logs truncated, shell history empty | Missing log gaps, auditctl -s | Anti-forensics (T1070.003 Clear Command History) |
Initial access to Linux estates is commonly through exposed SSH with stolen or weak credentials, exploitation of a public-facing application (T1190), a web shell (T1505.003), or a pivot from a compromised Windows domain into Linux hosts that trust it. The Linux Detection and Response Guide covers the detection engineering behind these signals.
Triage questions
- Is encryption still running? Look for the process with high I/O (
top,iotop,ps -ef --forest) and note its PID, parent, user and binary path before anything else. Capture memory now if you have a tool and procedure for it. - Which hosts and shares are affected? Encrypted files on an NFS export may have been written by a client, not by the server. Identify the writing host from NFS server logs, file ownership and client mount tables.
- Which identity did the attacker use? Read the authentication logs for the accepted login before the encryption: user, source IP, and whether it was a password or a public key (
sshdlogs the key fingerprint onAccepted publickey). - Where else does that identity work? Map the key or account across hosts: configuration management, central
authorized_keysmanagement, SSH certificate authorities, sudo rules and directory groups (SSSD or similar). - Was data taken? Check egress logs for the days before encryption. Double extortion changes the notification decision even if every file is restored.
- Are backups intact and isolated? Identify the last clean backup per system and whether the backup server, repository or snapshot tooling was reachable from the affected hosts or credentials.
- Is the Windows domain or hypervisor also involved? If yes, run those playbooks in parallel, because Linux recovery may depend on them.
Containment priorities
- Isolate affected hosts at the network layer. Move them to a quarantine VLAN or security group, or apply a host firewall rule that allows only your forensic workstation. If many hosts are affected, CISA advises taking the network segment offline at the switch level. Use out-of-band communication so the attacker does not see your response.
- Stop encryption without destroying evidence. Suspend the process (
kill -STOP) rather than killing it if you intend to capture memory, then terminate it. Power off only if you cannot disconnect the host. - Unmount or disable shared storage. Make NFS exports read-only or stop exporting them, and disable SMB shares served by Samba, so a still-infected client cannot encrypt more data.
- Cut the attacker's access paths. Block the source IPs, disable the accounts used, and remove the public keys found in the attacker's logins from every
authorized_keysfile. If you use an SSH certificate authority, revoke the certificates and update theRevokedKeyslist. See the SSH Key Compromise Response Playbook. - Protect backups. Disconnect backup repositories from production networks, suspend scheduled jobs that would overwrite good copies with encrypted data, and change the backup system's own administrative credentials from a clean device. The Backup Identity Isolation Guide explains why these credentials matter.
- Rotate shared credentials. Database passwords, API keys in environment files, cloud access keys and Kerberos keytabs present on affected hosts should be rotated once you can do it from a clean system.
Containment looks different depending on where the Linux host runs and how large the estate is.
| Environment | Isolation method | Evidence first step | Watch for |
|---|---|---|---|
| Physical server | Switch port shutdown or quarantine VLAN | Memory capture, then disk image | Out-of-band management interfaces (BMC) on the same network |
| Virtual machine on a hypervisor | Disconnect the virtual NIC or move to an isolated port group | Hypervisor snapshot including memory where supported | Whether the hypervisor itself is compromised; if so, run the ESXi playbook |
| Cloud instance | Replace the security group with one that allows only forensic access | Volume snapshot before termination | Instance roles and cloud keys on the host; rotate them |
| Container host | Cordon the node and isolate its network | Snapshot the node volume; record running containers and images | Cluster credentials and service account tokens on the node |
Small estates with a handful of servers can usually isolate everything at once and rebuild by hand from documented steps. Large estates need a triage cut: isolate the hosts that share credentials with the affected ones, keep unaffected business services running behind tightened firewall rules, and rely on configuration management to rebuild at scale. In both cases, decide early who can authorise taking a production service offline, because that decision is the usual source of delay.
Eradication
Hunt for persistence on every affected host and on hosts the compromised identities could reach. The table lists the common Linux locations; findings feed both eradication and the rebuild configuration.
| Persistence type | Where to look | ATT&CK v20 |
|---|---|---|
| SSH authorised keys | ~/.ssh/authorized_keys and authorized_keys2 for every user including root and service accounts; AuthorizedKeysFile and AuthorizedKeysCommand in sshd_config and its drop-in directory | T1098.004 SSH Authorized Keys |
| Cron and at | /etc/crontab, /etc/cron.d/, /etc/cron.{hourly,daily,weekly,monthly}/, user crontabs in /var/spool/cron/, at jobs | T1053.003 Cron |
| systemd units and timers | /etc/systemd/system/, /usr/lib/systemd/system/, ~/.config/systemd/user/; systemctl list-timers --all | T1543.002 Systemd Service |
| Dynamic linker preload | /etc/ld.so.preload, LD_PRELOAD set in service or profile files | T1574.006 Dynamic Linker Hijacking |
| Shell start-up files | /etc/profile, /etc/profile.d/, ~/.bashrc, ~/.bash_profile | T1546.004 Unix Shell Configuration Modification |
| Init and rc scripts | /etc/rc.local, /etc/init.d/ | T1037.004 RC Scripts |
| New local accounts and sudo rules | /etc/passwd, /etc/shadow, /etc/group, /etc/sudoers and /etc/sudoers.d/ | T1136 Create Account, T1078.003 Local Accounts |
| Web shells | Web roots and upload directories, recently modified script files | T1505.003 Web Shell |
- Compare against a baseline: package verification (
rpm -Vaon RPM systems,debsumsordpkg --verifyon Debian family systems) and file integrity monitoring baselines show modified system binaries. See the Linux File Integrity Monitoring Guide. - Fix the entry point: patch the exploited application, remove password authentication from internet-facing SSH, and close the management exposure that allowed access. Apply the controls in the Linux Server Hardening Guide to the rebuild baseline.
- Decide rebuild over clean: where the attacker held root, assume rootkit level tampering is possible. Eradication findings tell you what to block and where else to hunt; they do not make the host trustworthy again.
Recovery
- Prioritise by dependency. Identity and directory services, DNS, configuration management and secrets stores come first, because everything else depends on them. Then databases, then application tiers. See Recovering IAM and PAM After Ransomware or Domain Compromise.
- Rebuild hosts from trusted sources. Use signed installation media or golden images and your configuration management code, with new SSH host keys, new user keys and new service credentials. Do not copy
/etcor home directories wholesale from affected hosts. - Check backups before restoring. Confirm the backup timestamp predates the earliest attacker activity, not just the encryption time. Scan restored data for web shells and scripts, and restore first onto an isolated host to validate.
- Restore data, not systems. Bring back application data and database dumps onto the new hosts; reapply configuration from code.
- Check decryption options only through trusted routes. CISA recommends consulting law enforcement about possible decryptors. See the Ransomware Decryptors guide before running any third-party tool.
- Reconnect in stages. Only clean, rebuilt hosts go back on the production network, with enhanced logging and alerting turned on first.
| Recovery check | Pass condition |
|---|---|
| Backup provenance | Taken before the first attacker login, stored where affected credentials could not delete it |
| Credentials | All SSH keys, service passwords, keytabs and API keys from affected hosts rotated |
| Logging | auditd running with rules loaded, journal persistent, logs forwarding off-host |
| Access | No password SSH on exposed hosts; root login disabled; sudo rules reviewed |
| Monitoring | Alerts on new authorized_keys entries, new cron or systemd units, and mass file renames |
Evidence to preserve
Collect before rebuild, hash every item and record the chain of custody. The Linux Forensics Guide covers acquisition technique in depth.
| Evidence | Why it matters | How to collect |
|---|---|---|
| Memory image | Encryption keys sometimes remain in memory; running processes and network connections | Capture before shutdown with an approved tool |
| Disk image or VM snapshot | Full timeline, deleted files, malware samples | Hypervisor snapshot or block-level image, kept read-only |
| auditd logs | Process execution, file and identity changes tied to the audit user ID | Copy /var/log/audit/; query with ausearch -ts ... -te ... -i or by rule key with -k |
| systemd journal | Service starts, sshd events, kernel messages per boot | Copy /var/log/journal/ or export with journalctl -o export; journalctl --verify checks file consistency |
| Authentication logs | Accepted logins, key fingerprints, sudo use | /var/log/auth.log (Debian family) or /var/log/secure (RHEL family) |
| Persistence artefacts | Attacker keys, cron entries, unit files | Copy the files in the eradication table with metadata intact |
| Ransom notes and an encrypted file sample | Family identification, decryptor checks | Copy, do not open on a production host |
| Network and NFS server logs | Exfiltration and which client wrote encrypted files | Export from firewall, flow collector and file server |
| Playbook phase | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | MITRE ATT&CK v20 addressed |
|---|---|---|---|
| Triage and scoping | RS.AN-03 | IR-4, AU-6 | T1021.004 SSH, T1190 Exploit Public-Facing Application |
| Containment | RS.MI-01 | SC-7, AC-2, IA-5 | T1486 Data Encrypted for Impact |
| Eradication | RS.MI-02 | IR-4 | T1098.004, T1053.003, T1543.002, T1574.006 |
| Evidence | RS.AN-03 | AU-9 | T1070.003 Clear Command History |
| Recovery | RC.RP-01, RC.RP-03 | CP-9, CP-10 | T1490 Inhibit System Recovery |
| Notification | RS.CO-02 | IR-6 | Not applicable |
Notification triggers
- Personal data: encryption that makes personal data unavailable is itself a personal data breach under GDPR, not only theft. Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to result in a risk to individuals; Article 34 adds notice to individuals where the risk is high. See the Breach Notification Laws by Country Guide.
- NIS2 entities: significant incidents need an early warning to the CSIRT or competent authority within 24 hours of awareness and an incident notification within 72 hours, under Article 23 of the NIS2 Directive as transposed nationally. See the NIS2 Directive Guide.
- US listed companies: Form 8-K Item 1.05 for material incidents, generally within four business days of the materiality determination.
- Law enforcement and national agencies: CISA's checklist asks US organisations to report to CISA, the FBI or the US Secret Service; UK organisations can report to the NCSC and Report Fraud (which replaced Action Fraud on 4 December 2025). In Scotland, report to Police Scotland on 101. Reporting also opens access to decryptor intelligence.
- Payments: any payment decision needs legal advice on sanctions; see the Ransomware Payments and Sanctions Guide.
Practitioner checklist
- Forward auditd, journal and authentication logs off-host in real time, so root on a server cannot erase the record.
- Keep an inventory of which SSH keys and service accounts work on which hosts, or move to short-lived SSH certificates.
- Alert on writes to
authorized_keys, cron directories, systemd unit paths and/etc/ld.so.preload. - Store backups where production root and backup operator credentials cannot delete them, with immutability where available.
- Rebuild from configuration management code and golden images, and test that a full rebuild works.
- Pre-stage a forensic collection kit and a quarantine network for Linux hosts.
- Export NFS shares with the narrowest client list and use read-only exports where writes are not needed.
- Run a tabletop exercise on a Linux encryption scenario with application owners, including the backup restore test.
Standards and references
- CISA: #StopRansomware Guide and Ransomware Response Checklist
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- Linux man-pages: ausearch(8)
- Linux man-pages: journalctl(1)
- MITRE ATT&CK: T1486 Data Encrypted for Impact
- MITRE ATT&CK: T1098.004 SSH Authorized Keys
- GDPR: Article 33 Notification of a personal data breach to the supervisory authority
Related NHI Mgmt Group resources: ESXi Ransomware Playbook · Ransomware Response and Recovery Guide · Linux Logging and auditd for Defenders Guide · SSH Key Management Guide · Linux Service Accounts and Keytab Management Guide