Detect Website Defacement — Unauthorized Web Root and CMS Content Tampering in Elastic Security
Website defacement remains a common Impact objective for hacktivist and ideologically-motivated actors, and increasingly appears as a secondary objective in ransomware and extortion intrusions to pressure victims publicly. The typical path to defacement is initial access via an exposed CMS admin panel (WordPress, Joomla), an unpatched CVE in a web application, or credentials reused/purchased from a prior breach, followed directly by modification of homepage or landing-page content — either through the CMS's own content editor or by dropping a file directly into the web root that overwrites index.html/index.php/default.aspx. Two independent detection surfaces exist: (1) endpoint/file telemetry showing a write to a canonical homepage filename inside a web-exposed directory, especially when the writing process is a shell, script interpreter, or the web server worker itself rather than a known deployment/CI process; and (2) CMS application-layer telemetry showing an admin authentication event immediately followed by a content-publish action from a source IP that has never previously been associated with that admin account. Neither signal alone is fully reliable (legitimate deploys touch index files; legitimate admins log in from new locations occasionally), but the combination — an unrecognized process or unrecognized source touching production homepage content outside a known deployment window — is a high-fidelity defacement indicator.
MITRE ATT&CK
- Tactic
- Impact
Elastic Detection Query
any where event.category == "file" and event.type in ("creation", "change", "rename") and (
file.path : ("*wwwroot*", "*htdocs*", "*inetpub*", "*/var/www/*", "*/usr/share/nginx/*") and
file.name : ("index.html", "index.php", "index.htm", "default.aspx", "default.asp", "home.html", "wp-config.php") and
not process.name : ("msbuild.exe", "dotnet.exe", "git.exe", "rsync", "scp", "w3wp.exe", "docker.exe")
)Detects creation, modification, or rename of canonical homepage/landing-page filenames inside web-exposed directories where the responsible process is not a recognized deployment tool, using Elastic ECS file events. Covers the endpoint/filesystem half of the defacement detection surface; the CMS admin-publish anomaly (source-IP-never-seen-before) should be implemented as a companion detection against ingested CMS application logs.
Data Sources
Required Tables
False Positives & Tuning
- Deployment tools not yet added to the process allowlist writing homepage files during a legitimate release
- Configuration management agents (Ansible, Puppet, Chef) pushing static content updates
Other platforms for THREAT-Impact-WebsiteDefacementIntegrityTamper
Testing Methodology
Validate this detection against 2 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1 Simulate Web Root Homepage Overwrite via Shell
Expected signal: File creation/modification event for index.html in a web-exposed directory, InitiatingProcess is a shell (bash/sh) rather than a known deployment tool.
- Test 2 Simulate CMS Admin Publish From New Source IP
Expected signal: Two CMS audit log events for the same admin account within 30 minutes: a login followed by a publish action, from an IP absent from the account's known-IP set.
Response Playbook
Triage
- Confirm the change is unauthorized: diff the current homepage content against the last known-good version in source control or the CDN cache to see exactly what was altered.
- Identify the writing process and account for the file-level signal, or the admin account and source IP for the CMS-level signal — determine whether that account's credentials were recently involved in a phishing or credential-stuffing alert.
- Check whether the site is public-facing and currently serving the defaced content to visitors, or whether it was caught before propagating past a staging/CDN cache layer.
- Look for a preceding initial-access indicator on the same host: web shell upload, CMS plugin/theme file upload, or exploitation of a known CVE in the CMS or web framework.
- Determine scope: is this one site/vhost on a shared web server, or could the same access path affect other tenants on the same host?
Containment
- Restore the homepage/affected pages from a known-good backup or source-control revision immediately to limit public exposure.
- Revoke sessions and force a password reset for the compromised admin account; enforce MFA on the CMS admin panel if not already required.
- Isolate the host (if self-hosted) via EDR, or place the CDN/WAF in front of the origin with a maintenance page while remediation completes.
- Remove any dropped web shell or unauthorized plugin/theme file identified during triage, and patch the CVE or misconfiguration that enabled initial access.
- If the defacement is part of a broader extortion campaign, coordinate with the incident commander before making the fix public — some actors monitor for restoration and re-deface.
Evidence Collection
- The defaced file's full content and a diff against the last known-good version
- DeviceFileEvents / Sysmon FileCreate history for the affected file and directory over the prior 30 days
- CMS audit log entries for the admin account: login history, IP history, and all content actions in the preceding 7 days
- Web server access logs for the affected vhost around the time of the change
- Any web shell or backdoor file discovered on the host, preserved for forensic analysis
Escalation Criteria
- !Defacement is currently live and publicly visible on a customer-facing or brand-critical domain
- !Defacement includes political, extremist, or extortion messaging tied to a known threat actor or campaign
- !Evidence of a web shell or persistent backdoor beyond the single content change
- !Multiple sites/vhosts on the same infrastructure show tampering, indicating broader compromise
- !The compromised admin account also has access to other systems (shared credentials, SSO)
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Sysmon Event ID 11 (FileCreate) or Event ID 2 (FileCreationTime changed) for the web root directory - >
CMS application logs: wp-content/debug.log, plugin/theme edit history, revision history for the affected page - >
Web server access/error logs showing the request that triggered the content change (POST to /wp-admin/post.php, /administrator/index.php, or an uploaded file request) - >
Any newly created PHP/ASPX file in an uploads or plugin directory (common web shell staging locations)
Tuning Guidance
Maintain an accurate KnownDeployProcesses allowlist reflecting your actual CI/CD and configuration-management tooling; the largest source of false positives is a legitimate deploy process not yet on the list. For the CMS admin-publish signal, seed PriorIPsPerAccount with at least 90 days of history before enabling alerting, and consider excluding known corporate egress IP ranges/VPN concentrators from the 'never seen' comparison to reduce noise from NAT pool rotation.
Hunting Queries
Hunt for newly created server-side script files written by the web server worker process itself — a common precursor to defacement where a web shell is dropped before the homepage is modified.
DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath has_any ("\\wwwroot\\", "/var/www/")
| where FileName endswith ".php" or FileName endswith ".aspx"
| where InitiatingProcessFileName in~ ("w3wp.exe", "php-cgi.exe", "httpd", "nginx")
| where ActionType == "FileCreated"
| summarize FirstSeen=min(Timestamp), Count=count() by FileName, FolderPath, DeviceName
| where FirstSeen > ago(30d)
| sort by FirstSeen descindex=mde sourcetype="DeviceFileEvents" ActionType=FileCreated (FolderPath="*\\wwwroot\\*" OR FolderPath="*/var/www/*") (FileName="*.php" OR FileName="*.aspx") InitiatingProcessFileName IN ("w3wp.exe","php-cgi.exe","httpd","nginx")
| stats earliest(_time) AS FirstSeen count AS Count by FileName FolderPath DeviceName
| sort - FirstSeenAtomic Red Team Tests
Overwrites a test index.html file in a web-exposed directory using a shell process rather than a deployment tool, simulating the file-tampering path to defacement. Run only against a lab/test web root.
Command
echo '<html><body>TEST DEFACEMENT SIMULATION</body></html>' > /var/www/test-site/index.htmlCleanup
git -C /var/www/test-site checkout -- index.htmlExpected Telemetry
File creation/modification event for index.html in a web-exposed directory, InitiatingProcess is a shell (bash/sh) rather than a known deployment tool.
Expected Detection
Alert fires on WebRootHomepageTamperedByUnexpectedProcess indicator with RiskScore=90.
Simulates a CMS admin login and content-publish action logged from a source IP not present in the account's prior 90-day login history, replicating the credential-theft-then-deface pattern. Requires test CMS audit log entries.
Command
# Insert test CMSAuditLogs_CL rows: login_success then publish_post within 5 minutes, SourceIP=203.0.113.50 (not in prior 90-day set for the test account)Cleanup
Remove the injected test log rows from CMSAuditLogs_CLExpected Telemetry
Two CMS audit log events for the same admin account within 30 minutes: a login followed by a publish action, from an IP absent from the account's known-IP set.
Expected Detection
Alert fires on CMSAdminPublishFromNeverSeenSourceIP indicator with RiskScore=75.