Short answer. Isolate the site: enable maintenance mode and cut off the attacker's access. Rotate every credential — hosting panel, SSH, database, CMS. Preserve a copy of the logs and a server snapshot before any cleanup. Find the entry point and the infected files, restore from a clean backup, and close the vulnerability. The minute-by-minute plan is below.
The first hour decides how the incident ends: a quick cleanup by the evening, or weeks of back-and-forth with your host and search engines. Panic does more damage than the hack itself — files deleted "just in case" take the traces of the entry point with them. And make sure it really is a hack: if the site simply went down under a flood of traffic while the files and admin panel are untouched, that is a different incident with a different plan — see DDoS attack: what to do in the first hour.
How to tell your website has been hacked
A hack rarely announces itself directly — more often it shows up through indirect signs.
| Sign | What it means | How to check |
|---|---|---|
| Redirects to third-party sites | Malicious JavaScript injected into the code | Open the site in incognito and from a phone; run the malware check |
| New administrator accounts | The attacker has persistence in the CMS | User list in the admin panel: dates, roles |
| Modified or new files | A web shell or injected code | find by modification date; diff against the repository |
| Spam sent from your domain | The mail script or server is compromised | Mail queue, DMARC reports, blacklists |
| Browser or search engine warning | The site is flagged by Safe Browsing | Google Search Console, Security Issues |
| Spike in outbound traffic | Spam, attacks, or data exfiltration | Traffic graphs at your host; ss, netstat |
| Unknown processes and cron jobs | The malware reinstalls itself | crontab -l, ps aux |
| The site suddenly slowed down | A cryptominer is eating CPU | Server load, error logs |
A detailed breakdown of infection signs is in our guide to checking a website for malware; for a quick external look, run the malware scanner and the security scanner.
The first 60 minutes: a step-by-step plan
0–10 minutes: isolate the site
Stop the harm to visitors and take away the attacker's access without destroying the traces. Enable maintenance mode or close the site in the hosting panel, serve a stub page with a 503 status code, and restrict the admin panel and SSH to your own IP address. What you must not do: delete suspicious files, clear logs, or reinstall the CMS from scratch — that destroys the evidence you will need to find the entry point.
Do not wipe a hacked site right away. First a copy of the logs and a snapshot of the files, then everything else. Skip this step and you will not find the entry point — which means you will be hacked again the same way.
10–20 minutes: rotate every credential
Assume everything is compromised: the hosting panel password, SSH, the database user, CMS administrators, FTP, API keys. Rotate everything at once, starting with the hosting panel — it controls the rest. Then remove anything foreign: unknown CMS administrators, unfamiliar keys in ~/.ssh/authorized_keys, new database users, fresh access tokens.
20–30 minutes: preserve the evidence
Before any cleanup, capture the state of the system: a server snapshot or an archive of the site directory preserving file dates, plus copies of the web server logs (access and error), the authentication journal, and FTP logs for the last two to four weeks — stored on your local machine, out of the attacker's reach. Ten minutes now saves days later: the logs let you reconstruct when the attacker arrived and what they managed to do.
30–45 minutes: find the entry point and the infection
Now look for what changed. Start with files modified in the last few days:
# files modified in the last 3 days find /var/www -type f -mtime -3 -not -path "*/cache/*" -ls
Then search PHP files for typical web shell signatures:
# web shell hunt by common constructs
grep -rn --include="*.php" -e "base64_decode" -e "eval(" -e "gzinflate" /var/www
Check the scheduler — malware often plants a job that reinstalls it after removal:
# current user's cron and system jobs crontab -l ls -la /etc/cron.d/ /etc/cron.hourly/
And review recent server logins:
# login history and successful SSH authentications last -a | head -20 grep "Accepted" /var/log/auth.log | tail -20
Cross-reference every suspicious file with the web server logs: the first request to a web shell usually points straight at the entry point — a vulnerable plugin, an upload form, or a guessed password.
45–60 minutes: clean up or roll back
By the end of the hour, make the call. If you have a backup made verifiably before the hack and you know the compromise date — roll back: it is faster and more reliable than manual cleaning. If there is no clean backup, remove the infection by hand: web shells, modified core files, injected code in the database.
Restoring from a backup without closing the hole is a pause, not a fix. The vulnerability that let the attacker in the first time is still there in the restored copy, and a repeat hack is a matter of a day or two.
How websites get hacked most often
Vulnerable CMS plugins and themes. The most common vector by far: bots start exploiting a known hole in a popular plugin within hours of disclosure. Abandoned plugins and "nulled" themes with built-in backdoors belong here too.
Weak passwords and no 2FA. Password guessing against admin panels and SSH runs around the clock on every site; a password from a leaked database or "admin123" falls within minutes.
Outdated software. An old CMS core, PHP without security patches, forgotten libraries: botnet scanners methodically sweep the entire internet, and they will reach your server too.
An infected developer machine. Infostealers grab saved FTP and SSH passwords — the site is then "hacked" with perfectly valid credentials, without a single vulnerability on the server.
SQL injection and custom code. Homegrown forms and integrations without parameterized queries or input validation. Less frequent than plugin exploits, but with heavier consequences — up to a full database dump.
Recovery and hardening afterwards
Do not reopen the site immediately — first close what let the attacker in and carry every fix over into the restored copy. Update everything: CMS core, plugins, themes, PHP; remove unused plugins entirely. Rotate CMS keys and salts — in WordPress these are the secret keys in wp-config.php, and changing them invalidates the attacker's sessions. Reissue the SSL certificate if the private key lived on the compromised server — verify the new configuration with the SSL checker.
Scan the site from the outside: run the domain through the malware scanner and the security scanner — the latter will also show which security headers are missing, with a detailed walkthrough in our complete guide to security headers.
If the site was flagged as dangerous, request a review after the cleanup in Google Search Console under Security Issues. While you are at it, make sure the domain has not ended up in fraud databases — we covered how to check that in the article on checking a website for fraud.
The first weeks after an incident are prime time for repeat attempts: the attacker knows your site and will come back to see whether the hole is closed. Continuous monitoring of uptime, the SSL certificate, and malware reappearance is a sensible minimum after a hack — the pricing page shows how that works in enterno.io.
If personal data has leaked
If the site stored user data — accounts, orders, contact forms — and there is reason to believe it was accessed, data protection rules in most jurisdictions require notifying the regulator. Under the GDPR, the supervisory authority must be notified within 72 hours of becoming aware of the breach, and affected users informed without undue delay when the risk to them is high. Check the exact requirements of your jurisdiction and document the incident timeline as you go: the log copies from the first hour become the core of that report.
FAQ
Can I just delete the virus and move on?
No. Deleting the file removes a symptom, not the cause: while the entry point stays open, the infection will return, often the same day. Malware also almost always has duplicates — a second shell, a cron job, code in the database.
How soon will the site return to search after a warning label?
After a review request, Google usually lifts the Safe Browsing flag within one to three days. The condition is that the site is genuinely clean: every failed review makes the next one take longer. Rankings recover more slowly — from a week to a month.
Do I need to tell my users?
If their data may have been affected — yes, and sooner rather than later. An honest notice with a forced password reset costs far less reputation than users learning about the breach from a browser warning. If payment data is involved, notify your payment provider as well.
How do I know the hole is actually closed?
You have found the specific request in the logs that got the attacker in and removed its cause: updated the vulnerable component, disabled the flawed upload form, changed the stolen password. If the entry point was never found, treat the hole as open: harden everything at once and watch for new file changes.
What if there is no clean backup?
Clean manually: a fresh CMS distribution over the infected core, a review of upload directories for executable files, a search for injected code in the database. It is slow — so right after recovery, set up regular backups stored off the server.
Checklist: the first hour after a hack
- Enable maintenance mode and close the site to visitors
- Restrict the admin panel and SSH to your own IP address
- Rotate all credentials: hosting, SSH, database, CMS, FTP, API keys
- Remove foreign administrators and unfamiliar SSH keys
- Take a server snapshot and copy the logs to a safe place
- Find modified files and web shells (find, grep)
- Check cron, running processes, and the server login history
- Identify the entry point from the web server logs
- Roll back to a clean backup or remove the infection manually
- Close the vulnerability, update everything, enable monitoring