Sign 1: Unexpected processes or resource spikes

A server that's suddenly running hot for no obvious reason - high CPU from a process you don't recognise, disk I/O that doesn't match your usual workload, or a process running under a user account that shouldn't be doing anything - is one of the most common tells. Cryptomining malware in particular is often caught this way, since it's relentlessly CPU-hungry and not especially good at hiding from top or htop.

Sign 2: Unfamiliar user accounts or SSH keys

Check /etc/passwd for accounts you didn't create, and check ~/.ssh/authorized_keys for every user on the box - not just root - for keys nobody on your team recognises. Attackers who gain initial access frequently add a persistence mechanism immediately, precisely so they can get back in even after the original vulnerability is patched.

Sign 3: Modified or missing log files

Gaps in /var/log/auth.log or /var/log/syslog, timestamps that don't line up, or logs that have clearly been truncated are a strong signal - attackers who know what they're doing will try to cover their tracks by editing or deleting log entries that show how they got in. A file integrity monitoring tool (Wazuh's FIM module, for example) will flag this automatically; without one, it usually only gets noticed when someone goes looking after the fact.

Sign 4: Outbound connections to unfamiliar destinations

A web server that's suddenly making outbound connections it has no business making - to IP ranges you don't recognise, on ports you don't use - is a classic sign of command-and-control traffic or data exfiltration in progress. netstat -tulpn or ss -tulpn will show current connections; comparing against a known-good baseline is what makes this actually useful rather than just noisy.

Sign 5: Cron jobs or startup scripts you didn't create

Check crontab -l for every user, plus /etc/cron.d/, systemd timers, and anything referenced in rc.local or systemd service files. Malware that survives a reboot usually does so via one of these mechanisms - it's a cheap, reliable way for an attacker to re-establish themselves even if you kill the running process.

If you're reading this because you've spotted one of these right now: stop making changes to the server. Don't reboot it, don't kill the suspicious process yet, and don't start "cleaning up" by hand. The next section explains why.

What to do in the first hour

"The instinct to immediately start fixing things is natural - and it's exactly what destroys the evidence you'd need to know whether you've actually fixed anything."

Why "just wipe and reinstall" is the wrong first move

Wiping and reinstalling feels decisive, but without first understanding how the attacker got in, you risk reinstalling the exact same vulnerability. We've seen businesses wipe a compromised server, restore from backup, and get compromised again within days via the same unpatched service or leaked credential - because nobody established root cause before rebuilding. A proper investigation first, then remediation, is slower but it's the difference between actually fixing the problem and just resetting the clock on it.

The bottom line

None of these five signs are individually damning - servers do unusual things for benign reasons sometimes. But two or more together, or any of them on a server holding sensitive data, warrants a proper look before you touch anything else on the box.

Seeing one of these signs right now?

Don't reboot. Contact us before you take any remediation steps, so we can help preserve what's needed for a proper investigation.

See Our Forensics Service →