6.6.3 One continuous worked AD investigation

§6 — Chapter 6 | 6.6 Study aids

This is one continuous hypothetical investigation. The objective is a verified new host-access capability, not an invented domain-compromise result. All names and observations are synthetic; commands remain references for the later practice phase.

6.6.3.1 Starting state and first question

Assume a supplied low-privilege EXAMPLE\analyst identity and a usable domain query route. Verify the token/network identity and domain/DC context. The account is a member of Support; the group name is not an administrative right.

§6.1.1.1 — Establish the current identity and domain

§6.2.1.1 — Baseline enumeration — users and groups

6.6.3.2 A readable file creates a scoped lead

SYSVOL is readable. A selected logon script names FS01\Finance. This proves a readable reference, not Finance access. Add the host/share to the investigation map, establish scope/address and test the selected operation with the current identity.

§6.2.2.1 — Enumerate shares, SYSVOL and NETLOGON

§6.2.6.1 — Validate host-specific access rights

6.6.3.3 Dead end: listing did not grant the wanted read

SMB authenticates and lists Finance, but the selected configuration file is denied. Keep the valid identity and listing evidence. Close the claim that its contents or credentials are known. Do not repeat the denied read unchanged; return only after a relevant identity/right change.

§6.5.1.1 — Diagnose the failed boundary

6.6.3.4 A service clue does not settle the attack

An SPN identifies svc_reports on DB01. Its useful rights and password feasibility are unknown. Record the account/service relationship, then rank it against stronger existing evidence; do not request every ticket merely because a service registration exists.

§6.2.4.1 — Enumerate service accounts and SPNs

6.6.3.5 Validate a graph edge manually

A graph suggests Support can add a member to Helpdesk and Helpdesk has a useful APP01 remote-management relationship. Check the controlled membership, the group member-write operation/GUID, scope and applicable deny rules. Separately validate what Helpdesk enables on APP01 and whether its endpoint is reachable.

§6.2.5.1 — Enumerate and validate effective object permissions

§6.4.1.1 — Select a compatible remote-access mechanism

6.6.3.6 Paper transition and verification

For this worked example only, assume all conditions are verified and the scoped practice authorization allows the specific group change. The canonical procedure supplies the exact modification and restoration steps. A successful directory change is not yet a fresh token or a remote session. Refresh the relevant authentication context and test the intended endpoint; verify host and whoami output after a session is established.

§6.3.7.1 — Choose a permission-backed identity transition

§6.4.2.1 — Access using WinRM or RDP

6.6.3.7 New state, new questions

The synthetic session now verifies analyst on APP01. Re-enumerate the token, relevant readable configuration, object/host rights and routes from that state. An onward share denial may concern a second-hop credential context; it does not erase the verified first hop. No higher privilege, accessible LSASS material or domain administration is assumed.

§6.5.2.1 — Re-enumerate after an identity or host change

6.6.3.8 Why the route changed