Web Application Compromise to Windows Lateral Movement
| Report ID | SIR-2026-06-22-01 | Classification | Simulated / Training Environment |
| Analyst | F. Nanos | Date of Report | 2026-06-22 / 23 |
| Severity | Critical | Status | Closed (Contained) |
| Affected Assets | 1x public-facing WordPress host, 1x internal Windows server | ||
1. Executive Summary
A two-stage intrusion was reconstructed spanning a public-facing WordPress host and an internal Windows server. The threat actor gained initial access to the web application via credential brute-forcing, escalated to code execution by abusing a built-in content-management feature to plant a disguised web shell, and achieved local privilege escalation through an exposed SSH key backup. Using credentials obtained during this phase, the actor pivoted to an internal Windows host, hijacked a legitimate scheduled task to obtain elevated code execution, dumped credential material from memory, and cleared the host's security event log mid-session before moving laterally toward a further internal target. Every technique observed abused legitimate, documented functionality rather than exploiting a software vulnerability, and the actor's clearing of security logging required the investigation to rely on artifacts that survive this class of anti-forensic activity.
2. Scope & Methodology
Investigation of the web-facing host relied on host-based audit logging (scoped to the web service account) cross-referenced with web-server access logs. Investigation of the Windows host began with standard Security-log review, but pivoted through several artifact layers, RDP-specific operational logs, PowerShell transcription, and registry-based execution caching, as each successive log source was found incomplete or deliberately cleared.
# Linux host: audit log review
sudo ausearch -k exec -i
grep "wp-login" /var/log/apache2/access.log
# Windows host: log source triage
Get-WinEvent -ListLog * | Where-Object {$_.RecordCount -gt 0}
wevtutil epl "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" <out.evtx>
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}
# Registry-based execution cache (survives Security log clearing)
AppCompatCacheParser.exe --csv <out> --csvf shimcache_parsed.csv
3. Technical Findings
3.1 Initial Access (Web Application)
Web-server access logs identified sustained credential brute-forcing against the WordPress login endpoint, succeeding after approximately one minute of attempts. The same source subsequently accessed the platform's built-in theme-editing feature and repeatedly saved a modified template file, a documented content-management capability requiring no vulnerability, resulting in arbitrary PHP execution once an authenticated session was obtained.
3.2 Web Shell & Local Privilege Escalation
The planted code was disguised using a parameter name closely resembling WordPress's legitimate cron-trigger mechanism, reducing its visibility during casual log review. Host-based audit logging (scoped to the web-service account) captured the resulting command execution, including reconnaissance, a reverse-shell callback, and a targeted search for private key material that recovered an exposed SSH key backup file. This key was used to authenticate directly as root, completing local privilege escalation without further exploitation.
3.3 Post-Escalation Activity & Persistence (Web Host)
Root-level shell history, the only available evidence source once privilege escalation placed activity outside the scope of the service-account-restricted audit rules, recorded an internal network sweep, targeted port probing against a specific host, retrieval and execution of an additional payload from the same external staging server used for initial access, and establishment of persistence via a disguised system service mimicking a legitimate kernel process name.
3.4 Lateral Movement to Windows Host
Standard Security-log review of the Windows target did not cover the incident window. RDP-specific operational logging, a separate log source unaffected by the same gap, confirmed an inbound connection from the previously compromised web host's IP address, authenticated with a domain account's credentials, consistent with credential material obtained during the initial intrusion phase.
3.5 Privilege Escalation via Scheduled Task Hijack
A legitimate, pre-existing scheduled task configured to run a diagnostic utility with elevated privileges on an hourly basis was found to have its target binary replaced with a payload later confirmed via public threat-intelligence lookup as a known post-exploitation framework stager. No new persistence mechanism was created; an already-trusted, already-elevated execution path was repurposed directly.
3.6 Credential Access
Process-creation logging on the host was enabled but did not capture command-line detail, limiting log-based visibility into subsequent actions. PowerShell transcription, a separate and independently configured logging mechanism, had captured a short encoded command that decoded to a renamed memory-dumping utility targeting the LSASS process. Offline analysis of the resulting memory dump recovered cached credential material for a second, higher-privileged domain account.
3.7 Anti-Forensics & Continued Lateral Movement
The Windows Security event log was found to have been cleared during the incident window, confirmed by the log-clear event that Windows records automatically as the first entry in any newly cleared log, which also served as a reliable timeline boundary marker. Activity following this boundary was reconstructed using a registry-based execution-history artifact unaffected by Security log clearing, which recovered evidence of a renamed remote-execution utility and its associated service installation, indicating a further lateral movement toward an additional internal host.
4. Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Source IP | [redacted] | Brute-force source, reused as RDP source and payload staging host |
| Web shell parameter | [redacted, cron-mimicking parameter name] | Disguised trigger for planted PHP code |
| Exposed key file | [redacted, .bak private key backup] | Root-equivalent credential exposure |
| Persistence service | [redacted, kernel-process-mimicking name] | Linux host persistence |
| Hijacked task | [redacted diagnostic scheduled task] | Windows privilege escalation vector |
| Service artifact | Fixed-name remote-execution service binary | Lateral movement tooling fingerprint, survives client renaming |
5. MITRE ATT&CK Mapping
| Technique ID | Technique | Tactic |
|---|---|---|
| T1110 | Brute Force | Credential Access |
| T1505.003 | Web Shell | Persistence |
| T1552.004 | Credentials in Files (SSH key) | Credential Access |
| T1078 | Valid Accounts | Initial Access, Lateral Movement |
| T1053.005 | Scheduled Task Abuse | Persistence, Privilege Escalation |
| T1003.001 | OS Credential Dumping (LSASS) | Credential Access |
| T1070.001 | Clear Windows Event Logs | Defense Evasion |
| T1021.002 / T1570 | Remote Services / Lateral Tool Transfer | Lateral Movement |
| T1036 | Masquerading | Defense Evasion |
6. Recommendations
- Enforce account lockout or rate limiting on the WordPress authentication endpoint. Brute-forcing succeeded without any apparent throttling.
- Restrict Theme Editor and equivalent code-execution-capable admin features to a smaller, monitored set of trusted accounts, or disable entirely where not required.
- Remove or securely relocate private key backup files from predictable, web-accessible paths. Audit for `.bak` and similar backup-extension files containing credential material.
- Extend audit logging scope beyond single-service-account UIDs to cover privilege-escalated activity, which is currently invisible once an attacker reaches root.
- Enable command-line auditing for process-creation events on Windows hosts. The absence of this detail significantly slowed credential-access detection.
- Forward event logs to a centralized, host-independent SIEM so that local log clearing does not create investigative blind spots.
- Review and restrict scheduled tasks running with elevated privileges for unauthorized modification, particularly those referencing user-writable binary paths.
7. Investigator's Notes
Two log-scoping limitations shaped this investigation. On the web host, audit rules scoped to the service account went blind the moment the actor escalated to root, requiring a pivot to root shell history as the only remaining evidence source. On the Windows host, deliberate Security log clearing created a similar blind spot. The resolution required recognizing that registry-based execution caching operates entirely independently of the Event Log subsystem and survives this class of anti-forensic activity intact. Both lessons are now treated as standing considerations: privilege-scoped audit rules require a documented root-level fallback source, and registry-based artifacts should be checked in parallel with, not only after, Event Log analysis on any Windows host investigation.