Your Website Got Hacked — Now What? The Emergency Steps, in Order

When a website is hacked, the correct first moves are: (1) do not panic and do not delete anything yet, (2) take the site offline for visitors, (3) preserve the evidence, (4) rotate every credential from a clean device, (5) restore from a backup proven to be clean, (6) find the entry point before going live again. The order matters — the instinctive first move (deleting the defaced page) destroys exactly the trail you need to avoid getting hacked twice.

Why this keeps happening: Indonesia’s national cyber agency BSSN recorded 5.5 billion cyber attacks against Indonesia in 2025 alone, more than seven times the 2020–2024 annual average (Antara, 2026), and defacement (pages replaced or vandalized) is the most common outcome. Most victims are not large companies — they are small businesses whose only “IT team” is an external vendor.

The first 30 minutes: what to touch and what not to

Do not:

• Do not delete the attacker’s files or pages. The temptation is huge — that gambling page is right there, just remove it. Resist. Those files (with their creation dates) are evidence of the intrusion path, and often the only evidence.
• Do not reinstall the CMS or hosting. Same problem: you are mopping the crime scene before it has been examined.
• Do not pay a ransom note immediately if one appears — that decision needs assessment, not reflex.

Do now:

1. Isolate, don’t destroy. If possible, quarantine mode: site offline for visitors, server still running so logs and files stay intact. On shared hosting this usually means a “maintenance mode” toggle in the panel.
2. Screenshot everything: the replaced pages, the hacker message, unfamiliar files visible in the file manager — including their timestamps.
3. Write down the timeline as precisely as you can: when you last saw the site normal, when you found out.

The first hours: cut off the attacker’s access, from outside

The order matters because an attacker who still has access will re-seed themselves every time you clean.

1. Change passwords for the hosting account, cPanel/SSH, SFTP, databases, and every CMS admin account — from a clean device (not one that might be keylogged), unique password per service. Treat the old ones as already read by the attacker.
2. Revoke third-party access you do not recognize: API keys, application passwords, courtesy admin users (“for the support team”), webhooks. These doors get missed because “oh, that was the vendor who left last year”.
3. Check your domain’s email accounts — if the admin email is also compromised, “reset via email” is no longer safe; go through the hosting panel instead.
4. Turn on 2FA everywhere it is supported, today.

Day one: restore and inspect

Restore from backup — but only a backup proven clean. A backup from outside the compromised server, predating the incident, is a legitimate recovery point. How recent your last backup is decides everything: if restoring costs you the latest transaction data, that is the price of having no scheduled backup — note it as the next project, but do not leave hacked files live to avoid it.

Before going live, check these five places (in the restored copy or the quarantined server):

Location	What to look for
Upload folders (wp-content/uploads etc.)	.php files that have no business being in an images folder
Theme/plugin core files	Modification dates outside any edit you remember
users table / admin list	Admin accounts you did not create
functions.php, .htaccess, robots.txt	Injected foreign links/scripts, silent redirects
Cron jobs & scheduled tasks	Commands downloading payloads from other servers

Read the logs if you have them: web access logs (odd requests just before the incident), mass login failures/successes, SSH logs. The timestamp of the first attacker file you found is where the search starts.

Week one: close the root cause, repair your reputation

1. Audit the entry point — the step that separates “cleaned up” from “actually secure”. Without it, the quiet statistics are cruel: most sites cleaned without a root-cause audit get hit again, sometimes through the exact same hole. If you have no in-house capacity, this is external work — see what a security audit covers.
2. Check whether visitor data left with it. If yes, Indonesia’s PDP law (Law 27/2022) requires notifying data subjects within 3×24 hours — involve legal counsel; not telling can cost more than telling.
3. Report to BSSN via insiden.id for serious incidents — free, and it connects you to the national picture.
4. Check your reputation: site:yourdomain.com in Google (ghost pages still indexed?), Google Search Console security status and blacklist checkers. Request a security review in Search Console once clean.
5. Pay down the debt that made this possible: updates, dormant access removed, off-site scheduled backups, a team password manager. The full routine is in the 10-point website security checklist.

Frequently asked questions

How long does recovery usually take? Simple defacement cleaned by someone who knows the process: hours. If the attacker left backdoors that go unfound, or customer data was taken: days to weeks — and the remainder is audit work, not file shuffling.

I pay for hosting — aren’t they obligated to fix this? Hosting secures the server; your website, logins, and plugins on top of it are the site owner’s responsibility. Many plans provide tools, not incident handling — ask exactly what they cover, before you need it.

Can I finish this without outside help? Basic cleanup, often yes — the steps above are written for that. What is hard alone is objectivity: proving nothing was left behind. A small backdoor inside a file that “looks normal” is the last thing an owner finds, even weeks after believing it was clean.

---

Is your site compromised right now, or recently recovered and you want certainty nothing is left? Reach out via contact — first response within 24 hours, emergency steps can start today. Evidence of this work in real conditions: the IAC infrastructure case study.