A defaced website is a public incident from the first minute, and the visible page change is usually the least important part of it. The attacker who replaced your home page got write access to a CMS, a hosting account, a deploy pipeline, a storage bucket or your DNS, and may still hold it. This template gives [Organisation] a ready-to-adopt playbook for responding to external defacement of public websites: triage, evidence preservation, containment at the CDN and WAF, clean restoration, credential and non-human identity resets, communications and review. It is written for security operations, web and platform teams, communications leads and the managers who decide when to take a site offline. Replace every [bracketed] placeholder and test the playbook before you need it.
How to use this template
- Adopt, then tailor: copy sections 1 to 8 into your incident response plan and fill in the owners, hosting providers and recovery sources for each public site. See the Incident Response Plan Template.
- Know the threat: most defacements are hacktivist or opportunistic, timed to political events and claimed on social channels, often alongside DDoS. See the Hacktivism Guide and the DDoS Response Playbook.
- Find the path first: MITRE ATT&CK lists external defacement as T1491.002 under Impact. The playbook branches on how the change was made (section 3), because a CMS takeover, a stolen deploy key and a DNS hijack need different containment.
- Restore from known-good, never from the live server: keep a clean build source and a static holding page ready.
- Review annually and after every incident or hosting change. Owner: [Head of Digital Security].
1. Scope and triggers
1.1 This playbook covers unauthorised changes to the visible content of any [Organisation] public web property: corporate sites, campaign microsites, documentation portals, status pages and content served from CDN or object storage. Internal defacement (T1491.001, for example a changed intranet page or desktop wallpaper) follows the same steps but is handled as a likely intrusion under the general incident response plan.
1.2 Triggers: integrity or uptime monitor alert on a changed page hash or missing expected string; customer, staff or press report; a hacktivist claim naming [Organisation]; an unexpected CMS publish, new administrator or plugin; a deployment nobody scheduled; a WAF alert for web shell upload; or a DNS or TLS certificate change you did not make.
1.3 Common entry paths.
| Path | Typical evidence | ATT&CK | First containment |
|---|---|---|---|
| Exploited CMS core, plugin or theme | New PHP files, unknown admin user, exploit requests in access logs | T1190 Exploit Public-Facing Application; T1505.003 Web Shell | Maintenance page at the CDN, isolate origin, preserve disk |
| Stolen CMS or hosting panel credentials | Admin login from new IP or country, no MFA prompt | T1078 Valid Accounts | Disable account, revoke sessions, reset all admin credentials |
| Compromised deploy key, CI token or Git account | Commit or pipeline run with unexpected author or runner | T1078 Valid Accounts | Revoke the key or token, freeze the pipeline, review recent commits |
| Exposed storage bucket or static hosting | Object write from an unknown principal | T1078 Valid Accounts | Remove public write, rotate access keys, restore objects from versioning |
| DNS or registrar change | Site content differs by resolver; origin unchanged | T1584.002 DNS Server | Switch to the DNS Hijack Playbook |
2. Roles and contacts
| Role | Named owner | Responsibilities |
|---|---|---|
| Incident Lead | [Security Operations Manager] | Declares the incident, keeps the decision log and timeline |
| Web Platform Lead | [Web or Platform Engineering Lead] | CMS, hosting, CDN and WAF changes, restoration |
| Forensics Lead | [DFIR analyst or retained provider] | Evidence capture, root cause, scope of access |
| Identity Lead | [IAM Lead] | Human and non-human credential resets, session revocation |
| Business Owner | [Head of Digital] | Approves taking the site offline and the holding page wording |
| Communications Lead | [Head of Communications] | Press, social, customer and staff statements |
| Legal Counsel | [General Counsel] | Law enforcement, regulatory and contractual notices, unlawful content |
2.1 Provider sheet: for every hosting provider, managed CMS, CDN, WAF, DNS provider and registrar record the 24/7 support route, account IDs, who is authorised to request emergency changes and how the provider verifies them. Keep a copy offline.
2.2 Keep an out-of-band channel for responders. Assume the attacker may be reading compromised staff mailboxes if the entry path was credential theft.
3. Detection and triage
- Confirm and capture: take timestamped screenshots and save the full HTML, headers and resources of the defaced page from at least two networks before anything changes. Note the URL, resolver used and the IP address served.
- Locate the change: compare the live response with the origin, the CDN cache and the repository. Content differs by resolver: suspect DNS. Origin files changed: suspect CMS or host compromise. Only cached objects or a bucket changed: suspect storage or CDN configuration.
- Scope: list every site sharing the same server, CMS instance, hosting account, deploy key or CDN account. Hacktivist groups often deface many sites on one shared host.
- Look beyond the page: check for web shells, new admin users, scheduled tasks, modified plugins, injected scripts (card skimmers, cryptominers, malicious redirects) and outbound connections from the web server.
- Set severity: Critical if the content is unlawful, harmful to visitors (malware, credential phishing) or the site handles customer data; High for a main brand site; Medium for a low-traffic microsite with no data.
Decision point A: if the site serves malware, a phishing form or unlawful content, take it offline immediately (section 4.1) without waiting for full scoping.
Evidence to preserve: page captures; web server, CMS, WAF and CDN logs; CMS database export and audit log; a disk or snapshot image of the origin (snapshot before you clean it); file listings with modification times; Git history and CI run logs; cloud audit logs for the hosting account; and any claim posts, saved with URL and time. Record hashes for each item and keep chain of custody. See the Digital Forensics (DFIR) Guide.
4. Containment
4.1 Take the content down at the edge, not at the origin. Serve a prepared static holding page from the CDN, or switch the CDN origin to a clean static bucket. This removes the defacement within minutes while the compromised origin stays intact for forensics. Purge the CDN cache for all affected paths.
4.2 Cut attacker access.
- Restrict the origin so it accepts traffic only from CDN ranges, and block administrative paths (for example the CMS login and XML-RPC endpoints) at the WAF except from [admin IP range or ZTNA].
- Disable suspicious CMS accounts, force logout of all sessions and freeze publishing.
- Revoke deploy keys, CI tokens and storage access keys used by the site (section 5.3 covers full rotation).
- Isolate the origin host or container from internal networks; do not power it off before memory and disk capture if the Forensics Lead needs them.
Decision point B: if the origin cannot be isolated without losing evidence, snapshot first, then isolate. The Incident Lead records which was done when.
Decision point C: do not engage the attacker or respond to claims publicly. Legal Counsel decides on referral to law enforcement.
5. Eradication
5.1 Fix the entry path found in triage: patch or remove the vulnerable plugin, theme or core version; close public write on storage; remove unused CMS instances. See the PHP and WordPress Security Guide.
5.2 Do not "clean" a compromised server in place. Rebuild from a hardened image and redeploy code from the repository at a commit verified to predate the compromise. Search the database for injected content, rogue options and unknown administrators before reusing it.
5.3 Credential and NHI resets. Reset or revoke every credential the attacker could have seen or used, not only the one you think they used.
| Credential | Action | Owner |
|---|---|---|
| CMS administrator and editor accounts | Reset passwords, enforce phishing-resistant MFA, remove dormant accounts, revoke application passwords | Identity Lead |
| Hosting, control panel, SFTP and SSH | Reset passwords, replace SSH keys, remove unknown keys from authorized_keys | Web Platform Lead |
| Deploy keys, CI/CD tokens, Git personal access tokens | Revoke and reissue with least scope and expiry; review pipeline secrets | Web Platform Lead |
| CDN, WAF and DNS provider API tokens | Revoke, reissue scoped per zone, restrict by source IP where supported | Web Platform Lead |
| Database, SMTP and third-party API keys in config files | Rotate; move into a secrets manager | Web Platform Lead |
| CMS salts and session signing keys | Regenerate to invalidate every session | Web Platform Lead |
| TLS private keys on the compromised origin | Reissue certificates and revoke the old ones | Web Platform Lead |
See the Secrets Rotation Runbook Template and the Web Shell Response Playbook.
6. Recovery
- Deploy the rebuilt site to a staging origin and verify it: file integrity against the release manifest, no unknown admin users, plugins at current versions, WAF rules in place.
- Switch the CDN back to the new origin, purge cache, and confirm from several regions and resolvers.
- Restore content created since the last clean release from the CMS export only after review by an editor.
- Keep heightened monitoring for [30] days: page integrity checks every [5] minutes, alerts on admin logins, new users, plugin installs and file changes. Hacktivist groups often return.
- The Business Owner signs off the return to normal service; the Incident Lead closes the incident after the review.
7. Communication and notification
| Audience | When | Owner | Content |
|---|---|---|---|
| Executives | Within [1] hour | Incident Lead | Impact, content shown, actions, decisions needed |
| Staff | Same day | Communications Lead | Do not comment publicly or share screenshots; route press queries |
| Public and press | When the holding page goes up | Communications Lead | Short factual statement; do not repeat or amplify the attacker's message |
| Customers | If data, malware or phishing was involved | Communications Lead with Legal | What happened, what they should do |
| Regulators | If personal data was affected, within statutory deadlines (for example 72 hours under UK GDPR and GDPR Art. 33) | Legal Counsel | Breach notification |
| Law enforcement and national CERT | For hacktivist, extremist or repeat attacks | Legal Counsel | Indicators, claims, timeline |
| Hosting and CMS providers | Immediately if shared infrastructure | Web Platform Lead | Indicators, affected accounts |
8. Post-incident review
8.1 Within [10] business days review: time from defacement to detection, to holding page, to clean restoration; entry path and why it was open; every credential the attacker could reach; and whether other sites share the weakness. See the Post-Incident Review and Root Cause Analysis Template.
8.2 Track actions to closure: retire unused sites, move static sites to read-only hosting, add MFA to every admin path, and add scope and expiry to every deploy token.
Implementation guidance
Prepare before the incident.
- Inventory every public site, its CMS, host, CDN, DNS provider, owner and the credentials and tokens that can change it.
- Pre-build a static holding page and a CDN rule or origin switch that serves it in one step; test it.
- Enable content integrity monitoring and CMS audit logging, and send logs off the web host.
- Put admin interfaces behind SSO with phishing-resistant MFA or an allow-listed path.
- Exercise the playbook with a tabletop, then a drill on a staging site. Rollback: every edge rule added in section 4 must have a documented removal step.
Hosting model trade-offs.
| Model | Defacement exposure | Recovery |
|---|---|---|
| Self-managed CMS on a VM | Highest: plugins, admin panel, server access | Rebuild from image and repository |
| Managed CMS platform | Admin accounts and plugins; provider patches core | Provider backups plus content review |
| Static site via CI to object storage behind CDN | Deploy tokens and storage permissions | Redeploy a known commit; object versioning |
| Headless CMS with static front end | API tokens and editor accounts | Rebuild front end; restore content entries |
Small vs large organisations. A small organisation should favour managed or static hosting, MFA on every admin account and a tested holding page. A large one also needs a site register, central CDN and WAF policy, and alerting on publish events across all properties.
Metrics. Time to holding page; time to clean restoration; percentage of public sites with integrity monitoring; percentage of admin accounts with phishing-resistant MFA; deploy tokens without expiry; days since the holding page was last tested.
Framework mapping.
| Framework | References |
|---|---|
| NIST CSF 2.0 | DE.CM-09 monitoring of computing hardware, software and their data; RS.MA-01 coordinated response; RS.CO-02 stakeholder notification; RC.RP-01 recovery execution |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling; IR-6 Incident Reporting; SI-7 Software, Firmware, and Information Integrity; CM-3 Configuration Change Control; AU-6 Audit Record Review; IA-2 Identification and Authentication |
| MITRE ATT&CK | T1491.002 External Defacement; T1190; T1505.003; T1078; T1584.002 |
Where identity fits. Most defacements succeed through a credential: a reused CMS password, a deploy key with no expiry, a CDN API token in a public repository. Treating those keys and tokens as non-human identities with an owner, scope and rotation date is the most effective preventive control. See the API Key Management Guide.
Standards and references
- MITRE ATT&CK: T1491.002 External Defacement
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1505.003 Web Shell
- NCSC: Managing Public Domain Names
Related NHI Mgmt Group resources: Incident Response Plan Template · Hacktivism Guide · Web Application Firewall Guide · CDN Security Guide · DNS Hijack Playbook