Trace and Stop Active Ransomware on a Linux Server Now

If files are renaming, CPU is pegged, and ransom notes just appeared on your Linux server, you are in an active incident—not a drill. This guide walks Australian business owners and sysadmins through a terminal-first response: find the encryptor, choose between cutting the network layer or isolating the process ID (PID), and verify the threat has stopped before you restore anything.

Fixwebnode provides direct remote Linux server support for this exact crisis—live process triage, firewall containment, and recovery sequencing—not a freelance board. If you need hands-on help while you work the steps below, start here: Linux server support and bug fixing.

Why real-time ransomware response matters on Linux

Ransomware on Linux rarely waits politely. Once the payload is running, every second of disk I/O can mean more encrypted databases, mail stores, and application files. Australian small businesses often run Ubuntu or Debian VPS instances for websites, accounting, and customer portals; an uncontained encryptor can freeze invoicing and operations in one afternoon.

Two decisions dominate the first minutes. Option A: drop or choke the network path with firewall rules so command-and-control and lateral spread stop cold. Option B: identify the active encryption PID with ps aux (and related tools) and isolate or terminate it at the process level so local disk writes halt even if the box must stay partially online. You will often use both—network first if the host is still talking outbound, then PID isolation to stop encryption threads that already have open file handles.

This is server support under pressure: preserve evidence where you can, stop the bleed, then restore from clean backups. Geography for remote work across Australia is covered on our service areas page; the steps below are designed so you can act from SSH immediately.

How do I stop ransomware encrypting files on my Linux server in Australia right now?

Disconnect or firewall the host’s outbound path, identify the suspicious high-CPU or mass-open-file process with ps aux, lsof, and iotop, then stop that PID (and its parent) before you reboot or restore. Do not pay, do not run unknown “decrypt” binaries, and do not wipe disks until you have captured process lists and a sample of the ransom note for your insurer or IR partner.

If encryption is still advancing after a kill attempt, treat the box as compromised at the account level and move to full network quarantine plus offline restore.

Common issues during an active Linux ransomware incident

1. Mass file renaming while an unknown process burns CPU and disk

Symptoms: *.doc, database files, or web roots suddenly show new extensions; top shows a non-package binary at high CPU; disk LED or cloud IOPS spike. Root cause is usually a user-land encryptor already running under a web, deploy, or stolen SSH account.

2. Outbound C2 or secondary payload still reachable over the network

Symptoms: unexpected ESTABLISHED connections on high ports, DNS to odd hosts, or re-infection minutes after you kill one PID. Root cause is the malware maintaining network reach for keys, second-stage tools, or lateral movement.

3. Encryptor respawns after kill because of cron, systemd, or a parent watcher

Symptoms: you kill -9 a PID and seconds later a new PID appears with the same binary path; timers or @reboot entries reinstall the payload. Root cause is persistence outside the single process you terminated.

4. Shared storage or mounted backups are being encrypted in the same pass

Symptoms: NFS/SMB mounts, attached backup disks, or object-storage FUSE mounts show the same extension changes. Root cause is the encryptor walking every mounted path the compromised user can write.

Issue 1 — Trace the active encryptor and isolate its PID

Goal: identify the process doing bulk writes, freeze it, then remove it without rebooting into a worse state.

Step 1 — Open a second SSH session and freeze panic changes

Keep one session for monitoring. Avoid random package installs. Work as root only as needed.

sudo -i
export HISTFILE=/root/.incident_history
whoami; hostname; date -u

Step 2 — Rank CPU and disk hogs

ps aux --sort=-%cpu | head -n 25
ps aux --sort=-%mem | head -n 25
sudo iotop -aoP
sudo pidstat -d 1 5

Note any binary not from /usr/bin, /usr/sbin, or known service paths—especially under /tmp, /dev/shm, /var/tmp, or home directories.

Step 3 — Confirm mass file activity on the suspect PID

sudo lsof -p <PID> 2>/dev/null | head -n 80
sudo ls -la /proc/<PID>/exe
sudo tr '\0' ' ' < /proc/<PID>/cmdline; echo
sudo ls -la /proc/<PID>/fd | head -n 50

If exe points to a dropped binary and fds show hundreds of regular files opening for write, treat it as the encryptor candidate.

Step 4 — STOP the process first (safer than immediate SIGKILL for evidence)

sudo kill -STOP <PID>
sudo kill -STOP <PPID>
ps -o pid,ppid,stat,cmd -p <PID>,<PPID>

STOP freezes encryption threads so you can capture hashes before kill:

sudo cp /proc/<PID>/exe /root/sample_encryptor.bin
sudo sha256sum /root/sample_encryptor.bin
sudo cat /proc/<PID>/maps | head

Step 5 — Terminate and verify no replacement PID

sudo kill -9 <PID> <PPID>
sleep 2
ps aux | grep -E 'tmp|shm|encrypt|lock' | grep -v grep
sudo find /tmp /var/tmp /dev/shm -type f -executable -ls 2>/dev/null

When to call Fixwebnode: the binary reappears, /proc/<PID>/exe shows deleted but activity continues, or you cannot tell parent from child under a web pool (php-fpm workers, Node, Java). Remote IR can map the tree and persistence while you hold the network closed.

Issue 2 — Drop or choke the network layer with firewall rules

Goal: stop C2, prevent exfiltration, and block lateral SSH/SMB from this host—without always yanking the cable if you still need inbound admin from a single jump IP.

Step 1 — Snapshot current connections (evidence + targeting)

ss -tulpn
ss -tpn state established
sudo journalctl -u ssh -n 100 --no-pager

Step 2 — Prefer controlled quarantine over blind reboot

If you use iptables (common on many VPS images):

sudo iptables -I OUTPUT 1 -o lo -j ACCEPT
sudo iptables -I OUTPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Optional: allow only your admin IP for SSH out/in management
sudo iptables -I OUTPUT 3 -p tcp -d YOUR.ADMIN.IP.HERE --dport 22 -j ACCEPT
sudo iptables -A OUTPUT -j DROP
sudo iptables -I INPUT 1 -i lo -j ACCEPT
sudo iptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -I INPUT 3 -p tcp -s YOUR.ADMIN.IP.HERE --dport 22 -j ACCEPT
sudo iptables -A INPUT -j DROP
sudo iptables -S

If you use nftables:

sudo nft add table inet quarantine
sudo nft add chain inet quarantine input '{ type filter hook input priority 0; policy drop; }'
sudo nft add chain inet quarantine output '{ type filter hook output priority 0; policy drop; }'
sudo nft add rule inet quarantine input iif lo accept
sudo nft add rule inet quarantine output oif lo accept
sudo nft add rule inet quarantine input ct state established,related accept
sudo nft add rule inet quarantine output ct state established,related accept
sudo nft add rule inet quarantine input tcp dport 22 ip saddr YOUR.ADMIN.IP.HERE accept
sudo nft list ruleset

Step 3 — Cloud security group / provider firewall

On AWS, GCP, Azure, or Australian VPS panels, also set the instance security group to deny egress except your admin IP. Host iptables alone is not enough if another interface or container network path exists.

Step 4 — Verify outbound is dead

curl -I --max-time 5 https://example.com || echo "outbound blocked as expected"
ss -tpn state established

Crisis choice note: choose network drop first when you see active outbound connections or multi-host risk. Choose PID isolation first when the host must keep serving a local console restore and you have already confirmed no useful C2 (or the encryptor is CPU-bound offline). In production IR, apply a tight INPUT/OUTPUT policy immediately, then freeze PIDs—order matters less than doing both within minutes.

When to call Fixwebnode: you are locked out after a bad rule, containers bypass the host filter, or you need coordinated quarantine across several Australian VPS nodes without destroying forensic state.

Issue 3 — Kill persistence so the encryptor does not return

Goal: remove the respawn path that makes PID kills feel useless.

Step 1 — Cron and user timers

sudo crontab -l
sudo ls -la /etc/cron.* /var/spool/cron/crontabs
for u in $(cut -f1 -d: /etc/passwd); do echo "== $u"; crontab -u "$u" -l 2>/dev/null; done
systemctl list-timers --all

Step 2 — systemd units and enabling paths

systemctl list-units --type=service --all | grep -viE 'ssh|network|systemd|cron|rsyslog'
ls -la /etc/systemd/system /etc/systemd/system/multi-user.target.wants
sudo grep -R "tmp\|shm\|curl\|wget\|base64" /etc/systemd/system/ 2>/dev/null | head

Step 3 — Shell startup and authorized_keys

sudo grep -R "curl\|wget\|python\|perl\|base64" /etc/profile /etc/bash.bashrc /root /home/*/.bashrc /home/*/.profile 2>/dev/null | head -n 50
sudo find /root /home -name authorized_keys -exec ls -la {} \;
sudo find /root /home -name authorized_keys -exec cat {} \;

Step 4 — Disable suspicious unit and delete dropped binaries only after hashing

sudo systemctl stop evil-unit.service 2>/dev/null
sudo systemctl disable evil-unit.service 2>/dev/null
sudo mv /path/to/dropped_binary /root/quarantine_$(date +%s).bin
sudo chmod 000 /root/quarantine_*.bin

When to call Fixwebnode: unknown rootkits, loadable modules, or shared web account compromise across many sites—persistence hunting expands quickly past a single crontab line.

Issue 4 — Protect mounts and stop encrypting backups

Goal: keep the only clean recovery copy offline.

Step 1 — List mounts and writeable backup paths

mount | column -t
df -h
sudo ls -la /mnt /backup /var/backups 2>/dev/null

Step 2 — Remount backup volumes read-only or unmount

sudo mount -o remount,ro /backup
sudo umount /mnt/nfs-backup || sudo umount -l /mnt/nfs-backup

Step 3 — Freeze application writes if databases are mid-encrypt

sudo systemctl stop nginx apache2 php*-fpm mysql mariadb postgresql docker 2>/dev/null
sudo sync

Only restart services after malware is gone and you are restoring from a known-good backup—not from the infected volume.

When to call Fixwebnode: you are unsure which snapshot is clean, RAID/LVM layout is non-trivial, or ransomware hit both production and the on-server backup directory.

Interactive decision path under pressure

If outbound sockets to unknown IPs exist: apply quarantine firewall (Issue 2), then PID STOP/kill (Issue 1), then persistence (Issue 3).

If no outbound but disk is screaming: PID STOP immediately, capture /proc/<PID>/exe, kill, unmount backups, then lock network anyway so a second stage cannot phone home when you bring services back.

If SSH is the only access path: never DROP all INPUT without allowing your admin IP first. Test a second session before you exit the first.

Verification checklist after containment

ps aux --sort=-%cpu | head
sudo iotop -aoP
ss -tpn
sudo find /var/www /home /var/lib/mysql -name '*.encrypted' -o -name '*README*' 2>/dev/null | head
sudo tail -n 200 /var/log/auth.log
sudo tail -n 200 /var/log/syslog

Document timestamps, PIDs, hashes, and firewall changes. That record matters for insurers and for any specialist who joins the call.

When DIY is enough vs when to book Fixwebnode

DIY can be enough when: you still have clean off-host backups, the encryptor was a single user-land binary, kill + cron cleanup stopped respawn, and firewall quarantine holds. Restore onto a rebuilt host or a verified clean image; rotate every secret that lived on the box (SSH keys, database passwords, API tokens, panel logins).

Book Fixwebnode when: PIDs respawn, multiple servers share credentials, backups may be tainted, you face SEV-1 downtime for a live store or client portal, or you need a disciplined remote incident channel while staff work offline communications. We work as a direct specialist Linux support partner for Australian businesses—remote terminal IR, containment review, and recovery sequencing—via Ubuntu Linux server support.

Do not negotiate with criminals from the compromised host. Do not run unofficial decrypt utilities that demand disabling your remaining defenses. Prefer rebuild + restore over “cleaning in place” when root was exposed.

Close the incident the right way

Real-time ransomware defense on Linux is a short loop: see the writes, cut the network path, freeze and remove the PID, erase persistence, protect mounts, then restore from clean media. The two crisis options—firewall quarantine versus kernel-visible PID isolation with ps aux and friends—are complementary, not rivals.

If you are mid-attack and need a specialist on the session with you, start a conversation through Fixwebnode’s Linux server support page: https://fixwebnode.com.au/ubuntu-linux-server-support-bug-fixing-adelaide-australia. Remote coverage details are listed under service areas. Act now—every minute of open encryption costs files you may not get back.