How to tell if your Linux server has been hacked: 10 warning signs

Most server compromises are not dramatic. There is no ransom note on the homepage. An attacker gets in, installs a cryptominer or a spam relay, adds a way back in, and stays quiet for weeks.

The good news: intrusions leave traces. Here are the ten signs worth checking, with the commands to run.

1. The CPU is busy and nobody knows why

A cryptominer is the most common payload on a hacked server. It shows up as a process using 90–100 % of the CPU around the clock, often with a harmless-looking name like kworkerds or [kthreadd].

top -o %CPU
ps aux --sort=-%cpu | head

Look for processes you don't recognise, running as www-data, nobody or a user that should be idle.

2. Unknown processes or binaries in /tmp

Attackers love world-writable folders. Executables in /tmp, /var/tmp or /dev/shm are a red flag.

ls -la /tmp /var/tmp /dev/shm
find /tmp /var/tmp /dev/shm -type f -perm -u+x

3. New users, or new sudo rights

grep -E ':0:' /etc/passwd          # any account with UID 0 other than root?
getent group sudo
ls -la /etc/sudoers.d/

A new account, or an existing one added to sudo, means someone planned to come back.

4. SSH keys you didn't add

This is the favourite backdoor: one extra line in authorized_keys.

cat ~/.ssh/authorized_keys
sudo find / -name authorized_keys 2>/dev/null

Compare every key with the people who should have access.

5. Cron jobs that re-download something

Persistence often lives in a scheduled task that fetches a script every few minutes.

crontab -l
sudo ls -la /etc/cron.* /var/spool/cron/crontabs/

Watch for curl or wget piped into sh, and for base64 blobs.

6. Successful logins you can't explain

Failed attempts are normal on the internet. A successful login from an unknown IP is not.

last -a | head -30
sudo grep "Accepted" /var/log/auth.log | tail -30

7. Outgoing connections to strange places

Miners talk to mining pools, bots talk to command servers.

sudo ss -tunap | grep ESTAB

Connections on ports like 3333, 4444, 5555 or 14444 deserve a closer look.

8. The disk fills up for no reason

Spam queues, stolen data waiting to be sent, or a log flooded by an attack. A sudden jump in disk usage is worth investigating.

df -h
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20

9. Modified system files

Changed binaries in /bin or /usr/bin, or a modified /etc/passwd, point to a rootkit or a deliberate backdoor. On Debian and Ubuntu you can check packaged files against their checksums:

sudo dpkg --verify

10. Your host or a blacklist tells you first

An abuse notice from your hosting provider, emails bouncing because your IP is blacklisted, or a warning in Google Search Console. When this happens, the intrusion is usually weeks old.

Found something? The first hour

1. Don't reboot. Memory and running processes are evidence.
2. Isolate: restrict the firewall to your own IP.
3. Rotate secrets: SSH keys, database passwords, API tokens.
4. Find the entry point: an outdated web framework, a weak password, an exposed admin panel.
5. Rebuild if in doubt. A server where root was compromised can't be fully trusted again.

Checking all this every day, automatically

Running these ten checks by hand once is useful. Running them every day is what actually catches an intrusion early.

That is what FounderMode does: it watches processes and CPU, sensitive files (accounts, sudo, SSH keys, cron), logins and vulnerable versions, and sends one clear report every morning on Slack or by email. Installation takes one command. Try it free for 14 days.