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
- Don't reboot or power off. Volatile evidence - running processes, open network connections, in-memory artifacts - disappears the moment the machine restarts. If you need this evidence for a proper investigation (and for POPIA breach assessment, you likely do), rebooting destroys it.
- Isolate, don't shut down. Disconnect the server from the network (pull the cable, or apply a firewall rule blocking all traffic) rather than powering it off. This stops an active attacker without losing volatile data.
- Don't "clean up" by hand. Deleting the suspicious process, the strange cron job, or the unfamiliar user account might feel productive, but it destroys the evidence trail needed to understand how the attacker got in - which means you can't be confident you've actually closed the gap.
- Capture what you can, carefully. If you have the expertise, a memory capture and a list of running processes/connections before isolating is valuable. If you don't, this is exactly the point to bring in someone who does.
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.
