6.2.9 Map Active Directory attack paths

Strategy map | Master Notes | Operational index | Cheatsheets

Build identity, object-right, host-access and session maps. A graph relationship is a candidate until its effective permission, destination and current state are checked.

Speedrun blocks: 10; Block 13 route fundamentals first. Documented methods: 7.

Examples are hypothetical study material. Apply commands only to an assigned scope during the later practice phase. A method is enabled by its prerequisites; its presence here does not establish a vulnerability or practical mastery.

6.2.9.1 First pass: tools and findings

Use the branch matching the current host, identity and observed result. Tool output supplies leads; the linked procedure verifies and uses the exact condition.

6.2.9.1.1 Resolve domain, DC, DNS and clock first

Use the current domain identity or the supported query context; wrong naming/transport can look like a bad password.

whoami /all
whoami /upn
nltest /dsgetdc:DOMAIN
w32tm /query /status

• If Domain/DC preflight works: Enumerate users/groups/SPNs and collect supported directory relationships. → Enumerate directory objects with native, LDAP and PowerView approaches.
• Otherwise: KDC timeout, name failure or skew: repair that dependency before judging credentials. → Establish domain identity, DC, DNS, time and route.

6.2.9.1.2 Collect a BloodHound directory baseline with SharpHound

Use a collector compatible with the BloodHound version. DCOnly is a directory baseline, not proof of all host/session edges.

.\SharpHound.exe --CollectionMethods DCOnly --OutputDirectory .\bh --ZipFileName domain-dconly.zip

• If A useful object-control edge: Resolve the controlled trustee, target object and effective ACE. → Validate effective directory-object control.
• If A host/session edge: Check destination rights and session freshness independently. → Validate host access and volatile session candidates.
• If An account with an SPN: Check the actual account/SPN and ticket-request conditions. → Identify service accounts and SPNs worth investigating.
• Otherwise: Collection is blocked or incomplete: query the relevant objects manually. → Enumerate directory objects with native, LDAP and PowerView approaches.

6.2.9.2 Discovery workflow

Start with a known domain identity or a directory query context; useful group, object-right and session edges are not assumed.

Follow these observations into a method; the detailed recognition routes below show synthetic output and the checks still needed.

1. Resolve identity, realm, DC, DNS, clock and route first: Establish domain identity, DC, DNS, time and route.
2. Enumerate objects, group nesting and relevant shares with a supported client: Enumerate directory objects with native, LDAP and PowerView approaches; Read domain shares, SYSVOL and NETLOGON for useful artifacts.
3. Associate SPNs and effective ACEs with actual accounts and object types: Identify service accounts and SPNs worth investigating; Validate effective directory-object control.
4. Check host-specific rights and session freshness, then validate graph paths edge by edge: Validate host access and volatile session candidates; Collect focused BloodHound data and validate an attack path.

PowerView examples require a reviewed compatible script in the current authenticated directory context. Check the loaded copy rather than mixing legacy/fork parameter names; the directory-mapping entry includes native, ADSI and LDAP alternatives.

Import-Module .\PowerView.ps1
Get-Command -Module PowerView

Decision rule: an observed clue opens a candidate. Choose it only after the missing conditions are verified; a failed check rules out that context, while unavailable evidence stays inconclusive.

6.2.9.3 Method families

• Domain context and directory objects: Establish domain identity, DC, DNS, time and route, Enumerate directory objects with native, LDAP and PowerView approaches.
• Artifacts and service identities: Read domain shares, SYSVOL and NETLOGON for useful artifacts, Identify service accounts and SPNs worth investigating.
• Effective rights, host access and path ranking: Validate effective directory-object control, Validate host access and volatile session candidates, Collect focused BloodHound data and validate an attack path.

6.2.9.4 Choose a method

6.2.9.5 Establish domain identity, DC, DNS, time and route

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Operational procedure | Operational procedure | Quick sheet

6.2.9.5.1 Purpose and result

A verified domain context and working directory/authentication preflight.

6.2.9.5.2 Recognition clues

Domain credentials or a domain-joined foothold.

6.2.9.5.2.1 Find the clue from your starting access

Where to investigate: Start with the session identity and known credential scope; discover the realm/DC and inspect DNS, time and routes.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

whoami /all
whoami /upn
nltest /dsgetdc:DOMAIN
w32tm /query /status

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

UPN: USER@DOMAIN
DC: \\DC_HOST
Domain name: DOMAIN
Clock source/status: inspect

Recognize this detail: The named realm/DC and actual identity establish where directory/authentication checks must run.

Still missing before method selection: Check DC/service reachability, resolver/SPN naming and clock compatibility, not merely the password.

If you do not yet have this clue: start with Validate known passwords and context-specific reuse.

6.2.9.5.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew.

6.2.9.5.4 Discover and verify prerequisites

whoami /all
whoami /upn
nltest /dsgetdc:DOMAIN
w32tm /query /status

6.2.9.5.5 Why it works

Local process identity, network credential context and domain naming are separate. Kerberos depends on service names, time and KDC connectivity in addition to a valid password.

6.2.9.5.6 Execute and choose variants

6.2.9.5.6.1.1 Domain-joined Windows source

whoami /all
echo %USERDNSDOMAIN%
echo %USERDOMAIN%
echo %LOGONSERVER%
nltest /dsgetdc:DOMAIN
nltest /dclist:DOMAIN
w32tm /query /status

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.DOMAIN
Resolve-DnsName -Type SRV _kerberos._tcp.DOMAIN

6.2.9.5.6.1.2 Kali/off-domain source

dig +short SRV _ldap._tcp.dc._msdcs.DOMAIN @DC_IP
dig +short SRV _kerberos._tcp.DOMAIN @DC_IP
nxc smb DC_IP -d DOMAIN -u USER -p 'PASSWORD'
ldapsearch -x -LLL -H ldap://DC_HOST:389 -s base -b '' \
  defaultNamingContext configurationNamingContext rootDomainNamingContext dnsHostName

whoami /all
klist
dir \\DC_HOST\SYSVOL

IDENTITY MAP: USER/COMPUTER -> DIRECT + NESTED GROUPS -> DIRECTORY RIGHTS
HOST MAP:     COMPUTER -> OS/ROLE -> LOCAL/REMOTE-ACCESS RIGHTS -> SESSIONS
ROUTE MAP:    SOURCE -> DNS/KDC/DC/HOST -> REQUIRED PORT/SERVICE
LEAD MAP:     EVIDENCE -> HYPOTHESIS -> MINIMUM VALIDATION -> NEXT BLOCK

Authentication, authorization, reachability and session presence are independent. A valid LDAP bind does not prove share access; SMB administration on one host does not prove directory privilege; a session edge does not prove retrievable credentials.

AS-REQ/AS-REP: user proves knowledge of long-term key -> receives TGT
TGS-REQ/TGS-REP: TGT requests SERVICE/HOST -> receives service ticket
AP-REQ: client presents service ticket -> service authenticates client
AUTHORIZATION: target service still evaluates the represented identity/claims

Before changing credentials or tools:

getent hosts DC_HOST
nc -nvz DC_IP 88
date -u

w32tm /query /status
klist

Record domain FQDN/realm, DC FQDN/IP, source DNS, current time, KDC route and exact target SPN. IP connectivity does not replace hostname/SPN correctness.

6.2.9.5.7 Worked example — hypothetical

Observation: a valid domain password fails in a ticket-based client. Test: inspect DC naming, DNS, route and time. Illustrative output: the KDC is unreachable through the current route. Interpretation: fix transport before judging the credential.

6.2.9.5.8 Verify the result

Record represented identity, realm, selected DC, resolver, clock and real source route.

6.2.9.5.9 Failure and fallback

Wrong domain, KDC timeout, clock skew and account denial are distinct failures. Do not repeatedly change passwords to fix a route problem.

6.2.9.5.10 Continue from the interpreted result

6.2.9.6 Enumerate directory objects with native, LDAP and PowerView approaches

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Operational procedure | Operational procedure | Operational procedure | Operational procedure | Quick sheet

6.2.9.6.1 Purpose and result

User, group, computer, trust and policy relationships for attack-path hypotheses.

6.2.9.6.2 Recognition clues

A directory bind or domain-joined identity can read relevant objects.

6.2.9.6.2.1 Find the clue from your starting access

Where to investigate: Use the available built-in/LDAP interface from the verified domain context; inspect one useful user/group before broad graph assumptions.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

net user USER /domain
net group "GROUP" /domain

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Account: USER
Global group memberships: GROUP
Group members: CONTROLLED_USER

Recognize this detail: Account/group membership supplies a relationship to investigate; nested membership and effective destination rights remain separate.

Still missing before method selection: Verify object SID/type, nesting and the exact right granted to that principal.

If you do not yet have this clue: start with Establish domain identity, DC, DNS, time and route.

6.2.9.6.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Correct search base and authentication transport; object/attribute visibility and compatible local utilities.

6.2.9.6.4 Discover and verify prerequisites

net user /domain
net group /domain

6.2.9.6.5 Why it works

Tools expose the same directory through different interfaces. Group nesting, object types, primary groups and protected attributes affect how relationships translate into effective rights.

6.2.9.6.6 Execute and choose variants

net user /domain
net user USER /domain
net group /domain
net group "Domain Admins" /domain
net group "GROUP" /domain
net accounts /domain
nltest /domain_trusts /all_trusts
net view /domain
net view \\DC_HOST

Get-Command -Module ActiveDirectory
Get-ADDomain
Get-ADForest
Get-ADDomainController -Filter *
Get-ADUser -Filter * -Properties Enabled,Description,MemberOf,ServicePrincipalName,UserPrincipalName,PasswordLastSet,LastLogonDate,AdminCount
Get-ADGroup -Filter * -Properties GroupScope,GroupCategory,Members,Description
Get-ADGroupMember -Identity 'GROUP' -Recursive
Get-ADComputer -Filter * -Properties DNSHostName,OperatingSystem,OperatingSystemVersion,ServicePrincipalName,TrustedForDelegation,LastLogonDate
Get-ADTrust -Filter *

$root = [ADSI]'LDAP://RootDSE'
$base = [ADSI]("LDAP://" + $root.defaultNamingContext)
$searcher = New-Object System.DirectoryServices.DirectorySearcher($base)
$searcher.PageSize = 1000
$searcher.PropertiesToLoad.AddRange(@('samaccountname','userprincipalname','objectsid','memberof','serviceprincipalname','description','useraccountcontrol','pwdlastset','lastlogontimestamp'))
$searcher.Filter = '(&(objectCategory=person)(objectClass=user))'
$searcher.FindAll() | ForEach-Object { $_.Properties }

# Groups
$searcher.Filter = '(objectCategory=group)'
$searcher.PropertiesToLoad.Clear()
$searcher.PropertiesToLoad.AddRange(@('samaccountname','objectsid','member','grouptype','description'))
$searcher.FindAll() | ForEach-Object { $_.Properties }

# Computers
$searcher.Filter = '(objectCategory=computer)'
$searcher.PropertiesToLoad.Clear()
$searcher.PropertiesToLoad.AddRange(@('dnshostname','operatingsystem','operatingsystemversion','serviceprincipalname','useraccountcontrol','lastlogontimestamp'))
$searcher.FindAll() | ForEach-Object { $_.Properties }

ldapsearch -x -LLL -H ldap://DC_HOST:389 -s base -b '' \
  defaultNamingContext configurationNamingContext rootDomainNamingContext dnsHostName

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN' -W \
  -E pr=1000/noprompt -b 'DC=DOMAIN,DC=TLD' \
  '(&(objectCategory=person)(objectClass=user))' \
  sAMAccountName userPrincipalName objectSid userAccountControl memberOf description servicePrincipalName pwdLastSet lastLogonTimestamp adminCount

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN' -W \
  -E pr=1000/noprompt -b 'DC=DOMAIN,DC=TLD' \
  '(objectCategory=group)' sAMAccountName objectSid member groupType description

ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN' -W \
  -E pr=1000/noprompt -b 'DC=DOMAIN,DC=TLD' \
  '(objectCategory=computer)' dNSHostName operatingSystem operatingSystemVersion servicePrincipalName userAccountControl lastLogonTimestamp

# SPN-bearing accounts: mapping only; do not request tickets in this block.
ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN' -W \
  -E pr=1000/noprompt -b 'DC=DOMAIN,DC=TLD' \
  '(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))' \
  sAMAccountName servicePrincipalName memberOf userAccountControl pwdLastSet

# Trusted-domain objects
ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN' -W \
  -b 'DC=DOMAIN,DC=TLD' '(objectClass=trustedDomain)' \
  cn securityIdentifier trustDirection trustType trustAttributes

# OUs and GPO containers; correlate links before inferring host effect.
ldapsearch -x -LLL -H ldap://DC_HOST:389 -D 'USER@DOMAIN' -W \
  -E pr=1000/noprompt -b 'DC=DOMAIN,DC=TLD' \
  '(|(objectClass=organizationalUnit)(objectClass=groupPolicyContainer))' \
  distinguishedName displayName name gPLink gPOptions

Import-Module .\PowerView.ps1
Get-Command -Module PowerView
Get-Domain
Get-DomainController
Get-DomainTrust
Get-DomainUser | Select-Object samaccountname,userprincipalname,description,memberof,serviceprincipalname
Get-DomainGroup
Get-DomainGroupMember -Identity 'GROUP' -Recurse
Get-DomainComputer | Select-Object dnshostname,operatingsystem,operatingsystemversion
Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof

NEW PASSWORD/HASH/KEY/TICKET
-> VERIFY TYPE, CLIENT, REALM, VALIDITY
-> AUTHENTICATE THROUGH ONE COMPATIBLE SERVICE
-> CONFIRM IDENTITY
-> REPEAT GROUP/ACL/SHARE/HOST/SESSION/ROUTE MAPPING

Do not overwrite the old state. Record which source produced the material and which protocol accepted it.

6.2.9.6.7 Worked example — hypothetical

Observation: a group appears to grant useful access. Test: enumerate its membership and nesting with the available native/LDAP method. Illustrative output: the controlled user is included through another group. Interpretation: validate the resulting destination/object right.

6.2.9.6.8 Verify the result

Retain object identifiers, group relationships and actual visibility; distinguish directory facts from inferred execution access.

6.2.9.6.9 Failure and fallback

Missing RSAT/PowerView does not block built-in ADSI or LDAP. Signing/TLS policy requires a compatible authenticated transport.

6.2.9.6.10 Continue from the interpreted result

6.2.9.7 Read domain shares, SYSVOL and NETLOGON for useful artifacts

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Quick sheet

6.2.9.7.1 Purpose and result

Policy/scripts/configuration and typed credential or host clues.

6.2.9.7.2 Recognition clues

A valid domain identity and accessible file services.

6.2.9.7.2.1 Find the clue from your starting access

Where to investigate: Enumerate the DC/known file-server shares and inspect relevant SYSVOL/NETLOGON paths under the accepted domain identity.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

net view \\DC_HOST
dir \\DOMAIN\SYSVOL
dir \\DOMAIN\NETLOGON

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

NETLOGON contains LOGIN_SCRIPT
Readable script references SERVICE_ACCOUNT and CONFIG_PATH

Recognize this detail: A real domain-readable script gives concrete identity/path leads for credential and host investigation.

Still missing before method selection: Verify readable artifact content, whether any secret is current and what account/service it belongs to.

If you do not yet have this clue: start with Establish domain identity, DC, DNS, time and route.

6.2.9.7.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Reachable SMB plus share/object read rights in the chosen identity context.

6.2.9.7.4 Discover and verify prerequisites

dir \\DOMAIN\SYSVOL
dir \\DOMAIN\NETLOGON

6.2.9.7.5 Why it works

Domain-readable scripts and policy artifacts can disclose paths, service accounts or historical secrets. A script's presence does not prove that its credentials are current or that it runs with high privilege.

6.2.9.7.6 Execute and choose variants

6.2.9.7.6.1.1 Inventory, then test the object

net view \\DC_HOST
dir \\DC_HOST\SYSVOL
dir \\DC_HOST\NETLOGON

nxc smb DC_IP -d DOMAIN -u USER -p 'PASSWORD' --shares
smbclient -L //DC_IP -U 'DOMAIN/USER'
smbclient //DC_IP/SYSVOL -U 'DOMAIN/USER' -c 'recurse ON; ls'
smbclient //DC_IP/SHARE -U 'DOMAIN/USER'

Inside smbclient, use ls, cd, get FILE and a harmless approved put only when write validation is needed. Share listing, share connection, file read and file write are separate permissions.

Inspect authorized readable policy/logon/deployment paths for scripts, configurations, backups, connection strings and legacy Group Policy Preferences XML containing cpassword. Selectively retrieve relevant files; do not bulk-copy a share merely because it is readable. A discovered secret returns to the credential-classification procedure.

6.2.9.7.7 Worked example — hypothetical

Observation: a readable login script references a backup account. Test: inspect the relevant configuration and validate any recovered secret in context. Illustrative output: a credential opens another share. Interpretation: re-enumerate that identity's available objects.

6.2.9.7.8 Verify the result

Prove read access and actual artifact content; keep recovered real secrets private.

6.2.9.7.9 Failure and fallback

Share listing denial does not necessarily deny a known share path, and login success does not guarantee object read access.

6.2.9.7.10 Continue from the interpreted result

6.2.9.8 Identify service accounts and SPNs worth investigating

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Quick sheet

6.2.9.8.1 Purpose and result

A prioritized service-account and roast candidate list.

6.2.9.8.2 Recognition clues

User-owned SPNs or service-account clues.

6.2.9.8.2.1 Find the clue from your starting access

Where to investigate: Enumerate servicePrincipalName on user objects and associate each SPN with its owning account and memberships.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

samaccountname: SERVICE_USER
serviceprincipalname: HTTP/TARGET_HOST
memberof: GROUP

Recognize this detail: A user-owned service name identifies a potential ticket/password-recovery target whose rights may be useful.

Still missing before method selection: Check actual account type, KDC authentication, encryption type and feasibility; SPN existence alone is not weakness.

If you do not yet have this clue: start with Establish domain identity, DC, DNS, time and route.

6.2.9.8.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Directory visibility and correct service/account association; roasting requires the additional authentication and encryption conditions.

6.2.9.8.4 Discover and verify prerequisites

setspn -Q */*

6.2.9.8.5 Why it works

An SPN maps a service name to an account key. Computer-account SPNs and user-service-account SPNs have different password characteristics; SPN presence is not a cracked password.

6.2.9.8.6 Execute and choose variants

setspn -Q */*
setspn -L ACCOUNT

Get-DomainUser -SPN | Select-Object samaccountname,serviceprincipalname,memberof,useraccountcontrol,pwdlastset

Record account → service class/host/port → groups → password age/encryption/delegation clues → reachable service. An SPN means the account represents a Kerberos service identity; it does not mean the password is weak, the service is reachable or the account is privileged. Ticket acquisition/cracking is Block 11.

6.2.9.8.7 Worked example — hypothetical

Observation: a named user owns an HTTP SPN. Test: inspect account context and request only the selected account's ticket when permitted. Illustrative output: a roastable ticket is obtained. Interpretation: choose the matching offline mode and evaluate feasibility.

6.2.9.8.8 Verify the result

Record SPN, account/object type and relevant privilege relationships before prioritizing recovery.

6.2.9.8.9 Failure and fallback

An SPN alone proves neither weak password nor destination admin rights. Rank by evidence and potential benefit.

6.2.9.8.10 Continue from the interpreted result

6.2.9.9 Validate effective directory-object control

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Operational procedure | Quick sheet

6.2.9.9.1 Purpose and result

A verified object-control primitive suitable for a named identity transition.

6.2.9.9.2 Recognition clues

An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right.

6.2.9.9.2.1 Find the clue from your starting access

Where to investigate: Select a useful user/group/computer/domain object from mapping and resolve its ACE trustees, rights and object-specific scopes.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SecurityIdentifier: CONTROLLED_GROUP_SID
ActiveDirectoryRights: WriteDacl
Target: TARGET_OBJECT

Recognize this detail: A DACL-control ACE for a possibly controlled trustee opens an intermediate-right candidate.

Still missing before method selection: Resolve the ACE's trustee and group nesting, target object class, GUID and inheritance/deny scope. For password reset, group writes or DACL changes open that exact operation's procedure and check its additional conditions before modifying anything.

If you do not yet have this clue: start with Establish domain identity, DC, DNS, time and route.

6.2.9.9.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation.

6.2.9.9.4 Discover and verify prerequisites

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs

6.2.9.9.5 Why it works

Object rights are operation-specific. GenericWrite on a user is not a universal password-reset right; inherited ACEs and protected objects can change applicability.

6.2.9.9.6 Execute and choose variants

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs |
  Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight|WriteProperty|Self' } |
  Select-Object ObjectDN,SecurityIdentifier,ActiveDirectoryRights,ObjectAceType,AceType,IsInherited,InheritanceType

PowerView normally exposes the trustee as SecurityIdentifier. Resolve that SID and trace controlled direct/nested membership. -ResolveGUIDs resolves operation GUIDs; it does not make every trustee a friendly account name. A blank projected column can mean the selected property is absent, not that an ACE has no trustee.

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs |
  Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight|WriteProperty|Self' } |
  Select-Object ObjectDN,IdentityReference,ActiveDirectoryRights,ObjectAceType,AceType,IsInherited,InheritanceType

An ACE is one rule. Effective access depends on trustee/group nesting, allow/deny semantics, inheritance, object-specific GUIDs and security descriptor scope. Do not perform the modification in this mapping block.

Model: controlled principal → effective ACE → target object/type → permitted modification → authentication/authorization effect → cleanup.

Enumerate a target's ACL with resolved GUIDs:

Import-Module .\PowerView.ps1
Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs |
  Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner|ExtendedRight' }

Resolve trustees:

ConvertFrom-SID 'S-1-5-21-...'
Get-DomainObject -Identity 'S-1-5-21-...' | Select-Object samaccountname,objectclass

Common effects require different rights:

6.2.9.9.7 Worked example — hypothetical

Observation: a graph suggests a password-reset edge. Test: resolve the ACE and controlled user's effective membership against the actual target. Illustrative output: the required extended right applies. Interpretation: assess the reset's impact and select the intended transition.

6.2.9.9.8 Verify the result

Verify principal, object SID/type and effective permitted modification; preserve original ACL/state before changes.

6.2.9.9.9 Failure and fallback

A stale graph, inherited scope mismatch or deny/protected-object behavior can invalidate the edge.

6.2.9.9.10 Continue from the interpreted result

6.2.9.10 Validate host access and volatile session candidates

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Operational procedure | Quick sheet

6.2.9.10.1 Purpose and result

Verified service access or a prioritized host/session hypothesis.

6.2.9.10.2 Recognition clues

Group-to-host access edges or a privileged user's possible session.

6.2.9.10.2.1 Find the clue from your starting access

Where to investigate: Correlate directory group/session relationships with a specific host's service and local access policy, rather than treating all host edges as administrator access.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SMB authentication: accepted
SHARE: READ
RDP/WinRM/WMI authorization: not established

Recognize this detail: A permitted SMB action identifies a host capability; it does not establish RDP/WinRM/SCM rights. Investigate sessions only with a supported, permitted remote query.

Still missing before method selection: Verify actual group effectiveness, service/logon rights, session freshness and collection visibility.

If you do not yet have this clue: start with Establish domain identity, DC, DNS, time and route.

6.2.9.10.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient.

6.2.9.10.4 Discover and verify prerequisites

whoami /groups
net localgroup Administrators

6.2.9.10.5 Why it works

Local admin, RDP, WinRM and share-read relationships grant different capabilities. A historical session does not guarantee current credential material or the right to read it.

6.2.9.10.6 Execute and choose variants

Find-LocalAdminAccess

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

Find-LocalAdminAccess is a broad candidate generator and can be noisy or blocked by firewall/RPC controls. Validate a selected host with the service you may actually use. NetExec's (Pwn3d!) indicates administrative SMB context according to that tool; it does not establish RDP, WinRM, WMI/DCOM or directory rights. RDP, WinRM, SMB/service control and WMI/DCOM each have different ports, services, policies and authorization.

Get-NetSession -ComputerName COMPUTER -Verbose
Get-NetLoggedon -ComputerName COMPUTER

PsLoggedOn.exe \\COMPUTER

Get-NetSession relies on workstation/session enumeration APIs that modern Windows may restrict. PsLoggedOn combines Registry profile evidence with NetSessionEnum; remote Registry access and sufficient rights are relevant, and querying can itself create a network-session entry. Therefore:

• empty/denied is inconclusive, not proof of no users;
• a session is a time-sensitive observation, not a durable ACL;
• a session matters only if the current identity can reach/control that host and a later credential/ticket technique applies;
• session presence does not prove credentials are resident, accessible or reusable.

6.2.9.10.7 Worked example — hypothetical

Observation: a graph marks a user as able to RDP to a host. Test: validate the reachable RDP service and effective logon right. Illustrative output: RDP works but remote service creation is denied. Interpretation: retain the actual access form and inspect that host's new opportunities.

6.2.9.10.8 Verify the result

Record the destination-specific successful action and freshness/limits of session evidence.

6.2.9.10.9 Failure and fallback

Collection denial is not proof that no sessions exist; a valid credential is not proof of every host-access method.

6.2.9.10.10 Continue from the interpreted result

6.2.9.11 Collect focused BloodHound data and validate an attack path

Blocks: 10; Block 13 route fundamentals first. Operational procedure | Operational procedure | Quick sheet

6.2.9.11.1 Purpose and result

A ranked chain of independently testable relationships.

6.2.9.11.2 Recognition clues

Directory relationships are too broad for manual comparison or a candidate chain needs ranking.

6.2.9.11.2.1 Find the clue from your starting access

Where to investigate: Inspect focused collected relationships and the collector's scope/freshness before following a displayed path.

Discovery action — reference example:

Access/context: A known domain identity or a directory endpoint that permits the selected anonymous query

In BloodHound: locate the controlled principal; inspect the exact edge, source object, destination and collection age.
Resolve its underlying group/ACL/service evidence with the corresponding manual method.

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Graph path: CONTROLLED_GROUP -> WriteDacl -> TARGET_USER
Collection scope: directory only
Host/session data: not collected

Recognize this detail: The directory edge supplies a candidate intermediate right; missing host/session evidence cannot be invented from the graph.

Still missing before method selection: Collect with a version-compatible SharpHound/BloodHound collector, then validate the selected edge. Resolve group nesting and effective ACEs for object control; test destination rights and session freshness for host/session edges.

If you do not yet have this clue: start with Establish domain identity, DC, DNS, time and route.

6.2.9.11.3 Prerequisites

Starting access: A known domain identity or a directory endpoint that permits the selected anonymous query. Required conditions: Compatible collector/deployment, explicit scope, directory rights and separate permission/connectivity for host/session collection.

6.2.9.11.4 Discover and verify prerequisites

SharpHound.exe --help

6.2.9.11.5 Why it works

BloodHound models collected relationships, which may be stale or incomplete. Directory-only collection and host/session collection answer different questions and have different contact/rights requirements.

6.2.9.11.6 Execute and choose variants

6.2.9.11.6.1.1 Current SharpHound CE

Low-noise directory baseline that avoids contacting every workstation:

.\SharpHound.exe --CollectionMethods DCOnly --OutputDirectory .\bh --ZipFileName domain-dconly.zip

Add host facts only when they can answer the next question:

.\SharpHound.exe --CollectionMethods LocalGroup --ComputerFile .\candidate-hosts.txt --OutputDirectory .\bh --ZipFileName candidate-localgroups.zip
.\SharpHound.exe --CollectionMethods Session --ComputerFile .\candidate-hosts.txt --Loop --LoopDuration 00:10:00 --OutputDirectory .\bh --ZipFileName candidate-sessions.zip

SharpHound with no collection flag uses its broader default, including directory data plus local-group/session attempts. All performs every supported method; it is not the first response to an unanswered narrow question. Import the output ZIP into a compatible BloodHound CE deployment and verify node/edge counts and ingestion errors.

# Inspect the actual collector before using copied syntax.
.\SharpHound.exe --help

# Legacy/course PowerShell collector; use only with a compatible legacy deployment.
Import-Module .\SharpHound.ps1
Invoke-BloodHound -CollectionMethod All -OutputDirectory .\bh -ZipFileName legacy.zip

6.2.9.11.6.1.2 Noninteractive Kali first pass

Use one valid domain identity and scoped DC/SMB connectivity. Start in a fresh private directory so graph output and reports do not mix identities. DOMAIN is the DNS domain; DOMAIN_NETBIOS is its short name, DC_HOST the DC FQDN, and TARGET one approved SMB host. No menu input is required.

mkdir -p ~/oscp/work/TARGET/evidence/ad-first-pass
cd ~/oscp/work/TARGET/evidence/ad-first-pass
bloodhound-ce-python -d DOMAIN -u USER -p 'PASSWORD' -dc DC_HOST -ns DC_IP -c DCOnly --disable-autogc --zip
ldapdomaindump -u 'DOMAIN_NETBIOS\USER' -p 'PASSWORD' -o ldap-inventory ldap://DC_IP
bloodyAD --host DC_HOST --dc-ip DC_IP -d DOMAIN -u USER -p 'PASSWORD' get writable --detail --partition DOMAIN > writable.txt
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares --no-admin-check --log shares.log

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares --no-write-check --log shares.log

Do not use linWinPwn --auto as a substitute for this selection: its automatic chain has additional attack behavior. Its menu-based all,LoggedOn collector adds host RPC and remote-registry access that can trigger RemoteRegistry startup. The direct baseline also removes the wrapper's startup Nmap scan and conditional password-repair prompts. Authentication-method fallback can cause multiple authentication exchanges; stop and diagnose a failed credential rather than repeatedly running all collectors.

Sources: BloodHound.py CE, ldapdomaindump, bloodyAD writable query, NetExec share enumeration. A future tool/dependency version needs renewed behavior checks; these commands are reference material, not a claim of target execution or explicit OffSec tool endorsement.

6.2.9.11.6.1.3 Analyze in this order

1. Mark only identities/hosts actually controlled. A low-privilege session on a host does not make the host itself fully owned.
2. Inspect the controlled principal's direct and nested group memberships and outbound object-control edges.
3. Inspect reachable computers where it has local admin, RDP, WinRM/DCOM or other applicable rights.
4. Inspect high-value goals and shortest paths only as hypothesis generation.
5. Classify each selected edge:
   • directory/static-ish: group, ACL, GPO, OU, trust;
   • host-derived: local group or user right;
   • volatile: session;
   • route-dependent: the required host/service must be reachable now.
6. Reproduce the minimum important relationship manually before handing it to Block 11 or 12.

ID | CONTROLLED PRINCIPAL | RELATIONSHIP | TARGET | SOURCE EVIDENCE
   | EFFECTIVE? | ROUTE/SERVICE | VOLATILITY | EXPECTED TRANSITION
   | MINIMUM VALIDATION | STATUS | NEXT BLOCK

Rank candidates by:

1. confidence that the relationship is effective;
2. deterministic value of the resulting identity/access;
3. route and service availability;
4. stability versus volatile session timing;
5. reversibility and impact;
6. number of unsupported assumptions.

Prefer a validated readable share/credential clue or direct object right over a multi-edge path built from stale sessions and unreachable hosts.

6.2.9.11.7 Worked example — hypothetical

Observation: collection finds a short path from a controlled group to a privileged account. Test: validate each effective ACL and destination service edge manually. Illustrative output: one edge is stale. Interpretation: reject that chain and rank another with current evidence.

6.2.9.11.8 Verify the result

Validate every useful edge against current directory/host evidence and identify the transition each one enables.

6.2.9.11.9 Failure and fallback

Collector/version incompatibility and partial data are tool/visibility failures. They do not prove the environment lacks a path.

6.2.9.11.10 Continue from the interpreted result

6.2.9.12 Sources and shared concepts

Supplied PEN-200 Ch 22 pp705–760. The live Hexdump AD module currently contains no substantive lesson; use the course and linked Microsoft/SpecterOps sources.

Commands and their adjacent variant conditions are synchronized extracts of the linked operational procedures. Those procedures own complete execution details; this guide owns method selection, explanations and worked reasoning. Tool availability on the learner's Kali or a target must be checked in that environment.

Recognition interpretation: Microsoft account-control flags and PowerView user-query documentation. Parameter names can differ between legacy documentation and the loaded script; the illustrated bit test avoids ambiguous preauthentication switch names.