Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-Impact-PublicWebsiteDefacement.

Upgrade to Pro
THREAT-Impact-PublicWebsiteDefacement Elastic Security · Elastic

Detect Public Website Defacement via Compromised CMS Admin Session or Mass Static Asset Tampering in Elastic Security

Adversaries who obtain stolen CMS administrator credentials or exploit an unpatched plugin/theme vulnerability on a public-facing content management system (WordPress, Joomla, Drupal, Umbraco, Sitecore, etc.) frequently pivot straight to defacing the site — replacing the homepage, posting propaganda content, or mass-editing pages — to deliver a political message, claim credit, or intimidate the target organization. This pattern shows up in two complementary ways depending on the compromise vector: (1) a burst of authenticated content-edit HTTP requests (POST/PUT to admin post/page/theme-editor endpoints) from a single source IP or session hitting many distinct URLs in a short window, captured in WAF or reverse-proxy access logs, which is characteristic of a scripted mass-edit rather than a human editor working through the admin UI one page at a time; and (2) direct filesystem tampering where an attacker who has RCE (via a vulnerable plugin, exposed file manager, or stolen SFTP/SSH credentials) bypasses the CMS application layer entirely and mass-modifies static HTML, PHP, CSS, JS, and image assets directly in the web root, captured via endpoint file-monitoring telemetry. Both paths differ sharply from routine content operations: legitimate CMS editors and CI/CD deployment pipelines touch a handful of pages per session or deploy through a recognized service account/process, not dozens of distinct admin endpoints or web-root files from a single caller within minutes. Detection correlates a distinct-URL or distinct-file count threshold within a short burst window against the initiating source IP, session, or account to separate scripted mass defacement from normal editorial and deployment activity.

MITRE ATT&CK

Tactic
Impact

Elastic Detection Query

Elastic Security (Elastic)
eql
sequence by host.name, user.name with maxspan=15m
  [file where event.action == "modification" and file.path : ("*/var/www/*", "*wwwroot*", "*htdocs*", "*public_html*") and file.extension : ("html", "htm", "php", "css", "js", "jpg", "png", "svg")]
  [file where event.action == "modification" and file.path : ("*/var/www/*", "*wwwroot*", "*htdocs*", "*public_html*") and file.extension : ("html", "htm", "php", "css", "js", "jpg", "png", "svg")]
  [file where event.action == "modification" and file.path : ("*/var/www/*", "*wwwroot*", "*htdocs*", "*public_html*") and file.extension : ("html", "htm", "php", "css", "js", "jpg", "png", "svg")]
critical severity medium confidence

Elastic EQL sequence matching 3 or more web-root file modification events from the same host and user within a 15-minute window, using the Elastic Agent filesystem integration (logs-endpoint.events.file-*). This illustrative 3-step sequence approximates the mass-tampering pattern; a production rule should replace it with an Elastic detection-rule threshold aggregation (distinct file.path count >= 5 per host.name/user.name in 15m) for full parity with the KQL/SPL Branch 2 logic, since EQL sequence matching alone does not enforce a distinct-file-count threshold. Branch 1 (WAF admin-edit burst) should be implemented as a separate threshold rule over the web proxy/WAF integration dataset (logs-*.access-*), aggregating dcount(url.path) by source.ip.

Data Sources

Elastic Agent endpoint integration (file events)logs-endpoint.events.file-*WAF / reverse proxy integration (logs-*.access-*)

Required Tables

logs-endpoint.events.file-*

False Positives & Tuning

  • CI/CD deployment agents pushing an updated site build to the web root as part of a normal release
  • CMS auto-update processes rewriting many PHP/HTML/CSS files during a scheduled update window
  • Site migration or staging-to-production sync jobs copying a large static asset set into the web root
  • Backup/restore jobs that touch many web root files during a scheduled maintenance window

Other platforms for THREAT-Impact-PublicWebsiteDefacement


Testing Methodology

Validate this detection against 3 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.

  1. Test 1Simulate Burst of CMS Admin Content-Edit Requests

    Expected signal: WAF/reverse-proxy access logs (CommonSecurityLog) showing 10 POST requests to /wp-admin/post.php from the test source IP within a few minutes, targeting 10 distinct post IDs.

  2. Test 2Simulate Mass Static Asset Tampering on Web Root (Linux)

    Expected signal: File-modification events (Sysmon Event ID 11 / auditd) for 6 distinct files under /tmp/atomictest-webroot within seconds of each other, written by a shell process.

  3. Test 3Simulate Mass Static Asset Tampering on IIS Web Root (Windows)

    Expected signal: MDE DeviceFileEvents / Sysmon Event ID 11 entries for 5 distinct files under C:\atomictest\wwwroot within seconds, with InitiatingProcessFileName = powershell.exe.

Unlock playbooks & atomic tests with Pro

Get the full detection package for THREAT-Impact-PublicWebsiteDefacement — response playbook and atomic red team tests, plus investigation guidance and hunting queries.

df00tech Pro — £29/user/month

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections

Tactic Hub