The essentials
- Defacement is proof of write access to your site; the real question is what else that access reached — databases, customer data, other sites on the host.
- Capture the defaced state and preserve server logs before any restore; the logs identify the entry point.
- Entry is usually an unpatched CMS or plugin, stolen admin credentials, or a weak hosting account.
- Restoring from backup without closing the hole invites re-defacement within days — often automated.
- Check for webshells and new admin users; attackers leave doors behind the graffiti.
A defaced site is embarrassing in the most public way available, and the pressure to make it disappear is immediate. That pressure causes the classic mistake: restore the backup, delete the mess, change nothing — and get defaced again by the same automated tool a week later.
Treat it as what it is: unauthorized write access to your infrastructure, with a visible symptom and probably invisible ones too.
Do this now
- Capture the scene. Full-page screenshots and an archived copy of the defaced pages, with timestamps. Then put the site in maintenance mode rather than deleting anything.
- Preserve the logs. Web-server access and error logs, FTP/SSH logs, CMS audit logs, and hosting-panel history — exported now, before rotation or restore overwrites them.
- Find the way in. Look for the first anomalous request or login: an exploited plugin, an admin login from a strange address, a hosting-account access. File timestamps on the changed pages point to the moment.
- Close it and evict. Patch or remove the vulnerable component, change all admin and hosting credentials, remove unfamiliar users and access keys.
- Hunt the leftovers. Scan for webshells, modified core files, new scheduled tasks, and injected code sitewide — diff against a known-clean copy where possible.
- Restore verified-clean and monitor. Deploy from a source you trust, watch logs closely for return attempts, and consider what else the access could reach — a shared database or adjacent sites widen the scope.
What not to do
- Do not just restore the backup and move on — the hole travels with the old code.
- Do not delete logs while "cleaning up the mess".
- Do not announce all-clear before checking for persistence.
- Do not assume the visible page was the only thing touched.
- Do not keep using the same admin passwords "because they're strong" — they may be exactly what was stolen.
Preserve the evidence
Whatever else happens, these are the artifacts the investigation — and any insurance claim, dispute, or prosecution — will be built from:
- Screenshots and archived copies of the defacement.
- Web, FTP/SSH, and CMS logs covering the incident window.
- File modification timestamps on changed pages.
- The list of admin users and access keys before and after cleanup.
Keep a clear head
Public embarrassment is a bad advisor: it optimizes for making the symptom vanish rather than ending the access. The site can sit in maintenance mode for a few hours; that is a footnote. Re-defacement after a rushed restore is a story.
Questions victims ask
Restore first or investigate first?
Capture and preserve first — that is minutes, not hours. Then maintenance mode, then investigate enough to know the entry point, then restore clean with the hole closed. A restore that precedes understanding usually has to be redone.
Does defacement mean customer data was stolen?
Not automatically — many defacements are drive-by vandalism through a plugin exploit with no further reach. But write access sometimes equals read access, so check what the compromised component could touch before saying so publicly.
What about the SEO and safe-browsing damage?
If search engines flagged the site, use their post-cleanup review process (e.g. Search Console) once you are verifiably clean. Flags clear within days of a passed review; lingering blocklisting usually means leftover injected code.