> For the complete documentation index, see [llms.txt](https://blog.r00t-hunter.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.r00t-hunter.com/ad-lab-built-with-purpose/attack-scenarios.md).
# Attack Scenarios
Eight scenarios structured to chain sequentially. Each scenario documents the technique, the tooling used, and equally important the detection surface at that step.
**Critical framing note:** This attack chain is engineered for traversability in this specific lab. Every privilege path exists intentionally. Real environments break these chains at multiple points stale credentials, blocked lateral movement paths, inconsistent admin right assignments, unexpected MFA enrollment, and firewall rules nobody documented. The clean chain here exists for technique study and detection surface validation, not as a claim about typical enterprise difficulty.
#### **Scenario 01 - Initial Access**
*Phishing Delivery to Stage-1 Implant via HTTPS*
> *"Phishing works because trust is easier to exploit than software."*\
> — **r00t-hunter**
GoPhish campaign targeting sjones (HR) and mchen (Finance). Pretext is an HR policy update from a domain mimicking usa.corp.local. Payload is an Office macro staging an implant via HTTPS C2.
The foothold lands as sjones a standard user with no elevated privileges. Escalation is a separate phase.
**Tools:** GoPhish, Havoc C2, Office macro, HTTPS staging
**Lab note:** GoPhish delivery through the Postfix relay requires manually setting the From header and configuring relay acceptance on MAIL-USA. The first run usually results in mail sitting in the Postfix queue pending relay configuration tuning.
**Detection surface:** Suricata on outbound HTTPS to unknown destinations; Sysmon EventID 1 for Office spawning unexpected child processes; Wazuh FIM on new executable drops in user temp paths.
***
#### **Scenario 02 - Credential Acquisition**
*LSASS Memory Extraction*
> *"LSASS is a vault that opens itself if you knock the right way."*\
> — **r00t-hunter**
From the sjones session on WS-USA-01, identify higher-privileged sessions present on the same host. In this lab, lpark is logged in because the build phase explicitly creates that profile. In a real environment you may find no other sessions on the same workstation and need to move laterally first.
LSASS dump is processed offline on Kali.
**Tools:** mimikatz.exe, custom LSASS loader
**Detection surface:** Sysmon EventID 10 process access targeting lsass.exe from a non-allowlisted process. Access rights filter: 0x1010, 0x1410, 0x1FFFFF real loaders vary; treat any of these from a non-allowlisted process as suspicious. This fires regardless of loader implementation the kernel-level access event is consistent across approaches. Allowlist maintenance matters here: legitimate security tooling and backup agents access LSASS regularly, so an incomplete allowlist generates noise.
***
#### **Scenario 03 - Lateral Movement**
*Pass-the-Hash via WMI*
> *"The hash travels where the password never went."*\
> — **r00t-hunter**
With lpark's NTLM hash, authenticate to WS-USA-03 via WMI execution. WMI is preferable to service-based approaches because it does not create a new Windows service no EventID 7045. SMB activity is also less distinctive in Zeek's `smb_files.log`.
**Tools:** wmiexec.py, CrackMapExec, Pass-the-Hash
**Detection surface:** EventID 4624 LogonType=3 with NTLMSSP from a workstation IP to WS-USA-03. Behavioral correlation: no prior interactive logon for lpark on that source workstation in the preceding window. Zeek `ntlm.log` correlated with host-layer EventID.
***
#### **Scenario 04 - Privilege Escalation**
*Kerberoasting to DACL Abuse to DCSync*
> *"A service ticket cracked is a domain admin forged."*\
> — **r00t-hunter**
From WS-USA-03, request a TGS for svc\_backup's SPN. The TGS is RC4-encrypted (etype 0x17). Crack offline with hashcat mode 13100.
With svc\_backup credentials, verify via BloodHound whether a DACL abuse path exists. In this lab, svc\_backup has WriteDACL on DC-USA as a GPO delegation artifact. The intended path is to write the two replication GUIDs required for DCSync:
* `DS-Replication-Get-Changes` — `1131f6aa-9c07-11d1-f79f-00c04fc2dcd2`
* `DS-Replication-Get-Changes-All` — `1131f6ad-9c07-11d1-f79f-00c04fc2dcd2`
This produces a full NT hash dump of the domain.
**Detection surface:** EventID 4662 where Properties contains GUID `1131f6ad-9c07-11d1-f79f-00c04fc2dcd2` AND SubjectUserSid is not a DC machine account. High-confidence in this lab with a maintained DC allowlist. In practice, allowlist accuracy requires ongoing attention as DC inventory changes.
***
#### **Scenario 05 - Persistence**
*Golden Ticket and AdminSDHolder ACL Backdoor*
> *"The krbtgt key is the master watchtower. Steal it and time bends to you."*\
> — **r00t-hunter**
With the krbtgt NT hash from DCSync, forge a Golden Ticket with extended validity. Note: invalidating a forged ticket requires two consecutive krbtgt password rotations spaced at least 10 hours apart.
Secondary persistence: write a controlled account's SID into AdminSDHolder's nTSecurityDescriptor as a GenericAll ACE. SDProp propagates AdminSDHolder ACL changes to all protected group members every 60 minutes. That propagation window is your incident response window.
**Detection surface:** EventID 5136 where ObjectDN is `CN=AdminSDHolder,CN=System,DC=usa,DC=corp,DC=local` and AttributeLDAPDisplayName is `nTSecurityDescriptor`. Any modification outside a documented change window warrants immediate investigation.
***
#### **Scenario 06 - Cross-Forest Trust Path**
*Inter-Realm Trust Ticket with ExtraSids PAC Injection*
> *"Trust without filtering is a bridge with no guards."*\
> — **r00t-hunter**
As DA on usa.corp.local, retrieve the trust account hash for the `india$` account. This account holds the shared Kerberos secret for inter-realm referrals. Forge an inter-realm TGT using this trust key with the Enterprise Admins SID of usa.corp.local in the PAC ExtraSids field.
**Whether this works depends entirely on SID filtering.** SID filtering is not enabled by default on external trusts. Verify the current state before assuming the path exists:
```
netdom trust usa.corp.local /domain:india.corp.local /quarantine
```
In this lab, SID filtering is disabled. In an environment with SID filtering enabled, this path stops at the trust boundary which is the correct defensive configuration.
**Detection surface:** EventID 4769 cross-domain ticket requests; anomalous ExtraSids values in PAC data; unexpected authentication events in india.corp.local originating from usa.corp.local accounts.
***
#### **Scenario 07 - Exfiltration**
*DNS Tunneling and Chunked HTTPS*
> *"Every allowed protocol is an exfiltration highway if you drive slowly enough."*\
> — **r00t-hunter**
Two channels tested independently: dnscat2 for DNS-encoded exfiltration, and chunked HTTPS POST to the C2 endpoint. The purpose is testing whether the detection stack catches either channel DNS query volume anomaly in Zeek `dns.log`, or HTTP POST pattern or neither.
Under load, the 4 GB Security Onion in this lab sometimes misses Zeek `dns.log` entries due to capture buffer pressure. This is a hardware sizing limitation, not a real detection gap. Know the difference before drawing conclusions from timing data.
**Tools:** dnscat2, Havoc HTTPS C2, chunked base64 POST
***
#### **Scenario 08 - Impact Measurement**
*Controlled Rename Simulation for SOC Response Timing*
> *"The goal is not to stop the first rename. It's to stop the thousandth."*\
> — **r00t-hunter**
A Python script authenticates to accessible SMB shares via DA credentials, enumerates files matching common document extensions across both file servers, and renames each with a `.enc` extension alongside a ransom note. Only pre-seeded test files are affected.
The purpose is not ransomware research. It is measuring whether Security Onion detects the volume of SMB rename operations in Zeek's `smb_files.log`, and what the elapsed time is between first rename and first alert. In this lab with 4 GB Security Onion under full indexing load, alert delay was 3–5 minutes. That number is meaningful only for confirming that the detection logic fires at all not for SOC benchmarking.
**Tools:** Custom Python SMB client, Impacket smbclient
#### Attack Chain Summary
```
WS-USA-01 [sjones — standard HR user]
└─ LSASS dump → lpark NTLM hash
└─ WMI PtH → WS-USA-03 (no service creation, no event 7045)
└─ LDAP enumeration → BloodHound graph
└─ Kerberoast svc_backup (RC4 / etype 0x17) → hashcat 13100
└─ svc_backup credentials → WriteDACL on DC-USA
└─ DCSync → krbtgt NT hash → usa.corp.local full compromise
└─ Trust ticket + ExtraSids → india.corp.local access
(only if SID filtering disabled on trust)
```
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://blog.r00t-hunter.com/ad-lab-built-with-purpose/attack-scenarios.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.