The first reflex on spotting an unknown process is to power the server off and clean it up. Both are mistakes: shutting down destroys evidence held in memory, and cleaning almost always leaves a door open. Handle an incident in order, not in a hurry.
Typical signs: an innocuously named process eating CPU, outbound connections to unknown addresses, a new entry in crontab or authorized_keys, recently modified system files, a user account you did not create, missing logs. Do not power the server off, because memory holds the running processes, the connections and sometimes the intruder's keys. Isolate it instead: default deny on inbound and outbound traffic, with one exception for the address you investigate from.
Copy the disk and compute a checksum; save the output of ps, ss and last along with copies of the logs. Only then rotate every secret, not just the one you think the intruder used: database passwords, API keys, CI tokens, certificates. Put the application back on a freshly installed server from a backup taken before the first trace of compromise, after patching the flaw that was used. Analyse the old server, then reinstall it.
If your company is an essential or important entity under OUG 155/2024 (the NIS2 transposition approved by Law 124/2025), report a significant incident to DNSC with an early warning in 24 hours, a notification in 72 hours and a final report a month later. If personal data is affected and individuals are at risk, notify ANSPDCP within 72 hours of becoming aware (GDPR Article 33) and tell the individuals when the risk is high (Article 34). File the criminal complaint with the police or prosecutor: illegal access, Article 360 of the Criminal Code, goes to the ordinary prosecutor, while DIICOT takes only Articles 361–365 or organised groups.
| Who notifies | Whom | Deadline | Legal basis |
|---|---|---|---|
| Essential or important entity | DNSC, early warning | 24 hours from detection | OUG 155/2024 (NIS2) |
| Essential or important entity | DNSC, incident notification | 72 hours | OUG 155/2024 (NIS2) |
| Essential or important entity | DNSC, final report | one month after the 72-hour notification (or after the incident is handled) | OUG 155/2024, Article 15(7) |
| Any personal-data controller | ANSPDCP | 72 hours from becoming aware | GDPR Article 33 |
| Any controller, when the risk is high | Affected individuals | without undue delay | GDPR Article 34 |
| Any injured party | Police / prosecutor (DIICOT for Articles 361–365) | as soon as possible, to preserve evidence | Criminal Code, Articles 360–366 |
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable# Evidence is NOT written to the compromised machine: mount an external volume
# (mount /dev/sdb1 /mnt/evidence) or run the commands from your investigation host,
# for example: ssh root@server 'ps auxf --sort=-%cpu' > ps.txt
mount /dev/sdb1 /mnt/evidence && cd /mnt/evidence
ps auxf --sort=-%cpu > ps.txt
ss -tunap > connections.txt
last -aF > logins.txt
for u in $(cut -d: -f1 /etc/passwd); do echo "== $u"; crontab -l -u "$u" 2>/dev/null; done > cron.txt
find / -xdev -type f -newermt "$(date -d '-14 days' +%F)" > modified.txt
find / -xdev -name authorized_keys -print -exec cat {} \; > keys.txt
sha256sum * > SUMS.sha256A monitoring dashboard showed a web server sending traffic to an unknown address. The team blocked outbound traffic, snapshotted the disk, rotated the database and payment credentials, then relaunched the shop on a clean VPS from the last backup that predated the first suspicious log line.
Ransomware encrypted the invoicing server. The early warning reached DNSC the same day, the full notification within 72 hours and the final report three weeks later. Restoring from the offline backup took one day.
In practice, no. An attacker with root can replace binaries, kernel modules or systemd services with versions that look legitimate, and you cannot know what is left behind. Reinstalling from scratch and restoring the data is faster and the only real guarantee.
From centralised logs, if you have them: the first abnormal login, the first suspicious request in nginx, the first file change. On the affected server, file dates and cron entries give a hint, but they can be forged. The backup you restore must predate that date.
If their personal data was accessed and the risk to them is high, GDPR requires you to inform them directly and without delay. Even when it is not mandatory, a short and honest message costs less than the rumour, and you can leave out details that would help other attackers.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.