How to scan a Linux server for malware (step-by-step, 2026)

You suspect something is wrong with a server, or you simply want to know it is clean. A malware scan on Linux is not one command: malicious code hides in files, in running processes, in scheduled tasks and in the accounts that can log in. This guide walks through each place, in the order an incident responder would check them.

Run every command as root (or with sudo), and copy the output somewhere safe before changing anything: if the server *is* compromised, you will want the evidence.

Step 1: Check what is running right now

Malware that does real damage is usually running. Start with processes, not files.

ps auxf --sort=-%cpu | head -25

Red flags:

• a process using most of the CPU with a vague name (kworkerd, .x, systemd-helper);
• a process running as www-data, nginx or nobody that is not your web server;
• a binary whose path is in /tmp, /var/tmp or /dev/shm.

For any suspicious PID, see where the executable really lives, even if the file was deleted after launch:

ls -l /proc/<PID>/exe
cat /proc/<PID>/cmdline | tr '\0' ' '

A link ending in (deleted) is a classic sign: the attacker started the program, then removed the file to hide it.

Step 2: Check network connections

Most malware talks to the outside: a mining pool, a command server, a spam target.

ss -tunap | grep -v '127.0.0.1'

Look for outbound connections to unusual ports (3333, 4444, 5555, 7777 and 14444 are common for mining pools) and for services listening on ports you never opened.

Step 3: Look for executables where they should not be

World-writable folders are the favourite drop zone.

find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
find / -xdev -type f -name ".*" -perm -u+x 2>/dev/null | grep -v -E '/(proc|sys|snap)/'

The second command lists hidden executable files anywhere on the main filesystem. A few results are normal; a hidden binary in a web folder or a home directory is not.

Step 4: Find recently modified system files

If an attacker replaced a system binary, its modification date often gives it away.

find /bin /sbin /usr/bin /usr/sbin /lib /etc -xdev -type f -mtime -7 -ls 2>/dev/null

On Debian and Ubuntu you can also ask the package manager which installed files no longer match their original checksum:

dpkg --verify 2>/dev/null | grep -v ' c /etc/'

On RHEL, Rocky or AlmaLinux:

rpm -Va 2>/dev/null | grep -E '^..5'

Any changed file in /usr/bin or /usr/sbin that you did not update yourself deserves a closer look.

Step 5: Scan web directories for webshells

If the server hosts a website, the web root is the most likely entry point. Search for the functions webshells rely on:

grep -rIl --include=*.php -E "eval\(|base64_decode\(|gzinflate\(|shell_exec\(|assert\(\$_" /var/www 2>/dev/null

Legitimate code uses some of these functions, so review each hit. Files with a very long single line, random names, or a recent date in an upload folder are the ones to open first. Our webshell detection guide goes deeper.

Step 6: Check persistence: cron, systemd and SSH keys

Attackers make sure they come back after a reboot or a cleanup.

# Scheduled tasks for every user
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
ls -la /etc/cron.* /var/spool/cron 2>/dev/null

# Services added recently
systemctl list-unit-files --state=enabled | head -50
find /etc/systemd/system -type f -mtime -30 -ls

# SSH keys that grant access
find / -xdev -name authorized_keys -exec ls -l {} \; -exec cat {} \; 2>/dev/null

A cron job that downloads a script with curl ... | sh, a service you do not recognise, or an SSH key you cannot attribute to a person is a strong sign of compromise.

Step 7: Check users and recent logins

awk -F: '$3 == 0 {print $1}' /etc/passwd   # accounts with root rights
last -n 20
grep "Accepted" /var/log/auth.log* 2>/dev/null | tail -20

Only root should have UID 0. Logins from countries or at hours that do not match your team need an explanation.

Step 8: Run a signature-based antivirus scan

Manual checks find behaviour; an antivirus finds *known* malicious files quickly. Run it at low priority so production is not affected:

nice -n 19 ionice -c3 <your-scanner> -r /var/www /home /tmp /var/tmp

Scan the directories that receive files from the outside (web roots, upload folders, home directories, temporary folders) rather than the entire disk, and update signatures before each run.

What to do if you find something

1. Do not reboot or delete first. Save the suspicious files, the process list and the logs.
2. Isolate the server from the network if it is actively attacking others or leaking data.
3. Rotate every secret that was on the machine: SSH keys, database passwords, API keys.
4. Find the entry point (an outdated plugin, a weak password, an exposed service) before cleaning, or the attacker will come back the same way.
5. If the compromise is deep (changed system binaries, kernel modules), rebuild the server from a clean image rather than cleaning it.

How often should you scan?

A one-off scan tells you about today. Attacks happen on any day, so the useful rhythm is:

• continuously for logins, processes and CPU;
• daily for files in web and upload folders;
• daily for known vulnerabilities in the software you run.

Doing this by hand on every server does not scale. That is the gap automated monitoring fills.

Frequently asked questions

Can I scan a Linux server for malware without installing anything?

Yes. Steps 1 to 7 only use tools present on every distribution (ps, ss, find, grep, the package manager). They find most real-world infections, which are cryptominers, webshells and backdoors rather than classic viruses.

Will a malware scan slow down my server?

Process and network checks are instant. File scans read the disk: run them with nice and ionice, limit them to risky folders, and schedule them at night.

How do I know a scan result is a false positive?

Check the file's origin: is it part of a package (dpkg -S file or rpm -qf file), of your application's repository, or of a plugin you installed? A file nobody can explain should be treated as malicious until proven otherwise.

FounderMode runs these checks for you every day (antivirus, intrusion signs, persistence, vulnerable versions, CPU and disk) and sends a plain-English report to Slack. Start the free trial.