Detect a server intrusion

A compromise is not always visible. The site may answer normally while a process reads your files or sends spam from your IPv6 address. Detection is not about understanding everything at once, but about observing, containing and preserving evidence before deciding.

Before touching the machine

Record the time, the symptoms and recent changes. If the compromise is active, cut exposure (firewall, stop the web service) rather than the machine: a reboot wipes memory and a reinstall destroys evidence. If the dashboard offers a snapshot, take it before any change.

Copy logs elsewhere as soon as possible. A root attacker can alter them locally; an exported copy remains usable evidence.

Accounts and access

getent passwd | awk -F: '$3==0 {print $1}'
last -a | head -30
lastlog
sudo grep -r . /etc/sudoers /etc/sudoers.d
sudo find /root /home -name authorized_keys -exec ls -l {} \;

The first command lists accounts with UID 0: only root should appear. last and lastlog show recent logins, including those outside your usual hours. Check authorized keys, added sudoers entries and modified shells.

Processes, network and persistence

ps auxf
sudo ss -tulpn
sudo ss -tnp state established

Look for a plausible process name in an unusual path, a deleted binary still running (ls -l /proc/PID/exe shows (deleted)) or an outbound connection to an unknown address. Persistent attackers often add a cron job, a systemd timer or a service:

crontab -l
sudo ls -l /etc/cron.*
systemctl list-timers --all
systemctl list-unit-files --state=enabled
cat /etc/ld.so.preload

On a web server, look for recent files in upload directories and obfuscated calls: find /var/www -type f -mtime -7 -ls. A .php file dropped in an images folder is a strong signal.

Logs and inspection tools

journalctl --since "2026-11-01" -p warning
journalctl -u ssh --since today | grep -E "Accepted|Failed"

Nginx and PHP logs reveal repeated POST requests to the same script, remote file inclusions and encoded strings. Once installed, debsums -c and dpkg -V report modified system binaries; rkhunter --check and lynis audit system complete the inventory, but they cannot guarantee a compromised machine is clean: a rootkit can falsify their results.

Decide and rebuild

If only one site is affected and the entry point is identified, clean the files, update the application and change secrets. If the attacker obtained root, the only reliable answer is a reinstall from the dashboard. Restore only verified data, never binaries or configurations, then rotate every password, SSH key and token.

After rebuilding, check:

• UID 0 accounts and authorized keys;
• listening ports with ss -tulpn;
• scheduled tasks and systemd units;
• logs from the first days.

A fast reinfection points to a forgotten entry point, often a backup restored too quickly.