How to Detect Website Defacement and Unauthorized Changes

A defaced page is one possible sign of a broader integrity incident. To detect visible defacement and less obvious unauthorized changes, compare current critical files and configuration with a known-good baseline, then investigate alerts alongside authentication records, server logs, processes, accounts, and network activity. A page that looks normal does not establish that the server is intact.

Start by verifying that the site and server are clean, create a protected reference state, and monitor critical files for changes. Treat an alert as a lead: authorized releases and patches also change files, so check change records and correlate evidence before drawing conclusions.

What website defacement and unauthorized changes can mean

Defacement is a visible manifestation: someone may have changed the content displayed to visitors. An integrity incident can also involve less obvious changes to public content, application code, critical web-server files, configuration, accounts, or installed software. NIST’s data-integrity guidance describes the concern as “guarding against improper information modification or destruction and ensuring information non-repudiation and authenticity.” NIST NCCoE SP 1800-26 describes unauthorized insertion, deletion, and modification and presents detection, integrity monitoring, logging, reporting, containment, and forensics as connected parts of a response.

That is why visual inspection alone is inadequate. A changed page can be obvious, but an altered script, server setting, administrator account, or background process may not affect what the home page looks like. Conversely, a visual difference may have a routine explanation, such as a content release.

Indicators to investigate

These signals can help identify a possible incident, but no single one proves that a site has been compromised:

A checksum or cryptographic hash mismatch on a critical file.
Unexpected edits to public pages, scripts, application code, or server configuration.
Changes outside an expected release or maintenance window.
New privileged accounts, software, services, or processes that administrators cannot explain.
Unusual authentication patterns or network behavior occurring near the time of a file change.

Check the release calendar, patch records, and authorized administrator activity. A cluster of unexplained changes and unusual logins or processes deserves more urgent investigation than an isolated, documented deployment change.

Build a trustworthy baseline

Verify the system first. Confirm through your security and operational procedures that the server and site are in a known-clean state. If you baseline a compromised system, you can accidentally record attacker-controlled files as trusted.
Choose what to cover. Include critical public content, application code, web-server files, configuration, and other files relevant to your threat model. Record enough context to understand what each monitored file does and who owns it.
Calculate strong file hashes. A file-integrity monitoring tool compares current checksums or hashes with stored reference values. Prefer cryptographic hashes appropriate to your environment; do not rely on 32-bit CRC as a security check.
Protect the reference separately. Store baseline data offline or otherwise separately from the monitored host, with access controls and a recovery path. If an attacker who changes the site can also rewrite its reference database, the comparison may no longer be trustworthy.
Document approved updates. Releases and patches legitimately change files. Define who can authorize baseline updates, how changes are reviewed, and how the updated reference is protected. Avoid automatically trusting every observed change.

NIST SP 800-44 gives foundational advice on file-integrity checkers, secure baselines, offline reference storage, stronger checksums, and false positives. Its operational recommendations are guidance from that publication, not a universal modern monitoring schedule. Set review frequency based on your exposure, change rate, and response capacity.

Monitor and investigate changes

Watch critical files and configuration. Configure integrity monitoring for selected files and relevant system and application settings. Ensure alerts reach a responsible administrator or response team.
Retain useful context. Preserve timestamps, file paths, alert details, and relevant application, authentication, and server logs. Know where those records are stored and who can access them.
Check authorized activity. Compare the change time with deployment records, patch activity, scheduled jobs, and administrator actions. Confirm the change with its owner rather than assuming that a familiar time or account makes it safe.
Correlate independent evidence. Investigate nearby logins, new accounts, services, software, processes, and unusual network activity. A file change paired with unexplained privileged access is more concerning than a documented release.
Preserve evidence and follow your response plan. Keep relevant artifacts and logs for analysis. Follow your organization’s incident-response and reporting procedures; a screenshot or a file alert is not a complete forensic record.

NIST SP 800-44 Rev. 2 discusses critical-file monitoring, event notifications, and host-based and network-based intrusion detection capabilities and limitations. CISA’s incident-investigation guidance also emphasizes preserving and analyzing artifacts and logs. Monitoring signals should feed investigation and response, not replace them.

Host monitoring and network monitoring

Approach	Useful visibility	Limits to plan for
Host-based monitoring	File changes, processes, and system activity on the monitored server; it can remain useful when web traffic is encrypted.	Uses server resources and depends on the operating system. A monitor on a compromised host may be altered or disabled.
Network-based monitoring	Traffic across multiple hosts and a broader view of network behavior, depending on where sensors are placed.	Placement affects coverage, and encrypted traffic can reduce what inspection reveals. It does not directly replace file-integrity checks.

These controls provide different views and are complementary, not guarantees. Consider deployment effort, performance, resilience, alert quality, and the staff time needed to review false positives. Keep detection signatures and rules current where applicable, and make sure alerts include enough event detail to investigate.

Check what visitors can see

External page checks can help confirm a visible change or capture evidence of what a visitor saw at a particular URL and time. They cannot inspect server files, configuration, accounts, or processes, and they do not prove the origin or cause of a change. Use them as one observation alongside host and network evidence.

For a manual check, open the affected page in a clean browser session, compare it with an expected rendering or approved content, and record the URL and observation time. Avoid treating a cached page or an image alone as proof that the underlying server is clean.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A single request can capture a URL as PNG, JPEG, WebP, or PDF. A screenshot can help document a visible page state; use file-integrity monitoring and logs to investigate server integrity. See the ScreenshotNeo API documentation.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
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 Bun.write('shot.webp', res);

Replace the example URL with a page you are authorized to monitor. Keep the API key out of public client code and logs. The response includes X-Page-Verdict and X-Billed headers describing the page outcome and billing status.

Cookie and consent banners are accepted before capture; more than 60 known consent platforms, newsletter popups, and chat widgets can be removed. Each step can be turned off.
Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed; response headers report the verdict and billing status.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The free plan includes 1,000 screenshots per month without a card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

Troubleshooting and common mistakes

Symptom	Likely cause	What to do
Many files changed after a release	Expected deployment or patch changes were not recorded or reviewed.	Match file paths and timestamps to the release and patch records. Review the release process, then approve and protect the updated baseline through the normal change procedure.
The baseline matches, but the site looks wrong	The monitored scope may omit the changed file or content may be generated from a database or remote service.	Review coverage against the application architecture. Check database-backed content, application logs, and external dependencies as appropriate; a file baseline only checks what it monitors.
Alerts appear inconsistent or noisy	Monitoring scope, file ownership, change records, or alert context may be insufficient.	Confirm monitored paths and permissions, add relevant deployment context, and tune scope carefully. Do not suppress unexplained critical-file changes just to reduce noise.
The integrity database changed unexpectedly	It may be writable from the monitored host or baseline-update access may be too broad.	Treat this as a serious integrity concern. Preserve available records, verify the trusted copy, review access and authentication logs, and follow the incident-response plan.
A page screenshot differs from the expected page	The page may have changed, or rendering may vary because of dynamic content, personalization, consent state, timing, or caching.	Repeat under documented conditions and compare the observation time with server-side logs and approved changes. A visual difference is a lead, not proof of compromise.

Performance, reliability, and operating cost

File monitoring consumes host resources, and broad monitoring can create more alert-review work. Start with critical files and configuration, estimate the change volume, and expand where the coverage is useful and manageable. Network monitoring has different placement and traffic-visibility limits; neither approach catches every attack.

Protecting the baseline separately improves resilience if the host is compromised, but it also requires secure access, backup, and a controlled update process. Retained logs and artifacts need storage and review ownership. The operational cost is not only tooling: include the time to validate routine changes and investigate unexplained ones. No single cadence fits every site; choose one based on risk and response capacity.

FAQ

Can a normal-looking homepage prove the website is safe?

No. Changes to scripts, configuration, accounts, or background processes may not be visible on the homepage. Compare critical files with a trusted baseline and review system activity.

Does a hash mismatch mean the site was hacked?

No. Releases, patches, and other authorized work can change hashes. Check records and correlate the alert with other evidence.

Can screenshots replace file-integrity monitoring?

No. Screenshots show a rendered page at a point in time. They do not inspect the server’s files, configuration, accounts, or processes.

Should every file on the server be monitored?

Choose coverage based on the threat model and the ability to review alerts. Include critical web content, application code, server files, and configuration; expand deliberately as you learn where useful signals come from.