Server monitoring: what CPU, RAM and disk reveal about an intrusion
CPU, memory and disk are usually monitored to avoid outages. The same indicators are also one of the most reliable ways to spot an intrusion, including ones an antivirus does not detect.
The most common case: the crypto miner
Once inside, an attacker often wants to make money from your server. The simplest way is to install a crypto miner. The signs:
- sustained high CPU, often near 100% on all cores, even at night;
- a harmless-looking process name (
kworker,systemd-helper, a random string) started from/tmp,/dev/shmor a hidden directory; - permanent outbound connections to unusual ports;
- a scheduled task that restarts the process when it is killed.
A recent miner may not be in signature databases. Its CPU usage, however, is impossible to hide.
The signals to watch
| Indicator | What should alert you | Possible cause |
|---|---|---|
| CPU | Unusual high plateau, especially outside business hours | Miner, application loop, attack |
| Memory | Steady growth until the kernel kills processes (OOM) | Memory leak, malicious process |
| Disk | Sudden filling | Logs exploding under attack, staged exfiltration, stuck backup |
| Processes | Unknown name in top CPU or memory | Malware, tool installed by a third party |
| Services | Critical service stopped or failed | Crash, sabotage, failed update |
| Ports | New listening port | Backdoor, service exposed by mistake |
Establish a baseline
An indicator only makes sense compared with normal. For each server, note:
- usual CPU load during the day and at night;
- the 5 processes that normally use the most CPU and memory;
- the expected listening ports;
- disk usage and its weekly growth.
An anomaly is a deviation from that baseline. Comparing each day with the previous one is often enough to catch what changes.
A few useful commands
Most resource-hungry processes:
ps -eo pid,user,%cpu,%mem,comm --sort=-%cpu | head
Listening ports and their processes:
sudo ss -tlnp
Failed services:
systemctl --failed
Processes killed for lack of memory:
sudo journalctl -k --since "24 hours ago" | grep -i "out of memory"
What to do when something looks wrong
- Identify the process: executable path (
ls -l /proc/PID/exe), user, start time. - Do not kill it right away if you suspect an intrusion: note its connections (
ss -tp) and look for its restart mechanism (crontab, systemd service). - Find the entry point: recent successful SSH logins, vulnerable application, uploaded file.
- Rebuild from a clean source and rotate exposed secrets.
Frequently asked questions
Does a CPU spike mean an attack?
No, most spikes are legitimate: deployment, scheduled task, traffic. An unexplained plateau, especially at night, is what should alert you.
Do I need a dedicated monitoring tool?
Classic monitoring tools show graphs. What is often missing is the interpretation: knowing whether a process is normal and whether the trend is worrying.
FondateurMode records CPU, memory, disk, processes and services every day, compares them with the previous day, and the AI explains what is normal and what is not. Try it free for 14 days.