Website Defacement: Risks, Detection, and Response

A defaced website has public content that was changed without authorization. Treat the change as a possible sign of a wider compromise: investigate what access was used and what else may have been affected before declaring the site recovered. NIST identifies web defacement as an example of unauthorized data modification.^[1]

1. What website defacement means

Website defacement is an unauthorized alteration to a public-facing page or other website content. It can be a changed homepage, injected text, replaced images, or other unexpected content. The visible change is evidence that content was modified; by itself, it does not establish how the change happened, who caused it, or whether other systems or data were affected.

Investigate the possibility that access to a web server, content management system, administrator account, deployment process, or connected component was involved. These are avenues to check, not conclusions from the defacement alone. The response should establish the scope from available evidence.

2. How to recognize a possible defacement

A visual check can find obvious changes, but detection should also use reports, files, logs, alerts, and resource activity. NIST’s incident handling guide lists the following as possible signs of unauthorized data modification. Treat each as a lead to investigate, not conclusive proof on its own.^[1]

User reports: visitors or staff report unexpected text, images, redirects, or pages.
Changes to critical files: web pages or other important site files differ from an authoritative known-good copy.
Unexpected files or directories: new items have unusual names or appear in places where they are not expected.
Security alerts: intrusion detection or other monitoring reports activity that needs review.
Unusual log messages: application, web server, identity, or system records show unexpected events.
Unexpected resource use: resource consumption changes significantly from its normal pattern.

Compare affected pages and files with a known-good copy, then look for related changes elsewhere in the site. A page can appear normal while other files or accounts remain affected, so visual review alone cannot establish that the incident is contained.

3. Investigate the scope and preserve evidence

Notify the designated response contacts. Follow your organization’s incident procedures and assign an incident lead if your process calls for one.
Record what was observed. Note when the change was found, which pages or files appear affected, who reported it, and what systems are in scope so far.
Preserve relevant records and artifacts. Where feasible and safe, retain logs and suspicious files before routine rotation or cleanup overwrites them. Follow your incident plan for evidence handling.
Compare against authoritative content. Identify what changed and when, using a protected known-good copy and available records.
Review activity across relevant systems. Examine available hosting, web server, application, content management, identity, and network logs for the suspected period. Look for unexpected administrator accounts, file changes, and access activity.
Check connected exposure. Determine whether other hosted sites or connected services may share the same access path or credentials.
Determine containment and remediation from the evidence. The right steps depend on the environment and findings; a generic action sequence cannot establish that every incident is contained.

CISA recommends enabling logs on relevant business systems, deciding which user, administrator, network, application, and system events to record, centralizing records where practical, setting alerts for high-risk activity, reviewing logs, and protecting them from unauthorized access or deletion. Assign responsibility for review and response before an incident occurs.^[2]

4. Restore the site without missing the cause

Restore known-good content through the documented recovery process, using a protected authoritative copy. Before treating restoration as complete, consider whether the cause of the unauthorized modification has been addressed. If the access path remains available, the content could be changed again.

NIST’s public web server guidance recommends protecting an authoritative copy of web content, controlling who can update it, using strong authentication and logging, and incorporating restoration from that copy into incident response procedures.^[3] A successful page restore alone does not prove that the attacker has been removed or that connected accounts and systems are safe.

After restoration, keep monitoring and review what enabled the change. Update controls, responsibilities, and recovery documentation based on the investigation. CISA’s incident response playbooks include detection, analysis, and data preservation activities; follow the applicable organizational process and edition.^[4]

5. Prepare to detect and recover

Keep an authoritative copy separate from ordinary production access and protect it from unauthorized changes.
Restrict update rights to the smallest practical group; use strong authentication and a documented approval and deployment process.
Enable and retain useful logs on relevant systems, protect them against tampering, and decide who reviews them and how suspicious activity is escalated.
Document restoration steps and make sure the protected content copy can be used through the recovery process.
Assign response roles across technology, communications, legal, and business continuity functions as appropriate to your organization.

These controls support prevention, investigation, and recovery; none guarantees that a site will never be defaced. NIST’s web server guidance and CISA’s logging guidance provide further detail on authoritative content, access controls, monitoring, and response responsibilities.^[3]^[2]

6. Use screenshots as one investigation aid

A screenshot can document what a public page looked like at a particular capture, which may help compare visible changes or maintain a record for a response timeline. It does not reveal the server-side cause, prove that other files are clean, or replace preserved logs and incident investigation.

For a manual capture, open the page in a browser, record the URL and capture time with your incident notes, and save the image in the evidence location specified by your response process. Keep the original artifact and record who captured it. Avoid treating a later screenshot as a substitute for preserving the affected state and relevant system records.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Its one-request API can capture a URL as an image or PDF. For example, this cURL request saves a WebP capture of the affected public page:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

See the ScreenshotNeo API documentation for request options. Python and Node.js callers can use the same endpoint and parameters:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

ScreenshotNeo accepts cookie or consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Evidence note: use screenshots to record rendered public content, not as proof of server integrity or incident scope. Follow your response plan for preserving logs, files, and other evidence.

7. Troubleshooting investigation gaps

Problem	Why it matters	What to do
The page looks normal now	The visible content may have been restored or changed again; that does not establish what happened or whether other components were affected.	Compare files with the authoritative copy and review relevant logs and artifacts for the incident period.
There is no obvious suspicious log entry	Logging may not have been enabled, may not cover the relevant service, or records may have rotated.	Check which sources and event types were retained, preserve remaining data, and document the limits of what can be concluded.
A new file or alert was found	One indicator can be benign or unrelated and does not by itself define incident scope.	Preserve it and correlate its timing and context with other files, logs, accounts, and system activity.
The same content changes again after restoration	The cause or access path may still be present, or the restored content may be exposed to the same update route.	Reopen the investigation, preserve evidence, and review access, update, and deployment paths under the incident process before another recovery declaration.
Other sites share the same hosting or credentials	A common access path may increase the scope that needs review.	Check related sites and accounts for relevant changes and activity; do not assume they are affected or unaffected without evidence.
A screenshot does not match what another person saw	Pages can vary by time, cookies, location, or browser state.	Record capture time and URL, retain the original artifact, and use server and application records to investigate the difference.

8. FAQ

Does a defaced page prove that customer data was stolen?

No. A visible content change establishes neither data theft nor its absence. Investigate logs, systems, accounts, and evidence relevant to the environment.

Can I declare the incident resolved after putting the old homepage back?

No. Restoring content is one recovery action. Investigate the access path and scope, and continue monitoring before declaring recovery complete.

Should I delete suspicious files immediately?

Preserve relevant artifacts when feasible and safe, following your incident response and evidence handling process. Immediate deletion can remove information useful to the investigation.

Is a public screenshot enough to prove what happened?

No. It records a rendered page at a capture, but does not establish server-side activity, incident timing beyond the capture record, or the state of other systems.

Sources

NIST SP 800-61 Rev. 1, Computer Security Incident Handling Guide (legacy guidance; March 2008).
CISA, Using Logging on Business Systems.
NIST SP 800-44 Rev. 2, Guidelines on Securing Public Web Servers (September 2007).
CISA, Cybersecurity Incident and Vulnerability Response Playbooks.