Detect Compromised WordPress Sites Weaponized as Malware Distribution Redirectors in Splunk
Rather than standing up adversary-registered infrastructure that carries no reputation and is trivially blocked, actors including TA569 (SocGholish), the Gootloader crew, and Parrot TDS operators mass-compromise legitimate, high-reputation WordPress sites — typically via outdated plugins, stolen admin credentials, or vulnerable themes — and repurpose them as first-stage redirectors and payload-staging hosts. A compromised site is injected with obfuscated JavaScript (a 'fake update' overlay for SocGholish, or SEO-poisoned legal-document lures for Gootloader) that fingerprints the visitor and conditionally redirects first-time, non-crawler visitors through a traffic-distribution-system (TDS) chain to the actor's actual payload or phishing kit, while returning normal content to repeat visitors, bots, and security scanners. Because the compromised domain has years of clean history, a real TLS certificate, and legitimate unrelated content, domain-reputation-based blocking is ineffective; detection must instead focus on (1) the injected-script/traffic-fingerprinting pattern in outbound web traffic, (2) DNS and HTTP indicators of TDS chaining (rapid multi-hop redirects with cloaking headers), and (3) the file-drop/execution pattern that follows a user visiting an otherwise-reputable site and immediately downloading and running an unsigned binary.
MITRE ATT&CK
- Tactic
- Resource Development
SPL Detection Query
| union
[
search index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
TargetFilename IN ("*\\Downloads\\*.js", "*\\Downloads\\*.zip", "*\\Downloads\\*.msi", "*\\Downloads\\*.exe", "*\\Downloads\\*.hta", "*\\Temp\\*.js", "*\\Temp\\*.hta")
Image IN ("*\\chrome.exe", "*\\msedge.exe", "*\\firefox.exe")
| eval DownloadTime=_time
| table DownloadTime, host, TargetFilename, Image
| join type=inner host
[ search index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
ParentImage IN ("*\\chrome.exe", "*\\msedge.exe", "*\\firefox.exe", "*\\explorer.exe")
Image IN ("*.js", "*.hta", "*.msi", "*.exe")
| eval ExecTime=_time
| table ExecTime, host, Image, CommandLine ]
| where (ExecTime - DownloadTime) >= 0 AND (ExecTime - DownloadTime) <= 600
| eval SuspicionReason="DownloadThenExecuteWithinTenMinutes"
| table DownloadTime, ExecTime, host, TargetFilename, Image, CommandLine, SuspicionReason
]
[
search index=proxy sourcetype="*proxy*"
| eval Process=coalesce(app,"browser")
| bin _time span=15s
| stats dc(url) as HopCount, values(url) as Hosts, min(_time) as FirstHop, max(_time) as LastHop by host, _time
| where HopCount >= 4
| eval SuspicionReason="RapidMultiHopRedirectChain"
| table FirstHop, LastHop, host, HopCount, Hosts, SuspicionReason
]
| sort - DownloadTimeTwo-source detection combining Sysmon Event ID 11/1 correlation (download-then-execute within 10 minutes from a browser process) with proxy-log-derived redirect-chain analysis (4+ distinct URLs touched by the same host within a 15-second bucket). Requires Sysmon with file-create and process-create logging plus a web proxy sourcetype with per-request URL visibility.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Legitimate self-updating software downloading and launching an installer within the correlation window
- Ad-exchange real-time-bidding redirect chains that legitimately touch many hostnames within seconds
- SSO/identity-provider login flows with multiple redirect hops through gateway and CDN infrastructure
- Users downloading and manually launching a vendor-provided installer shortly after browsing to the vendor's site
Other platforms for THREAT-Infra-CompromisedWordPressRedirector
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.
- Test 1Browser Download Followed by Rapid Script-Host Execution (Fake-Update Simulation)
Expected signal: Sysmon Event ID 11: file creation at Downloads\atomic_update.js by powershell.exe. Sysmon Event ID 1: wscript.exe launching atomic_update.js roughly 2 seconds later, with ParentImage referencing the shell chain rather than a browser (adjust InitiatingProcessFileName filter to powershell.exe for this simulation).
- Test 2Simulated Multi-Hop Redirect Chain via Sequential curl Requests
Expected signal: Sysmon Event ID 3 / DeviceNetworkEvents: four outbound connections from powershell.exe to four distinct hostnames within approximately 3 seconds.
- Test 3Same Referring URL Accessed From Multiple Simulated Hosts (SEO-Poisoning Pattern)
Expected signal: Sysmon Event ID 3 / proxy logs: outbound HTTPS request to example.com with the atomic_test_lure query string logged.
References (5)
- https://attack.mitre.org/techniques/T1584/006/
- https://attack.mitre.org/tactics/TA0042/
- https://www.proofpoint.com/us/blog/threat-insight/socgholish-fake-browser-updates
- https://www.sophos.com/en-us/threat-center/threat-monitoring/threat-analyses/gootloader
- https://blog.talosintelligence.com/traffic-direction-systems/
Response Playbook
Triage
- Identify the referring page the user visited immediately before the download — pull browser history for the URL and confirm whether it is a normally-reputable, previously-visited site (a strong sign it may be a compromised legitimate site rather than adversary-owned infrastructure).
- Check the downloaded file's content: fake-update lures typically deliver a heavily obfuscated .js file (SocGholish) or a password-protected .zip containing an .lnk/.js stub (Gootloader). Extract and review the script for eval(), atob(), or long hex/base64 blobs.
- Determine whether the file was executed and, if so, what child processes it spawned — SocGholish commonly spawns a fingerprinting PowerShell chain; Gootloader spawns a WSH-based multi-stage loader that ultimately deploys Cobalt Strike or a ransomware precursor.
- Pull the full sequence of URLs visited in the seconds before the download landed (proxy/browser history) to reconstruct the TDS redirect chain and identify how many hops separated the original benign-looking site from the final payload host.
- Check whether other internal users visited the same referring URL/site in the same timeframe — a single compromised page is often served to many internal visitors, especially for SEO-poisoned Gootloader lures tied to specific search terms (e.g., 'agreement template').
- Fingerprint the compromised site itself if possible (from an isolated research host): view page source for injected <script> tags referencing unfamiliar domains, or check if the site is running an outdated WordPress/plugin version consistent with known mass-exploitation waves.
- Submit the payload hash to VirusTotal/sandbox and confirm the malware family (SocGholish loader, Gootloader, or other TDS-delivered payload) to determine the appropriate downstream response playbook.
Containment
- Isolate the endpoint via EDR network isolation if the downloaded file was executed, pending sandbox/forensic confirmation of payload behavior.
- Block the final payload-hosting domain and any intermediate TDS-chain hostnames at the web proxy/firewall — do NOT blanket-block the original compromised legitimate site if it serves other business-critical content; instead block only the malicious path/injected-script domain if separable.
- If the payload executed and established C2 (common with SocGholish -> Cobalt Strike chains), assume the host is compromised: capture memory, disable the account's active sessions, and reimage.
- Notify the compromised site's owner/webmaster (via WHOIS abuse contact or security.txt) if it is a third-party site your organization does not control, so they can remediate the underlying WordPress/plugin vulnerability.
- Hunt for the same payload hash, C2 indicators, and referring-site pattern across the environment to scope how many users were exposed to the same SEO-poisoned lure or fake-update campaign.
- If the lure was SEO-poisoning tied to a specific search term, add the term + payload domain combination to web-filtering categories and brief the security-awareness team on the specific lure theme observed.
Evidence Collection
- Full browser history and download manager records showing the referring page, the download URL, and every redirect hop in between.
- The injected JavaScript/HTML from the compromised page (captured via view-source or an archived crawl) showing the fingerprinting and conditional-redirect logic.
- Sysmon Event ID 11 (file creation) and Event ID 1 (process creation) for the downloaded file and any subsequent execution chain, including full command lines.
- Proxy/firewall logs enumerating every hostname touched during the redirect chain, with timestamps tight enough to reconstruct hop-by-hop timing.
- The payload sample itself (hashed, and submitted for sandbox detonation) along with any dropped second-stage artifacts.
- DNS query logs for both the compromised legitimate domain and every TDS-chain/payload domain observed, to identify other potentially affected hosts.
Escalation Criteria
- !The downloaded payload executed and sandbox analysis confirms a known loader family (SocGholish, Gootloader) with active C2 callback or Cobalt Strike beacon deployment.
- !Multiple internal users were exposed to the same compromised site or SEO-poisoned search result within a short window, indicating broad exposure rather than a single incident.
- !The compromised site is a vendor, partner, or industry-association site with an ongoing business relationship, requiring coordinated disclosure and possibly legal/procurement notification.
- !Post-execution telemetry shows credential access, lateral movement tooling staging, or ransomware precursor behavior (common Gootloader -> ransomware affiliate handoff pattern).
- !The affected host belongs to a privileged user (IT admin, finance, executive) where a successful loader deployment carries outsized blast radius.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Browser cache/history SQLite databases showing the full navigation and redirect sequence leading to the download. - >
Sysmon Event ID 22 (DNS Query) and Event ID 3 (Network Connection) for every hostname in the TDS chain, correlated by ProcessGuid. - >
Sysmon Event ID 11 (File Create) for the initial download and any dropped second-stage files. - >
Prefetch entries for wscript.exe/cscript.exe/powershell.exe confirming execution of the fake-update or fake-document payload. - >
Windows Registry Run keys or scheduled tasks created by the loader for persistence, if execution proceeded past initial access. - >
Any locally-cached copy of the injected JavaScript or the compromised page's HTML for static analysis of the fingerprinting/redirect logic.
Tuning Guidance
This detection targets behavioral symptoms (download-then-execute timing, redirect-chain hop count) precisely because domain reputation is useless against a compromised legitimate site. Tuning recommendations: (1) Build an allowlist of known enterprise software auto-updaters (Chrome, Edge, Zoom, Slack) that legitimately download-then-execute within the correlation window — fingerprint by publisher/signature rather than filename to resist renaming; (2) For the redirect-chain pillar, exclude known ad-exchange and CDN-edge hostname patterns from the hop count, since legitimate RTB auctions can trigger 4+ hops; (3) Prioritize alerts where the download file class is a script (.js/.hta) rather than a signed installer, since scripts are rarely a legitimate auto-update mechanism; (4) Cross-reference the referring URL against recent web-filtering category changes — sites that were previously categorized as benign (e.g., a local business or association site) and suddenly serve unusual JS are higher-confidence compromises than freshly-registered domains; (5) Where available, integrate with a URL-reputation feed that tracks known TDS/traffic-broker infrastructure (9hits, keitaro-style TDS panels) to convert the hop-count heuristic into a higher-confidence IOC match against known relay hosts.
Hunting Queries
Broad hunt widening beyond the primary detection's file-extension filter — catches renamed or extensionless downloads that are still executed via a scripting engine shortly after a browser download, a pattern common to Gootloader's evolving delivery chain.
// Hunt: Browser-initiated download immediately followed by WSH/PowerShell execution of that file, regardless of extension
DeviceFileEvents
| where Timestamp > ago(14d)
| where FolderPath has_any (@"\Downloads\", @"\Temp\")
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","firefox.exe")
| project DownloadTime=Timestamp, DeviceName, FileName, SHA256
| join kind=inner (
DeviceProcessEvents
| where Timestamp > ago(14d)
| where FileName in~ ("wscript.exe","cscript.exe","powershell.exe","mshta.exe")
| project ExecTime=Timestamp, DeviceName, ExecCommandLine=ProcessCommandLine
) on DeviceName
| where ExecTime between (DownloadTime .. DownloadTime + 15m)
| summarize Count=count(), SampleCmd=any(ExecCommandLine) by FileName, bin(DownloadTime, 1d)
| order by Count descindex=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
TargetFilename IN ("*\\Downloads\\*","*\\Temp\\*")
Image IN ("*\\chrome.exe","*\\msedge.exe","*\\firefox.exe")
| eval DownloadTime=_time
| join type=inner host
[ search index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
Image IN ("*\\wscript.exe","*\\cscript.exe","*\\powershell.exe","*\\mshta.exe")
| eval ExecTime=_time | table ExecTime, host, Image, CommandLine ]
| where (ExecTime - DownloadTime) >= 0 AND (ExecTime - DownloadTime) <= 900
| stats count as Count, values(CommandLine) as SampleCmds by TargetFilename
| sort - CountHunt for a single URL accessed by three or more distinct internal hosts within a week — since SEO-poisoning and mass-WordPress-compromise campaigns serve the same malicious lure page to many organic search visitors, multiple internal users independently reaching the identical URL is a strong indicator of a shared compromised-site campaign rather than isolated browsing.
// Hunt: Same referring URL/site visited by 3+ distinct internal hosts followed by a download event within the hour (SEO-poisoning / mass-compromise indicator)
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","firefox.exe")
| summarize UniqueDevices=dcount(DeviceName), Devices=make_set(DeviceName, 20) by RemoteUrl
| where UniqueDevices >= 3
| order by UniqueDevices descindex=proxy sourcetype="*proxy*"
| stats dc(host) as UniqueDevices, values(host) as Devices by url
| where UniqueDevices >= 3
| sort - UniqueDevicesAtomic Red Team Tests
Downloads a benign .js file via PowerShell (simulating a browser download into the Downloads folder) and immediately executes it with wscript.exe, replicating the download-then-execute timing signature of a SocGholish-style fake browser-update lure without using any actual malicious code.
Command
powershell.exe -Command "'WScript.Echo(\"atomic-test\")' | Out-File -FilePath $env:USERPROFILE\Downloads\atomic_update.js -Encoding ASCII; Start-Sleep -Seconds 2; wscript.exe $env:USERPROFILE\Downloads\atomic_update.js"Cleanup
Remove-Item $env:USERPROFILE\Downloads\atomic_update.js -Force -ErrorAction SilentlyContinueExpected Telemetry
Sysmon Event ID 11: file creation at Downloads\atomic_update.js by powershell.exe. Sysmon Event ID 1: wscript.exe launching atomic_update.js roughly 2 seconds later, with ParentImage referencing the shell chain rather than a browser (adjust InitiatingProcessFileName filter to powershell.exe for this simulation).
Expected Detection
KQL/SPL Pillar 1 fires on the download-to-execution correlation within the 10-minute window; SuspicionReason=DownloadThenExecuteWithinTenMinutes. Note: this atomic simulates the timing pattern using PowerShell as the download agent — for a fully faithful browser-originated test, manually download a benign .js file via Chrome/Edge and execute it with wscript.exe.
Issues four sequential HTTPS requests to distinct benign domains within a 10-second window using curl, simulating the timing signature of a TDS (traffic distribution system) redirect chain that hops a victim through several hostnames before landing on the final payload host.
Command
powershell.exe -Command "$hosts=@('example.com','httpbin.org','wikipedia.org','cloudflare.com'); foreach($h in $hosts){ try { Invoke-WebRequest -Uri \"https://$h\" -UseBasicParsing -TimeoutSec 3 | Out-Null } catch {}; Start-Sleep -Milliseconds 500 }"Expected Telemetry
Sysmon Event ID 3 / DeviceNetworkEvents: four outbound connections from powershell.exe to four distinct hostnames within approximately 3 seconds.
Expected Detection
KQL/SPL Pillar 2 fires on HopCount >= 4 within the 15-second window for the initiating process, SuspicionReason=RapidMultiHopRedirectChain. Expect this to require tuning against automation/scripting processes since the primary detection targets browser processes specifically.
Uses PowerShell to generate repeated requests to a single benign URL with a distinctive query string, simulating the pattern hunted for in the SEO-poisoning/mass-compromise hunting query — multiple internal endpoints independently reaching an identical malicious lure URL.
Command
powershell.exe -Command "Invoke-WebRequest -Uri 'https://example.com/?atomic_test_lure=agreement-template' -UseBasicParsing -TimeoutSec 3 | Out-Null"Expected Telemetry
Sysmon Event ID 3 / proxy logs: outbound HTTPS request to example.com with the atomic_test_lure query string logged.
Expected Detection
Hunting query for same-URL-multiple-devices fires only when run from 3+ distinct simulated/real hosts within the lookback window — run this atomic from multiple test endpoints to validate the hunt logic end-to-end.