Honeynet Collapse: Full Kill Chain from Public Web Application to Domain-Wide Compromise

1. Executive Summary

Between the initial compromise of a public-facing WordPress host and the final exfiltration of customer data from an internal CRM application server, a single threat actor progressed through five distinct internal systems over the course of a multi-day campaign, culminating in domain controller compromise, ransomware deployment, and a parallel, opportunistic compromise of an unrelated macOS developer workstation. Rather than exploiting a software vulnerability at any stage, the actor relied almost entirely on credential brute-forcing, abuse of legitimate administrative functionality, and living-off-the-land techniques, a pattern that persisted across every host in the chain and is the single most consistent signature of this campaign. Investigation of the full chain required six materially different evidence sources, web-server access logs, host-based audit logging, Volatility 3 memory forensics, Windows Event Log and registry analysis, NTFS metadata-only artifact recovery, and macOS-specific artifact parsing, because the actor deliberately disabled or cleared logging at three separate points in the chain. In every instance, the investigation was able to proceed by pivoting to an artifact category that survives the specific anti-forensic technique used, a pattern that itself became a repeatable methodology over the course of the engagement rather than a one-off improvisation at each stage.

2. Campaign Scope & Methodology

Six independent evidence packages were provided for this campaign, corresponding to the five compromised hosts plus one standalone memory capture: a web-server and host-audit log set for the WordPress host and its underlying Linux server, a full memory capture from a DMZ gateway server reached via lateral movement, a forensic disk image (E01) of a CRM application server, a metadata-only NTFS image (no user files, registry, or event logs) from a domain controller, and a macOS forensic disk image from an unrelated developer workstation, investigated as a parallel, opportunistic incident rather than a continuation of the same intrusion path. Each package was analyzed independently first, using the artifact categories appropriate to its evidence type, before being cross-referenced against the others to establish shared infrastructure, credential reuse, and tooling fingerprints. The consolidated methodology below reflects that two-pass approach: per-host technical findings (Section 4) followed by a dedicated cross-stage correlation pass (Section 6) that was not possible, and was not attempted, at the level of any single constituent report.

# Representative toolchain across the six evidence packages
# Web / Linux host
sudo ausearch -k exec -i
grep "wp-login" /var/log/apache2/access.log

# Windows log source triage (gateway, CRM, DC where available)
Get-WinEvent -ListLog * | Where-Object {$_.RecordCount -gt 0}
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102}   # log-clear marker
AppCompatCacheParser.exe --csv <out> --csvf shimcache_parsed.csv

# Memory forensics (DMZ gateway capture)
vol -f <capture> windows.pstree
vol -f <capture> windows.malfind
vol -f <capture> windows.netscan

# NTFS metadata-only image (domain controller)
MFTECmd.exe -f "<path>\$MFT" --csv "<out>" --csvf mft_parsed.csv
LogFileParser64.exe /LogFileFile:"<path>" /MftCsvFile:"mft_parsed.csv" /OutputPath:"<out>"

# macOS disk image
python3 mac_apt.py MOUNTED <verified_root> QUARANTINE TCC AUTOSTART INSTALLHISTORY -o <out>

3. Affected Systems

Stages 1 through 5 form a single, continuous intrusion path: the web host is the entry point, the gateway server and CRM server are successive internal pivots reached with credential material obtained earlier in the chain, and the domain controller is the terminal objective. Stage 6, the macOS workstation, is investigated and reported separately in its own right. Nothing in its evidence links it to the same threat actor or infrastructure, and it is included in this consolidated report only because it was issued as part of the same training series, not because it is part of the same kill chain.

4. Campaign Timeline (Stages 1-5)

The table below sequences the reconstructed activity across all five hosts in the main intrusion path onto a single relative timeline. Because each host's evidence package used a different reference clock (web-server logs, Windows Event Log timestamps, and NTFS metadata each anchor differently), absolute cross-host time alignment was not possible from the available evidence. The sequence below reflects the confirmed logical order of events (each stage's start depends on credential or access material obtained in the previous stage), not a verified shared clock.

5. Stage-by-Stage Technical Findings

6. Cross-Stage Analysis

Three patterns recur across Stages 1 through 5 clearly enough to be treated as campaign-level findings rather than isolated, per-host observations.

Escalating anti-forensics, not static tradecraft. The actor's approach to evading detection intensified at each stage rather than repeating a fixed playbook. Stage 2 cleared the Windows Security log once, after the fact, leaving a detectable log-clear marker as a timeline boundary. Stage 4 disabled the Event Log and Sysmon services outright, mid-session, preventing any record from being written at all rather than clearing one after the fact, a strictly more thorough technique. Stage 5, facing an evidence source with no logging infrastructure to disable in the first place (a metadata-only acquisition), relied instead on rename-then-execute file-level evasion. Read in sequence, this is not three unrelated anti-forensic choices but a single actor's technique maturing across the engagement, and it directly explains why no single evidence category, Event Logs, registry, or filesystem metadata, was sufficient on its own anywhere in this campaign.

Credential reuse as the connective tissue of the campaign. No stage after the first required a new exploitation technique to gain a foothold. Every lateral move, Stage 1 to Stage 2 (RDP with a domain account), Stage 2 to Stage 4 (reused domain credentials on the CRM server), was authenticated with material harvested at an earlier stage rather than a fresh compromise. This is the single strongest piece of evidence tying Stages 1, 2, and 4 together as one continuous intrusion rather than three coincidentally similar incidents, and it is also the campaign's clearest single point of failure from a defensive standpoint: interrupting credential reuse at any one hop, through segmentation, credential rotation, or privileged-account monitoring, would have contained the campaign to a single host.

A consistent recovery methodology, not five unrelated workarounds. Every time the actor removed or disabled a primary evidence source, the investigation resolved it by pivoting to an artifact category that survives that specific technique, and the same small set of fallback sources recurs deliberately across stages: registry-based usage and execution tracking (UserAssist in Stage 4, Shimcache in Stage 2) when the Event Log subsystem was disabled or cleared, shell and command history when privilege escalation moved activity outside audit-rule scope, and memory forensics (Stage 3) when no log source existed for a host at all. Framed at the campaign level, this is not five separate investigative improvisations but one repeatable principle applied five times: identify what the anti-forensic technique in play cannot reach, and go there first.

7. Consolidated Indicators of Compromise

8. Consolidated MITRE ATT&CK Mapping (Full Kill Chain)

9. Root Cause Analysis

Primary cause. The campaign originated from a public-facing web application with no rate limiting on its authentication endpoint, allowing credential brute-forcing to succeed within roughly one minute. Every subsequent stage of the campaign, five additional hosts, was reachable using either functionality already present on the compromised host (the Theme Editor, an exposed key backup) or credential material harvested at the previous stage. At no point did the actor need a software vulnerability to progress.

Contributing factors.

• No account lockout or rate limiting on the public authentication endpoint that served as the campaign's entry point.
• Predictable, web-accessible storage of a private key backup file, providing root-equivalent access with no further exploitation required.
• Domain credentials valid across multiple internal hosts (web host, gateway, CRM server) with no apparent segmentation or step-up authentication between them.
• Audit logging scoped to individual service accounts rather than extended to cover privilege-escalated activity, creating a documented blind spot the moment any account reached root or SYSTEM.
• Event Log and Sysmon services stoppable by a standard administrative session, with no independent, host-external forwarding to prevent local tampering from blinding central monitoring.
• No memory-capture or equivalent volatile-evidence collection built into standard incident response readiness for at least one host in the chain, a gap only avoided in this campaign because Volatility 3 analysis happened to be available for the DMZ gateway server specifically.

Evidentiary limitations. Absolute time correlation across all five hosts in the main intrusion path was not possible from the available evidence, since each host's evidence package anchored to a different reference clock and no single cross-host timestamp source (e.g., a centralized SIEM ingesting all five hosts) was provided. The Campaign Timeline in Section 4 reflects confirmed logical sequencing, not verified absolute chronology. The domain controller acquisition (Stage 5) was deliberately scoped to NTFS metadata only, meaning no registry, process, or network evidence exists for that host beyond what filesystem metadata could recover. Any findings requiring those artifact types on that specific host could not be pursued within this campaign's evidence.

10. Recommendations

1. Enforce account lockout or rate limiting on all public-facing authentication endpoints. This single control would have prevented the campaign's entry point entirely.
2. Rotate and segment domain credentials so that a single compromised account cannot authenticate across web-facing, gateway, and internal application-server roles. Credential reuse was the connective thread of this entire campaign.
3. Forward Event Log and Sysmon telemetry to a centralized, host-independent SIEM. Local service stoppage and log clearing were used at two separate stages and would not have blinded a properly externalized logging pipeline.
4. Extend audit logging scope beyond individual service-account UIDs to cover privilege-escalated activity, which went dark at multiple points in this campaign the moment an account reached root or SYSTEM.
5. Treat registry-based artifacts (UserAssist, Shimcache) and default-on shell history as standard, first-pass triage sources on every Windows host investigation, not fallbacks reached only once Event Logs are found to be unavailable.
6. Build memory-capture capability into standing incident-response readiness across all critical hosts. The DMZ gateway server investigation in this campaign would not have been possible from disk or log artifacts alone.
7. Restrict outbound access to public file-sharing and consumer cloud-storage services from servers handling sensitive data or holding domain-controller privileges.

11. Investigator's Notes

Investigating each stage in isolation, as the individual constituent reports do, is sufficient to answer "what happened on this host." It is not sufficient to answer "what is this actor's operating pattern," and that second question only became answerable once all five hosts were read together. The escalating anti-forensics pattern in Section 6, in particular, was not visible from any single report. It required noticing that Stage 2 cleared a log after the fact, Stage 4 disabled logging before the fact, and Stage 5 faced an environment with no logging to disable at all, and recognizing that ordering as deliberate escalation rather than three unrelated choices. This is the main practical lesson carried forward from this exercise: a campaign-level view, built by deliberately re-reading completed, individually-closed investigations against each other, surfaces actor behavior that per-incident reporting alone does not, and is worth doing even after each constituent case has already been closed.