How to Check a Linux Server for Malicious Processes

A Linux server can run slower than usual not only because of high load or a large number of requests. The cause may be malware, cryptominers, backdoors, or other unwanted processes. However, high CPU usage alone does not indicate that a server has been compromised — first, you need to identify the source of the load and check the server for other signs of compromise.

When to Check the Server

You should check the server if:

• the CPU is constantly under high load for no obvious reason;
• unknown processes have appeared;
• the server has started using significantly more network traffic;
• unknown ports are open;
• RAM consumption has unexpectedly increased;
• new users or SSH keys have appeared;
• unknown cron jobs or systemd services have been found;
• files are being modified or appearing without administrator intervention;
• the server has started performing unknown tasks.

However, a single suspicious process is not proof of an infection. For example, high load may be caused by a database, PHP-FPM, backups, or normal web traffic.

1. Checking Running Processes

The first step is to check which processes are running on the system:
ps aux
For a more convenient view, you can use:
top

or:
htop
In the list, pay attention to processes with:

• unusual names;
• high CPU usage;
• high RAM consumption;
• an unknown user;
• a suspicious executable file location.

It is especially suspicious if a process has appeared recently and is constantly consuming a significant amount of system resources.

2. Finding Processes with High CPU Usage

To quickly find the most resource-intensive processes:
ps aux --sort=-%cpu | head
For example, you may see:


High CPU usage by mariadbd, php-fpm, or another known service is not in itself a sign of malicious activity.
However, an unknown executable file located in /tmp or another temporary directory requires further investigation.

3. Checking the Process Location

You can obtain information about a specific process through /proc.
For example:
readlink -f /proc/67580/exe

You can also check the command used to start the process:
tr '\0' ' ' < /proc/67580/cmdline

And the user that owns the process:
ps -o user,pid,ppid,cmd -p 67580

The location of the executable file is important. For example, system programs are usually located in /usr/bin, /usr/sbin, and other standard directories.
An unknown binary file in /tmp, /var/tmp, or /dev/shm does not by itself prove the presence of malware, but it is a reason for further investigation.

4. Checking Network Connections

A malicious process may establish outbound connections to external servers or open its own ports.
You can view active connections and listening ports using:
ss -tulpn

To view current TCP connections:
ss -tp
The output can show the PID and name of the process using a connection.
Pay particular attention to:

• unknown processes listening on network ports;
• unexpected outbound connections;
• connections to unknown external addresses;
• processes that should not normally have network activity.

5. Checking Open Ports

For an external check, you can use nmap from another server or computer:
nmap -Pn SERVER_IP
If you find a port that should not be open, first determine which service is using it:
ss -lntup
Do not automatically assume that every unknown port is malicious. It may be used by software installed by the administrator.

6. Checking System Users

The next step is to check the system users:
cat /etc/passwd
To find users who have a shell:
grep -E '/bin/(bash|sh|zsh)$' /etc/passwd

It is also useful to check recent logins:
last
And failed authentication attempts:
lastb
If an unknown user has appeared on the server or unexpected successful logins are found, you need to determine their origin.

7. Checking SSH Keys

If authentication via SSH keys is used, you should check the following file:
~/.ssh/authorized_keys
For the root user:
/root/.ssh/authorized_keys
An unknown key can provide persistent access to the server even after an individual malicious process has been removed.
Therefore, if you suspect that the server has been compromised, you should check the SSH keys of all users who have access to the server.

8. Checking Cron Jobs

Malware may use cron to start automatically after a reboot or at specific intervals.
Tasks for the current user:
crontab -l
Tasks for another user:
crontab -u USERNAME -l
You should also check the system directories:
ls -la /etc/cron.d/
ls -la /etc/cron.daily/
ls -la /etc/cron.hourly/
ls -la /etc/cron.weekly/
ls -la /etc/cron.monthly/
Pay particular attention to recently added jobs that launch unknown scripts or binary files.

9. Checking systemd

Modern Linux distributions use systemd to manage services.
List running services:
systemctl --type=service --state=running
List services configured to start automatically:
systemctl list-unit-files --state=enabled
If an unknown service is found, you can view its configuration:
systemctl cat SERVICE_NAME
This allows you to determine which file is executed and which user the service runs under.

10. Checking Temporary Directories

Pay attention to:
/tmp
/var/tmp
/dev/shm
You can find recently modified files:
find /tmp /var/tmp /dev/shm -type f -mtime -1 -ls
However, you should not immediately delete the files you find. First, determine which process created them and whether the files are currently being used.

11. Analyzing Logs

System logs can help determine when suspicious activity started.
To view systemd messages:
journalctl
For example, the latest messages:
journalctl -n 100
Or events from the last hour:
journalctl --since "1 hour ago"
For SSH, you can search for successful and failed login attempts. The exact log files depend on the distribution. For example, Debian and Ubuntu commonly use:
/var/log/auth.log
while RHEL-based systems use:
/var/log/secure
During the analysis, it is important to correlate the time of a suspicious login with the time when the unknown process appeared.

12. Checking Files for Changes

If you know which system files should be present on the server, you can check their integrity using the appropriate tools for your distribution.
It is also useful to find recently modified files in system directories:
find /etc /usr/bin /usr/sbin -type f -mtime -3 -ls

However, the results of such a search require manual analysis because package updates can also modify system files.

13. Using Antivirus and Specialized Tools

For an additional check, you can use tools such as ClamAV and rkhunter.
For example, after installing ClamAV, you can run a scan:
clamscan -r /path/to/check
However, an antivirus scan does not guarantee that the server is secure. A clean scan does not rule out a compromise, especially if an attacker is using custom scripts or modified system components.
Therefore, automated scanners should be used as an additional tool, not as the only method of diagnosis.

14. How to Distinguish a Malicious Process from a Legitimate One

Not every unknown process is malicious.
Before terminating a process, determine:

1. What is the process called?
2. Which user started it?
3. Where is the executable file located?
4. What is the parent process?
5. Which arguments were passed when it was started?
6. Which files does the process use?
7. Which network connections does it establish?
8. How is the process started after a reboot?

For example, a process with high CPU usage may turn out to be a normal PHP script, database process, or backup task.

15. What to Do When a Suspicious Process Is Found

It is not recommended to immediately run:
kill -9 PID
First, save information about the process for further analysis:
ps auxww
readlink -f /proc/PID/exe
tr '\0' ' ' < /proc/PID/cmdline
ss -tpn
Then determine how the process is started and check whether another component of the malware remains on the server.
If there are reasons to believe that the server has been compromised, the safest option may be to reinstall the operating system from a trusted source and restore only verified data.
Simply removing one process does not guarantee that the compromise has been eliminated.

How to Prevent Malicious Processes

To reduce the risk of server compromise, it is recommended to:

• regularly install security updates;
• use SSH keys instead of passwords;
• disable unnecessary services;
• restrict access to administrative ports using a firewall;
• follow the principle of least privilege;
• avoid running applications as root unless necessary;
• monitor installed packages and services;
• regularly review SSH access;
• monitor CPU, RAM, disk, and network traffic;
• store backups separately from the server.

Conclusion

Checking a Linux server for malicious processes is not simply a matter of running an antivirus scan. First, you need to determine which processes are running on the server, which resources they are using, and which network connections they establish. Then, you should check users, SSH keys, cron jobs, systemd services, and system logs.
High CPU usage alone is not proof of an infection. What matters more is a combination of indicators: an unknown process, a suspicious file location, unusual network connections, an unknown mechanism for automatic execution, and unauthorized access to the server.