Detecting Linux Ransomware: auditd, Cron and Mass Encryption

Ransomware on Linux targets file servers, web and application hosts, and hypervisors. The binary is often a small compiled encryptor that walks directories such as /home, /var, /srv and /opt, or a mount point supplied by the operator, then writes a note. The first step is usually unremarkable shell activity, so we cover the endpoint with auditd and watch the behaviours that give the encryptor away.

Signals at a Glance

auditd Coverage

These rules log the building blocks: execution from world-writable directories, changes to the scheduling mechanisms, and permission changes. Bulk rename volume is better computed from your EDR or a file-integrity tool than from raw auditd, which can be heavy on busy hosts, so scope file watches to directories with data worth protecting:

# /etc/audit/rules.d/ransomware.rules  (tune/validate before production)
# Execution from world-writable locations
-a always,exit -F arch=b64 -S execve -F dir=/tmp -k exec_tmp
-a always,exit -F arch=b64 -S execve -F dir=/var/tmp -k exec_tmp
-a always,exit -F arch=b64 -S execve -F dir=/dev/shm -k exec_tmp

# Scheduling persistence
-w /etc/crontab -p wa -k cron_change
-w /etc/cron.d/ -p wa -k cron_change
-w /var/spool/cron/ -p wa -k cron_change
-w /etc/systemd/system/ -p wa -k systemd_change

# Mass permission changes
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,chown,fchownat -F auid>=1000 -F auid!=4294967295 -k perm_change

# Ransom-note style file creation in data directories (narrow to your paths)
-w /srv/ -p w -k data_write

Ship these events to your SIEM, and alert when perm_change or data_write keys spike for one process, or when a binary executed from the exec_tmp key then produces a flood of file events:

index=linux sourcetype=linux_audit key="perm_change" OR key="data_write" OR key="exec_tmp"
| bin _time span=5m
| stats count by host, exe, key, _time
| eventstats sum(count) as total by host, exe, _time
| where total > 500
| sort - total
# tune/validate: thresholds vary hugely by host role; start in report-only mode.

Process and Network Context

• Check how the process arrived. An ELF dropped by wget or curl from an external host and run within minutes, especially under a service account such as a web server user, is a strong lead.
• Look for stopped databases and application services immediately before the burst, and for deletion of snapshots, LVM volumes or backup directories.
• Compare against baseline for file servers. Rsync, backup jobs and log rotation produce legitimate bulk file activity; allowlist by executable path and user.
• Check for lateral SSH from a single compromised host to many servers, since operators often push the same encryptor to a fleet over SSH.