Hacked server? The first hour of incident response

Updated November 2026

If a server has been broken into, the safe sequence is: cut it off, keep the evidence, change every secret it held, and build a new server from a clean source. Patching the hole and carrying on is not enough, because the attacker has probably left a way back in (persistence).

0–15 min 15–60 min Day 1 Week 1 Isolate Do not reboot Start notes Snapshot disk Save logs, state Work out scope Rotate secrets Rebuild clean Report Restore data Watch closely Lessons learned
A rough timeline for a single hacked server. Larger incidents take longer, but the order stays the same.

Minutes 0–15: isolate

First, stop the damage spreading and stop the attacker working on the machine, without destroying what is in memory.

Not sure it is really a break-in? Run the checks in signs your server has been hacked first, but keep them short.

Minutes 15–60: preserve evidence

CISA’s joint advisory on incident response lists “mitigating the affected systems before responders can protect and recover data” as a common mistake, because it loses memory contents and other host data. Collect first, then fix.

  1. Snapshot the disk through your cloud or hosting control panel. It is fast, does not touch the running system, and lets you examine the disk later from a clean machine.
  2. Memory. Some providers can capture a VM’s memory or suspend it to disk; for physical servers you need a memory capture tool. If neither is ready, skip this step rather than improvise: the disk snapshot matters more.
  3. Record the live state, then copy it off the server:
# as root; saves running state into one folder
mkdir -p /root/ir && cd /root/ir
date -u > time.txt
ps auxwwf > ps.txt
ss -tanp > ss.txt
who > who.txt
journalctl --since "14 days ago" -o short-iso > journal.txt
tar czf varlog.tar.gz /var/log
sha256sum * > SHA256SUMS

Copy the folder to your workstation with scp or the provider’s file tools. Do not log in from the server to other machines: keys and passwords used there may be captured.

Then work out the scope: which passwords, keys and tokens were on this server, and which other systems trust it (database servers, backups, deploy keys, cloud API keys). Those systems may be next (lateral movement).

Why not just patch and carry on?

Patching closes the door the attacker came through. It does not remove what they did after they came in: extra SSH keys, new accounts, cron jobs, changed binaries, a kernel rootkit. You cannot prove a cleaned server is clean, because the tools you would check it with run on the same compromised system. CISA lists “only fixing the symptoms, not the root cause” as another common mistake. Unless the intrusion was clearly limited (for example, one web shell running as www-data with no sign of root access, confirmed by someone experienced), plan to rebuild.

Day 1: rotate, rebuild, report

Rotate every secret, all at once

Change credentials from a clean computer, and do it in one go after the server is isolated. Changing them one at a time while the attacker still has access only shows them what you are doing.

More detail in compromised credentials.

Rebuild from a clean source

  1. Create a new server from the vendor’s official image or installation media, not from a snapshot of the hacked one.
  2. Install all security updates before it goes on the network (see patch fast).
  3. Fix the way in: the unpatched software, weak password or exposed service. If you do not know how they got in, look at the evidence before you go live, or the same thing will happen again.
  4. Configure it from your configuration management or written notes. Do not copy binaries, crontabs, home directories or /etc wholesale from the old server.
  5. Harden it: server hardening and SSH hardening.

Report

Who you must tell depends on your country, sector and contracts. In general terms:

Hosting provider
Tell them, especially if your server attacked others or sent spam. They may already have sent you an abuse complaint.
National CERT or CSIRT
Most countries have one that accepts reports, often voluntarily. In the US, CISA takes reports at cisa.gov/report, and individual cybercrime can be reported to the FBI’s IC3. In the UK it is the NCSC; in EU countries, the national CSIRT. Some sectors have mandatory reporting rules.
Data protection authority
If personal data may have been accessed, data protection law may require a report. Under the EU GDPR, a notifiable breach must be reported to the supervisory authority within 72 hours of becoming aware of it, and affected people must be told without undue delay when the risk to them is high. Other countries have their own rules; get legal advice. See data breach.
Customers and police
Contracts may require you to notify customers. For crime such as extortion, contact the police.

Get help when it is big. If personal data, money or many systems are involved, or you have cyber insurance, bring in a professional incident response firm early. Insurers often have conditions about who you may use and when you must tell them.

Week 1: restore and learn

Restore data, carefully

Restore databases and uploaded files from a backup taken before the break-in, if you can tell when that was. Check restored web directories for scripts in upload folders and unknown files before they go live. Content changed since that backup has to be re-entered or checked by hand. Step-by-step: restore from backup.

Watch closely

For the next weeks, watch the new server and everything that trusted the old one: logins, outbound connections, new files. Attackers sometimes come back with credentials you missed. Login alerts and off-server logs make this easier.

Lessons learned

Hold a short, blame-free review within a couple of weeks. Ask: how did they get in, how long were they there, how did we find out, and what would have stopped or caught it sooner? NIST SP 800-61 Rev. 3 (April 2025) feeds lessons learned into continuous improvement and says they should often be shared as soon as they are found, not held back until recovery ends. Turn the answers into concrete changes, such as faster patching, automatic updates, file integrity monitoring or tested backups.

Sources