In short: You recognize suspicious processes on Linux servers by a few features: program file deleted or located in /tmp, /dev/shm or a web directory, a name that imitates a system process, an unusual user, persistent network connections or high load for no reason. Use read-only commands to check whether the program file belongs to an installed package, and secure your findings before you terminate anything.
What "suspicious" means for a process
Hundreds of processes run on a web server. Most belong to the operating system, the web server, the database or PHP. An attacker who was able to execute code through a vulnerability such as PHP2Shell tries not to stand out among them. He chooses inconspicuous names and places programs where the web server user may write.
For the check, it helps to know the normal state. Whoever knows which services should run on a server, under which users and with what load, spots deviations much faster. If this knowledge is missing, it is worth using the process list of a comparable, unsuspicious server for comparison.
A single feature is not yet proof. What matters is the combination. A process with the name of a kernel thread that runs under www-data, was started from /dev/shm and holds a connection abroad is a clear case. How to check the special case of a shell under the web server is described in Warning sign: the web server starts a shell.
A first overview in five commands
All commands only read. Run them as root so that you see all processes, and save the outputs in a file outside the web directory.
# 1. All processes with user, parent PID, start time, CPU and command line
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Processes whose program file was deleted
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Processes running from temporary or web directories
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Processes with network connections
ss -tunap
# 5. Overview of the processes of the web server users
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
User names differ by distribution and panel; Plesk and other panels often run PHP under the respective customer's user. Adjust the list to your environment.
Read the outputs with an eye on the start time. Processes that have been running since the server's last restart usually belong to the system. Processes that were started in the middle of the night or in the days after 17 October and fit no service deserve attention. Also compare the number of PHP processes with what your pool configuration allows; clearly more processes under a web server user are a hint.
Suspicious processes on Linux: typical features
| Feature | Why it stands out | Harmless explanation possible? |
|---|---|---|
| Program file "(deleted)" | Attackers delete files after the start | yes, after package updates until restart |
Start location /tmp, /dev/shm, upload folder |
anyone or the web server may write there | rarely |
Name in square brackets such as [kworker] |
imitates kernel threads | no, if a program file is behind it |
| Persistently high CPU load for no reason | typical for crypto miners | yes, for batch jobs or indexing |
| Parent process 1 and web server user | detached from the web server, keeps running on its own | rarely |
| Connection to an unknown destination | control or data exfiltration | yes, for updates and APIs |
Real kernel threads have no program file; ls -l /proc/PID/exe returns no path for them. If a process with a kernel name points to a file, it is disguised. For high load with no apparent reason, the article Crypto miners on the web server helps further.
Cross-check: does the program file belong to a package?
Almost all legitimate programs on a server come from the package manager. A program file that belongs to no package is not automatically malicious, but deserves a close look.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: which package does the file belong to?
rpm -qf "$EXE" # RHEL family
sha256sum /proc/$PID/exe # checksum, also works for a deleted file
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # environment variables
If the program file is deleted, sha256sum /proc/$PID/exe still reads it from the running process. This checksum belongs in the documentation. A copy of the file should be made only by someone who knows how to store it safely.
Limits of checking on the running system
All commands above trust the system you are checking. In an ordinary break-in through the website with the web server user's rights, that is defensible. If an attacker has gained root rights, he can hide processes and falsify outputs. The server then shows only what the attacker allows.
Hints of this are contradictions: load without a visible process, connections that the firewall sees but ss does not, or modified system programs. In such cases the check belongs on a secured image. On running systems, a backup of the memory is often added, because some malware exists only there and leaves hardly any traces on the disk. This backup must be made before a restart and requires suitable tools and experience. Why you should create it before a reinstall is explained in Securing evidence before you reinstall.
Do not terminate suspicious processes as a first step. A cron job or a service often restarts them, and with the process, the command line, connections and the deleted program file disappear from memory.
Checking autostarts and next steps
A malicious process that would disappear after a restart would be worthless to attackers. So every process finding comes with the question of what starts it. Besides cron jobs, systemd services in particular come into question, which an attacker with root rights can create. Services with generic names whose program file sits in an unusual directory, and unit files created after 17 October, stand out.
# Running services and recently changed unit files
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Is a library injected into every process? The file normally does not exist.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
An entry in /etc/ld.so.preload is rare on normal web servers and a strong indication of manipulation with root rights. How to check scheduled tasks completely is described in Detecting hidden cron jobs as a backdoor.
The next steps then follow in this order:
- Secure outputs and checksums with the time.
- Look for persistence: cron jobs, systemd services and timers, SSH keys.
- Clarify the origin: logs from 20 October, new files in the web directory.
- Isolate the server and plan cleanup or rebuild.
An overview of all typical signs after PHP2Shell is given in Am I already compromised?.
How does PHP SOS help?
- Assess processes: We check the process list, program files and connections and classify every finding.
- Secure it in a court-proof way: With IT forensics, we secure memory and storage media before anything is changed.
- Find persistence: We search for mechanisms that restart malicious processes.
- Close out: We clean up or rebuild and document the incident through to its close.
Frequently asked questions
How do I recognize a suspicious process on Linux?
Typical features are a deleted program file, a start location in /tmp or /dev/shm, a name that imitates a system process, an unusual user and persistent network connections. Individual features are hints; several together are a serious suspicion.
What does "(deleted)" mean at /proc/PID/exe?
The process's program file was deleted after the start. That legitimately happens after package updates until the service restarts. For processes from temporary folders or under the web server user, it is typical camouflage behavior.
Can I rely on the output of ps?
In an ordinary break-in, usually yes. But if an attacker has gained root rights, he can manipulate tools and outputs. Then a check from outside, for example on a secured image, is more reliable.
Should I terminate a suspicious process with kill?
Not as the first step. First secure command line, program file, connections and start time. A terminated process reveals nothing any more, and a cron job or service often restarts it anyway.