← Back to Blog

Incident Response · 10 min read · June 22, 2026

Is My Server Hacked? How to Check for Signs of Compromise in 2026

That moment of dread when something feels wrong with your server. Unusual CPU spikes, strange network traffic, a file you don't recognise. Here is exactly how to investigate — step by step, using commands you already have.

The 7-Minute Compromise Check

Run these checks in order. Each one takes under a minute. If any of them raises a red flag, proceed to the deep investigation section below.

1. Check who is logged in right now

who -a
last -10

Look for unexpected usernames or IP addresses you don't recognise. If you see a user logged in from a foreign country and it is not you, that is a compromise signal. last shows login history for the past days or weeks.

2. Look for suspicious processes

ps aux --sort=-%cpu | head -20

Look for processes consuming abnormal amounts of CPU or memory. Common malicious processes are named to look legitimate — sysupdate, mysql-safe, httpd-worker — but run from unexpected directories like /tmp, /dev/shm, or /var/tmp.

Anything running from /tmp with high CPU usage is almost certainly malware.

3. Check active network connections

ss -tunap | grep ESTAB

This shows all established TCP and UDP connections. Look for connections to IP addresses in countries where you have no business. Outbound connections to unfamiliar IPs on ports 443, 8443, or 8080 are common for command-and-control (C2) traffic.

If you see a process you don't recognise calling out to a remote IP, investigate immediately.

4. Check for unauthorised user accounts

cat /etc/passwd | grep -E '/bin/(bash|sh|zsh)$'
cat /etc/sudoers | grep -v '^#' | grep -v '^$'

Look for user accounts you did not create. Hackers often add a backdoor user with sudo access. Pay special attention to recently created accounts — check with ls -la /etc/passwd to see when the file was last modified.

5. Check for suspicious cron jobs

crontab -l
ls -la /etc/cron*
cat /etc/crontab

Attackers frequently install persistence via cron jobs that download and execute payloads. Look for anything downloading files with wget or curl, running scripts from /tmp, or executing encoded commands.

6. Check for unauthorised SSH keys

cat ~/.ssh/authorized_keys
ls -la /home/*/.ssh/authorized_keys 2>/dev/null

Hackers add their own SSH keys to maintain persistent access even after passwords are changed. If you see a key you did not install, your server has a backdoor.

7. Check for recently modified files

find /bin /sbin /usr/bin /usr/sbin -mtime -7 -ls
find /etc -name '*.conf' -mtime -3 -ls

Unexpected modifications to system binaries or configuration files are a strong indicator of compromise. Attackers replace common commands like ps, netstat, or ls with trojaned versions that hide their activity.

Deep Investigation — If You Found Something

If any of the quick checks above raised a flag, here is how to dig deeper.

Check for rootkits

# Check if common system commands have been replaced
dpkg --verify 2>/dev/null || rpm -Va 2>/dev/null

# Look for hidden kernel modules
lsmod | grep -E 'hide|rootkit|backdoor'

# Check for LD_PRELOAD tricks
cat /etc/ld.so.preload 2>/dev/null
cat /etc/ld.so.conf 2>/dev/null

Rootkits are the most dangerous type of infection. They hide processes, files, and network connections from standard system tools. If dpkg --verify shows modified system files, you are likely dealing with a rootkit.

Dump the firewall and look for port forwards

iptables -L -n -v
iptables -t nat -L -n -v

Attackers often add iptables rules to forward traffic or hide their connections. Unexpected NAT rules that redirect traffic to internal IPs are a red flag.

Check for hidden processes

# Compare /proc listing with ps output
ls /proc | grep -E '^[0-9]+$' | sort -n

If you see process IDs in /proc that do not appear in ps output, a rootkit is hiding them.

Scan for malware binaries

# Check common hiding spots
ls -la /tmp /var/tmp /dev/shm /var/spool
find / -name '*.sh' -newer /etc/passwd -type f 2>/dev/null | head -20

# Look for base64-encoded scripts in unexpected places
find /var /tmp -name '*.pl' -o -name '*.py' -o -name '*.rb' 2>/dev/null | head -20

Malware binaries often hide in world-writable directories. Any executable script in /tmp or /dev/shm that is older than a few minutes is suspicious.

What to Do If You Confirm a Breach

If the evidence points to a compromise, follow these steps in order:

1. Isolate the server. Disconnect it from the network or apply a restrictive firewall rule to block all traffic except your SSH IP.
2. Take a snapshot. Before making any changes, dump running processes, network connections, and memory. lsof -i and cat /proc/[pid]/maps are your friends.
3. Change all credentials. Root password, database passwords, API keys, and any service tokens used by the server.
4. Remove backdoor access. Delete unauthorised SSH keys, remove unknown user accounts, and kill suspicious cron jobs.
5. Scan the full system. Run ClamAV or a similar scanner to identify known malware binaries.
6. Audit logs. Check /var/log/auth.log, /var/log/syslog, and application logs to trace the entry point.
7. Patch the vulnerability. The attacker got in through a specific exploit. Find it and close it — outdated software, weak SSH password, exposed database, or vulnerable web app.

Why Manual Checks Are Not Enough

The checks above are a solid starting point, but they have limits:

• Sophisticated rootkits subvert the very commands you are using to investigate. They make ps, ss, and ls lie to you.
• Timing matters. A hacker's AI agent can be in and out in under 90 seconds. By the time you run your manual checks, the evidence may already be gone.
• False negatives. Human inspection misses things. Automated behavioural analysis catches anomalies that a tired sysadmin scrolling through logs at 3 AM will never see.

This is why automated 24/7 monitoring is the only reliable defense. A real-time detection system watches every process, connection, and file change continuously — and alerts you the moment something looks wrong, not hours later when you happen to check.

The Bottom Line

Most server compromises are discovered by accident — a user reports slowness, a billing alert goes off for unusual traffic, or a friend says "your site is serving malware." By the time someone notices, the attacker has had free rein for days or weeks.

The commands in this guide will help you investigate when something feels off. But the real answer to "is my server hacked?" should come from an automated system that never sleeps, never gets distracted, and catches the breach in seconds — not days.