Server hacked? What to do, step by step

Finding out that a server has been broken into is stressful. Acting in the right order limits the damage: contain first, understand second, rebuild and recover third. This guide covers Linux servers in detail and adds notes for Windows.

Signs of a compromise

• Unknown processes using all CPU (often crypto miners), or unknown outgoing connections.
• New user accounts, SSH keys, cron jobs or services you did not create.
• Modified website files, injected scripts, spam pages or redirects.
• Abuse reports about spam, scanning or phishing from your IP address.
• Logins at odd times or from unknown addresses.

Step 1: Contain, but keep evidence

• Do not wipe anything yet. Evidence tells you how the attacker got in, so you can close the hole.
• Take a snapshot or backup of the current state if your plan offers it, clearly labelled as compromised.
• Cut the attacker off: restrict the firewall to your own IP address for SSH and block outgoing traffic you do not need. Use the web console if the network is restricted. See UFW firewall.
• Change your client area password and turn on two-factor authentication, from a computer you trust.

Step 2: Investigate

Log in and look around. Work read-only where you can.

Who logged in, and from where:

last -n 30
sudo journalctl -u ssh --since "14 days ago" | grep -E 'Accepted|session opened'

What runs and what listens:

ps auxf
sudo ss -tulpn
sudo ss -tnp state established

Persistence mechanisms:

sudo crontab -l
sudo ls -la /etc/cron.d /etc/cron.daily /var/spool/cron/crontabs
systemctl list-units --type=service --state=running
systemctl list-timers

Accounts and keys:

awk -F: '$3 == 0 {print $1}' /etc/passwd
awk -F: '$3 >= 1000 {print $1}' /etc/passwd
sudo cat /root/.ssh/authorized_keys
cat ~/.ssh/authorized_keys

The first awk line lists accounts with root rights (only root should appear); the second lists normal users.

Changed system files:

sudo dpkg --verify
sudo find /etc /usr/bin /usr/sbin -xdev -type f -mtime -7 -ls

dpkg --verify reports packaged files whose content differs from the package; changes in /usr/bin or /usr/sbin are a strong warning sign. For websites, look for recently changed PHP files and unknown files in upload folders.

Write down what you find, with times. It tells you the entry point: an outdated CMS plugin, a weak password, an exposed admin panel, a leaked key.

Step 3: Rebuild from a clean image

The safest path is a fresh installation:

1. Save the data you need (databases, uploads, configuration you understand) from the compromised server, and treat it as untrusted.
2. Reinstall the operating system: see reinstall the operating system.
3. Secure the new system before it goes online: secure a new Linux server.
4. Install current versions of your applications from trusted sources.
5. Restore data from a backup taken before the intrusion, or check saved data carefully (for example, no unknown PHP files in uploads, no new admin users in the database).

Step 4: Rotate every credential

Assume everything the server knew is known to the attacker:

• SSH keys and passwords of all users; create new keys on a clean computer.
• Database passwords and application secrets (for example in wp-config.php or .env files).
• API keys and tokens stored on the server, such as payment, mail or cloud credentials.
• Passwords of control panels, FTP and mail accounts.

Step 5: Close the hole and watch

Fix the entry point you found, then keep watching for a while: logins in the SSH log, unexpected processes and outgoing connections. Turn on automatic updates and consider Fail2ban or CrowdSec.

Windows servers

• Run a full and an offline scan with Microsoft Defender (the offline scan restarts the server):

Start-MpScan -ScanType FullScan
Start-MpWDOScan

• Check local accounts, scheduled tasks and connections:

Get-LocalUser
Get-ScheduledTask | Where-Object State -ne 'Disabled' | Select-Object TaskPath, TaskName
Get-NetTCPConnection -State Established

• Review sign-ins in the Security event log (event IDs 4624 and 4625). As on Linux, a reinstall is the safest recovery.

Abuse complaints and legal duties

If we contacted you about abuse from your server, reply on the ticket, explain the containment steps and keep us updated. If personal data may have been accessed, you may have to report the breach to a data protection authority and inform affected people, often within short deadlines. Ask a legal adviser.

Troubleshooting

The malicious process comes back after you kill it. A cron job, a systemd unit or a modified binary restarts it. That is a reason to rebuild rather than clean.

You cannot log in at all. The attacker may have changed passwords or keys. Use the web console if your service page shows one, or open a ticket.

The site is clean but gets infected again. The entry point is still open, often an outdated plugin or a reused password. Find it before you restore.

Next steps

• Start clean: reinstall the operating system.
• Be ready next time: backup strategy.
• Abuse reports explained: abuse FAQ.