3.1 Recover and use authentication material

Strategy map | Master Notes | Operational index | Cheatsheets

Treat passwords, keys, stored verifiers, challenge responses and tickets as different capabilities. Recovering a password, authenticating and obtaining useful authorization are separate transitions.

Speedrun blocks: 5; recurring identity thread. Documented methods: 10.

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

3.1.1 First pass: tools and findings

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

3.1.1.1 Identify the artifact before using a cracking tool

Keep provenance and local/domain/application account scope. Hash-looking text is not automatically an NT hash.

file FILE
head -c 160 FILE

If A plaintext password: Test the matching identity on one relevant reachable service. → Validate known passwords and context-specific reuse.
If An SSH private key: Check key format, protection and the intended account. → Inspect and recover SSH private-key access.
If A ticket/cache: Check principal, service scope, expiry and a compatible client. → Classify tickets and use a compatible cache.
Otherwise: Format is still unknown: inspect the artifact before selecting a Hashcat/John mode. → Classify the artifact and its identity context.

3.1.1.2 Use Hashcat/John only after format identification

Select the documented format-specific mode and an offline candidate list; recovery is not proof of service access.

hashcat -a 0 -m MODE hashes.txt wordlist.txt -r /usr/share/hashcat/rules/best64.rule --session job
hashcat -m MODE hashes.txt --show

If A password is recovered: Validate the account scope and relevant service permission. → Validate known passwords and context-specific reuse.
If A reusable NT hash rather than a recoverable plaintext password: Use only protocols and clients supporting that material. → Recover or reuse an NT password hash.
Otherwise: No recovery: revisit artifact type and feasible candidates; enumerate other evidence instead of assuming the account is unusable. → Classify the artifact and its identity context.

3.1.2 Discovery workflow

Start with an artifact produced by an actual read, query, session or collection source; the artifact type and username may still be unknown.

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

Record source and account scope, then inspect the artifact's structure: Classify the artifact and its identity context.
Separate an immediately usable password/key from material needing recovery: Validate known passwords and context-specific reuse; Inspect and recover SSH private-key access; Recover passwords with feasible dictionary, rule and mask attacks.
Use type-specific handling for stored verifiers, captured responses and tickets: Recover or reuse an NT password hash; Recover a password from a captured NTLM response; Recover a password from cached domain logon verifiers; Classify tickets and use a compatible cache.
After acceptance, test the specific service right and return to authenticated enumeration: Match route, destination service and effective authorization; Enumerate SMB/RPC shares, files and identities.

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

3.1.3 Method families

Classification and online use: Classify the artifact and its identity context, Validate known passwords and context-specific reuse.
Offline recovery and protected files: Recover passwords with feasible dictionary, rule and mask attacks, Recover a protected KeePass database password, Inspect and recover SSH private-key access, Recover Linux account passwords from matched records.
Typed Windows/domain material: Recover or reuse an NT password hash, Recover a password from a captured NTLM response, Recover a password from cached domain logon verifiers, Classify tickets and use a compatible cache.

3.1.4 Choose a method

Method	Recognition clue	Required access	Enabling conditions	Resulting capability
Classify the artifact and its identity context	A secret-like value, key file, stored hash, challenge response or ticket	A credential artifact with a recorded source and possible account context	Artifact provenance and format; possible local/domain/application identity and compatible protocol	A typed credential record with a justified use or recovery path
Validate known passwords and context-specific reuse	A password tied to a plausible user and service	A credential artifact with a recorded source and possible account context	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	A verified authentication result followed by tested service-specific authorization
Recover passwords with feasible dictionary, rule and mask attacks	A supported stored verifier or converted protected artifact	A credential artifact with a recorded source and possible account context	Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend	A recovered candidate password or a documented exhausted search strategy
Recover a protected KeePass database password	A readable KeePass database and possible associated key file	A credential artifact with a recorded source and possible account context	Complete database, compatible converter, and every required factor; a feasible password candidate strategy	An opened vault or a valid recovered database password
Inspect and recover SSH private-key access	A private key from a file read, share, repository or home directory	A credential artifact with a recorded source and possible account context	Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy	A usable key and a verified SSH authentication context
Recover Linux account passwords from matched records	Readable password verifiers and account metadata	A credential artifact with a recorded source and possible account context	Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy	A recovered local account password with a justified privilege/reuse test
Recover or reuse an NT password hash	An NT verifier from an appropriate credential source	A credential artifact with a recorded source and possible account context	Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights	A recovered password or a verified hash-backed authentication capability
Recover a password from a captured NTLM response	A complete challenge-response record	A credential artifact with a recorded source and possible account context	Correct challenge/response formatting and feasible candidates; acquisition method must fit the allowed context	A recovered password from the response's offline verifier
Recover a password from cached domain logon verifiers	A DCC2/MSCache record from matched SECURITY/SYSTEM material	A credential artifact with a recorded source and possible account context	Correct username/salt/iteration context and feasible offline candidates	A recovered domain password, subject to current account state
Classify tickets and use a compatible cache	A ccache/kirbi file or an existing ticket cache	A credential artifact with a recorded source and possible account context	Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route	A verified Kerberos authentication capability for an appropriate service

3.1.5 Classify the artifact and its identity context

Blocks: 5; recurring identity thread. Operational procedure | Operational procedure | Operational procedure | Quick sheet

3.1.5.1 Purpose and result

A typed credential record with a justified use or recovery path.

3.1.5.2 Recognition clues

A secret-like value, key file, stored hash, challenge response or ticket.

3.1.5.2.1 Find the clue from your starting access

Where to investigate: Return to the file, database row, capture or session that produced the artifact; inspect structure and account labels before choosing a tool mode.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Artifact provenance and format; possible local/domain/application identity and compatible protocol

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Identify artifact type, source, account/domain and compatible next operation; record unknowns instead of guessing.

Failure/next check: A 32-character hexadecimal value is not enough to identify its algorithm. Use application/source evidence and converters.

file FILE
head -c 160 FILE

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.

Possible structures:
-----BEGIN OPENSSH PRIVATE KEY-----
USER::DOMAIN:CHALLENGE:RESPONSE:BLOB
USER:RID:LM_HASH:NT_HASH:::

Recognize this detail: Headers and producing context distinguish a private key, challenge response and stored NT verifier.

Still missing before method selection: Record the exact source, user/domain and complete format; identify compatible recovery/authentication operations.

Outcome after checking	Example and next decision
Enabled after validation	Source and format agree on the type: route it to the matching recovery/use method.
Ruled out in this context	The value is an application identifier rather than an authentication artifact: reject the credential hypothesis.
Inconclusive	A bare hexadecimal string without provenance does not identify its algorithm; investigate the producing application.

If you do not yet have this clue: start with Inspect source, backups, configuration and repository artifacts.

3.1.5.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Artifact provenance and format; possible local/domain/application identity and compatible protocol.

3.1.5.4 Discover and verify prerequisites

file FILE
head -c 160 FILE

3.1.5.5 Why it works

An NT hash, Net-NTLMv2 response and DCC2 verifier are not interchangeable. Source and format constrain cracking mode, reuse protocol and expected rights.

3.1.5.6 Execute and choose variants

SOURCE -> MATERIAL/FORMAT -> LOCAL/DOMAIN/APPLICATION IDENTITY
-> POSSIBLE USE -> SERVICE/PROTOCOL -> AUTHENTICATION
-> AUTHORIZATION -> NEW ACCESS -> RE-ENUMERATION

Record source, claimed identity, format evidence, possible uses, tested service, result and resulting rights together.

Material	Recognition	Compatible use
Cleartext password	Text tied to an identity/source	Normal protocol/application login
SSH private key	OpenSSH/PEM private-key block	SSH public-key authentication; recover passphrase offline if protected
Linux password record	`USER:$id$salt$digest:...`	Offline recovery with complete record/format
Application/file verifier	Tool-specific $...$ or documented digest	Offline recovery with matching mode/parser
NT hash	Usually 32 hex from SAM/LSASS/NTDS context	Offline recovery; PtH where NTLM and the client support it
Net-NTLMv2 response	`USER::DOMAIN:challenge:proof:blob`	Offline recovery or live relay under specific conditions; not PtH material
DCC2/MSCache v2	Username-dependent cached-domain verifier	Offline recovery; not ordinary PtH material
Kerberos ticket	`.kirbi`, ccache or in-memory cache	Ticket-specific access subject to realm, SPN, validity, clock and route
Kerberos roast material	`$krb5asrep$...` or `$krb5tgs$...`	Offline recovery with matching enctype/mode
Session/API token	Cookie, bearer/JWT or application token	Issuing application and authorization context only

Do not feed unknown strings into random modes. Preserve the source and identity context, then identify the format:

hashid HASH_OR_FILE
john --list=formats | grep -i KEYWORD
hashcat -hh | grep -i KEYWORD
hashcat --example-hashes | less

Failure cue: No hashes loaded, token/line-length errors or zero parsed hashes normally indicate wrong format, mode, damaged input or unsupported version—not a strong password.

Output	Type	Immediate compatible possibilities	Not valid as
Cleartext password	Reusable secret	Password authentication, key derivation, DPAPI where applicable	Proof of authorization
NT hash	NTLM key	Offline crack; PTH where NTLM/service policy allows; Kerberos RC4 transition where supported	Net-NTLM response or DCC2
AES128/AES256 key	Kerberos long-term key	Request Kerberos material using compatible tooling	Direct NTLM authentication
`.kirbi` / ccache	Kerberos ticket container	Use while valid for its client/realm/SPN scope	Password/hash
DCC2/MSCache v2	Offline verifier	Offline cracking	PTH
DPAPI key/blob	Protected-data material	Decrypt only with matching context/keys	General logon credential
Machine-account key	Computer identity	Map the computer account's rights and Kerberos/NTLM paths	Human/domain-admin identity

3.1.5.6.1.1 Net-NTLMv2 relay is a live authentication path, not hash reuse

A captured Net-NTLMv2 response is suitable for offline recovery, but cannot be passed as an NT hash. A relay path instead needs a fresh inbound NTLM authentication event, a different reachable target that accepts the relayed protocol, target protections that permit the exchange, and useful authorization for the relayed identity.

For an explicitly selected SMB destination, inspect signing behavior before considering it a relay receiver:

nmap -p 445 --script smb2-security-mode TARGET

Interpret: signing required closes the ordinary SMB-to-SMB relay receiver path. Signing enabled but not required is only one prerequisite; it does not supply an authentication source, bypass EPA/channel binding on another protocol, or grant the relayed identity useful rights.

The current OSCP+ exam guide prohibits poisoning/spoofing. Do not use Responder-style name-resolution poisoning in the exam workflow. A direct, already-existing authentication source still needs a separately reviewed, scope-compliant relay procedure and an action-specific verification; the incomplete procedure is tracked as RW09.

Every newly usable identity returns to Block 10 before movement:

VERIFY MATERIAL -> AUTHENTICATE SAFELY -> CONFIRM IDENTITY
                -> MAP GROUPS/RIGHTS/SHARES/HOSTS/ROUTES

3.1.5.7 Worked example — hypothetical

Observation: a recovered value is labelled a hash. Test: inspect its format and producing source. Illustrative output: it is a challenge-response capture rather than an NT verifier. Interpretation: choose offline recovery; reject direct Pass-the-Hash.

3.1.5.8 Verify the result

Identify artifact type, source, account/domain and compatible next operation; record unknowns instead of guessing.

3.1.5.9 Failure and fallback

A 32-character hexadecimal value is not enough to identify its algorithm. Use application/source evidence and converters.

3.1.5.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
A supported stored verifier or converted protected artifact	Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend	§3.1.7 — Recover passwords with feasible dictionary, rule and mask attacks
A ccache/kirbi file or an existing ticket cache	Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route	§3.1.14 — Classify tickets and use a compatible cache
A readable KeePass database and possible associated key file	Complete database, compatible converter, and every required factor; a feasible password candidate strategy	§3.1.8 — Recover a protected KeePass database password
A private key from a file read, share, repository or home directory	Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy	§3.1.9 — Inspect and recover SSH private-key access
Readable password verifiers and account metadata	Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy	§3.1.10 — Recover Linux account passwords from matched records
An NT verifier from an appropriate credential source	Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights	§3.1.11 — Recover or reuse an NT password hash
A complete challenge-response record	Correct challenge/response formatting and feasible candidates; acquisition method must fit the allowed context	§3.1.12 — Recover a password from a captured NTLM response
A DCC2/MSCache record from matched SECURITY/SYSTEM material	Correct username/salt/iteration context and feasible offline candidates	§3.1.13 — Recover a password from cached domain logon verifiers

3.1.6 Validate known passwords and context-specific reuse

Blocks: 5; recurring identity thread. Operational procedure | Operational procedure | Operational procedure | Quick sheet

3.1.6.1 Purpose and result

A verified authentication result followed by tested service-specific authorization.

3.1.6.2 Recognition clues

A password tied to a plausible user and service.

3.1.6.2.1 Find the clue from your starting access

Where to investigate: Use the account label from the producing source and the observed service inventory to choose one compatible, correctly qualified validation.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Record exact identity, service and tested read/write/session effect; classify authentication and authorization separately.

Failure/next check: Account disabled, expired password, wrong domain and denied logon require different responses. Avoid repeating a known-valid password against a denied action.

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

Illustrative evidence — synthetic, abbreviated:

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

SMB TARGET [+] DOMAIN\USER: accepted
Administrative execution: not yet demonstrated

Recognize this detail: Accepted authentication proves one service/account pairing; it does not establish shares, administration, RDP or WinRM.

Still missing before method selection: Qualify local/domain/application identity explicitly, test a compatible reachable service and record the accepted identity. Then test the specific share/logon/execution right; successful authentication is not administrative authorization.

Outcome after checking	Example and next decision
Enabled after validation	The intended service operation succeeds under the recorded identity: use that access and re-enumerate.
Ruled out in this context	The secret is valid only for the application and not the proposed OS account: reject that reuse pairing.
Inconclusive	A generic logon failure may hide account/domain/state mismatch; classify it before repeating attempts.

If you do not yet have this clue: start with Classify the artifact and its identity context.

3.1.6.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state.

3.1.6.4 Discover and verify prerequisites

nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD'
ssh -p PORT USER@TARGET

3.1.6.5 Why it works

One password may belong to several independently managed identities. Authentication success is useful only when associated with a precise service and allowed action.

3.1.6.6 Execute and choose variants

Use the normal client for the observed service:

ssh -o PreferredAuthentications=password -p PORT USER@TARGET
nxc smb TARGET -d DOMAIN -u USER -p 'PASSWORD' --shares
evil-winrm -i TARGET -u USER -p 'PASSWORD'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /p:'PASSWORD' /cert:ignore

Local Windows account:

nxc smb TARGET --local-auth -u USER -p 'PASSWORD' --shares

Decisive output: the destination service accepts the intended identity. Share, session or action access is a separate authorization result.

3.1.6.6.1 Variant — known user, targeted password dictionary

hydra -l USER -P WORDLIST -s PORT -t 4 -f ssh://TARGET
hydra -l USER -P WORDLIST -t 1 -f rdp://TARGET

Use only on an assigned target after checking lockout and rate controls. Confirm every reported success with the normal client.

3.1.6.6.2 Variant — one password across an authorized user list

hydra -L USERS -p 'PASSWORD' -s PORT -t 1 rdp://TARGET
nxc smb TARGET -d DOMAIN -u USERS -p 'PASSWORD' --continue-on-success

One attempt per account can still trigger lockout or monitoring. Establish scope, threshold/window and observation period first.

3.1.6.6.3 Variant — HTTP POST form

Capture a correct request and stable failure marker with Burp:

hydra -l USER -P WORDLIST TARGET http-post-form \
  '/LOGIN_PATH:username=^USER^&password=^PASS^:F=STABLE_FAILURE_TEXT'

Dynamic CSRF tokens, cookies, redirects, throttling and uniform responses require manual handling or a different approach. A weak failure marker creates false positives.

3.1.6.6.4 RunasCs — test a known password from an existing Windows shell

Use a reviewed, compatible build on the current Windows host with a known plaintext password. This creates a new local process/logon context; it is not remote execution and does not turn an NT hash into a password.

3.1.6.6.5 Domain account: verify the new process token

REM Domain account: verify the new process token
RunasCs.exe USER PASSWORD "cmd /c whoami /all" -d DOMAIN

3.1.6.6.6 Local account: omit the domain switch for the current host's account

REM Local account: omit the domain switch for the current host's account
RunasCs.exe USER PASSWORD "cmd /c whoami /all"

3.1.6.6.7 Network-only credentials: local identity stays unchanged

REM Network-only credentials: local identity stays unchanged
RunasCs.exe USER PASSWORD "cmd /c dir \\TARGET\SHARE" -d DOMAIN -l 9

Read: in the first two forms, whoami identifies the created process; inspect its groups/integrity before claiming escalation. With logon type 9, local whoami is not a credential test: use the remote operation's result. Logon failure → check account scope, password and permitted logon type. An accepted logon with access denied → inspect authorization on that resource.

RunasCs upstream. Native runas remains an alternative when an interactive password prompt is usable. Neither tool guarantees an elevated token.

accepted identity -> groups/roles -> reachable services -> shares/files
-> authenticated application behavior -> accessible hosts/routes
-> new credentials/tickets/sessions -> privilege and movement handoffs

Verify destination host, accepted identity and actual read/write/execute rights. New hosts/listeners return to discovery; recovered material returns here; operating-system execution enters session handling; domain identities enter AD mapping.

net accounts /domain

Get-DomainPolicyData | Select-Object -ExpandProperty SystemAccess

Password validation belongs to the existing credential procedure. Do not spray by default. If explicitly required, account for lockout threshold, duration, observation window and prior failures; use one justified candidate, stop on lockout/rate-limit evidence and preserve successful identities separately.

3.1.6.7 Worked example — hypothetical

Observation: a configuration contains a username/password. Test: validate the source application first, then an evidence-backed OS/domain reuse. Illustrative output: SMB authenticates but no administrative access exists. Interpretation: enumerate readable shares rather than assume execution.

3.1.6.8 Verify the result

Record exact identity, service and tested read/write/session effect; classify authentication and authorization separately.

3.1.6.9 Failure and fallback

Account disabled, expired password, wrong domain and denied logon require different responses. Avoid repeating a known-valid password against a denied action.

3.1.6.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
SMB/RPC endpoints, domain clues or new credentials	Reachable SMB/RPC; anonymous, guest, local or domain context must be explicit; share and filesystem ACLs both matter	§1.2.6 — Enumerate SMB/RPC shares, files and identities
A credential appears valid but the destination's usable access is unknown	Real source-to-service route, correct identity context and protocol-specific execution/logon rights	§6.4.4.5 — Match route, destination service and effective authorization
An SSH service and a known password, private key or agent context	Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission	§1.2.10 — Use SSH passwords, keys and forwarding-capable access

3.1.7 Recover passwords with feasible dictionary, rule and mask attacks

Choose when: A supported stored verifier or converted protected artifact · Result: A recovered candidate password or a documented exhausted search strategy

Blocks: 5; recurring identity thread. Operational procedure | Operational procedure | Operational procedure | Quick sheet

3.1.7.1 Purpose and result

A recovered candidate password or a documented exhausted search strategy.

3.1.7.2 Recognition clues

A supported stored verifier or converted protected artifact.

3.1.7.2.1 Find the clue from your starting access

Where to investigate: Identify a supported verifier/converter and build candidate structure from relevant names/policy/context rather than selecting an arbitrary hash mode.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Use the tool's show/result output and then validate the recovered credential in its correct context.

Failure/next check: Token/separator errors imply wrong or incomplete input; no recovery means only the tested candidate space was exhausted.

hashcat --example-hashes
john --list=formats

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.

Artifact format matches SUPPORTED_MODE
Candidate model: relevant words plus a justified suffix pattern

Recognize this detail: A verified format and feasible candidate model enable offline recovery; a hash-shaped string alone does not.

Still missing before method selection: Check complete salt/context, conversion correctness, tool backend and whether all required factors are present.

Outcome after checking	Example and next decision
Enabled after validation	The verifier and candidate space are valid: use the selected offline strategy and verify recovered credentials.
Ruled out in this context	The artifact is a non-crackable token or unsupported format under this workflow: reject that mode.
Inconclusive	Parsing errors or an incomplete source require input repair; no recovery only exhausts the tested candidates.

If you do not yet have this clue: start with Classify the artifact and its identity context.

3.1.7.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend.

3.1.7.4 Discover and verify prerequisites

hashcat --example-hashes
john --list=formats

3.1.7.5 Why it works

Offline cracking compares candidate-derived values without contacting the service. Dictionary rules and masks model likely structure; infeasible keyspaces do not become useful through a different tool name.

3.1.7.6 Execute and choose variants

hashcat -b -m MODE
python3 -c "print((CHARSET_SIZE ** LENGTH) / GUESSES_PER_SECOND)"

Use the actual mode and hardware rate. Salts prevent reusable precomputation; iterations and memory-hard KDFs reduce guesses per second. Prefer candidates in this order:

exact recovered/default candidates -> organization/user/product words
-> observed policy and mutations -> small dictionary plus rules
-> known mask/hybrid -> broader curated lists/rules
-> exhaustive search only when its measured cost is defensible

Preview mutations before spending the candidate budget:

hashcat -r /usr/share/hashcat/rules/best64.rule --stdout wordlist.txt | head -n 50
john --wordlist=wordlist.txt --rules=Jumbo --stdout | head -n 50

hashcat -a 0 -m MODE hashes.txt wordlist.txt -r /usr/share/hashcat/rules/best64.rule --session job
hashcat -m MODE hashes.txt --show

-a 0 is dictionary mode. Do not use -a 3 with a wordlist; attack mode 3 expects a mask.

Common source examples identify NTLM as mode 1000, Net-NTLMv2 as 5600 and KeePass as 13400, but confirm against the installed version:

hashcat -h | grep -Ei 'NTLM|NetNTLMv2|KeePass|OpenSSH'

3.1.7.6.1 Mask and session variants

hashcat -m MODE hashes.txt -a 3 '?u?l?l?l?l?d?d?d' --session targeted-mask
hashcat --session targeted-mask --restore

Mask order is a hypothesis about structure. Estimate its keyspace before committing time.

3.1.7.6.2 Hybrid variant — base word plus three digits

hashcat -a 6 -m MODE hashes.txt wordlist.txt '?d?d?d' --session targeted-hybrid

Use only when evidence supports both the base words and suffix shape.

john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt
john --show hash.txt

john --format=FORMAT --wordlist=wordlist.txt --rules=Jumbo hash.txt
john --session=crack-job --wordlist=wordlist.txt hash.txt
john --restore=crack-job

File-to-hash converters:

zip2john archive.zip > archive.hash
7z2john archive.7z > archive.hash
ssh2john id_rsa > ssh.hash
keepass2john vault.kdbx > keepass.hash
pdf2john document.pdf > pdf.hash
office2john document.docx > office.hash
rar2john archive.rar > rar.hash
unshadow passwd.copy shadow.copy > linux.hash

Converter availability varies by package/path; locate it rather than assuming:

command -v ssh2john || find /usr/share/john -maxdepth 2 -iname '*2john*' 2>/dev/null

Preserve the complete converter output. Some formats include a filename label before : that John accepts but Hashcat may require removed from a separate tool-specific copy.

3.1.7.7 Worked example — hypothetical

Observation: a supported verifier and a naming/password-pattern clue exist. Test: validate the mode with a known-format sample and apply a focused rule strategy. Illustrative output: one candidate recovers the verifier. Interpretation: verify it against the intended identity/service.

3.1.7.8 Verify the result

Use the tool's show/result output and then validate the recovered credential in its correct context.

3.1.7.9 Failure and fallback

Token/separator errors imply wrong or incomplete input; no recovery means only the tested candidate space was exhausted.

3.1.7.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
A private key from a file read, share, repository or home directory	Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy	§3.1.9 — Inspect and recover SSH private-key access
A user-owned SPN and a useful service-account relationship	A valid domain authentication/TGT context, reachable KDC, target SPN and a feasible password/encryption candidate strategy	§6.3.11.11 — Request a selected service ticket for offline service-account recovery

3.1.8 Recover a protected KeePass database password

Choose when: A readable KeePass database and possible associated key file · Result: An opened vault or a valid recovered database password

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.8.1 Purpose and result

An opened vault or a valid recovered database password.

3.1.8.2 Recognition clues

A readable KeePass database and possible associated key file.

3.1.8.2.1 Find the clue from your starting access

Where to investigate: Look for a vault in readable backups/shares/application data, then inspect file identity and nearby factor/configuration references.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Complete database, compatible converter, and every required factor; a feasible password candidate strategy

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Open the database with all factors and distinguish vault credentials from target account credentials.

Failure/next check: Missing factors, unsupported versions or malformed conversion require fixing the input, not endless password guessing.

file FILE
keepass2john FILE > keepass.hash

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.

FILE: Keepass password database
Converter: supported verifier produced
Possible additional key file: KEY_FILE

Recognize this detail: A supported database gives a recovery target, but a referenced key file indicates a separate factor.

Still missing before method selection: Confirm vault version, required key/account factors and a feasible password search.

Outcome after checking	Example and next decision
Enabled after validation	All required factors are available and the recovered password opens the vault: inspect its typed credentials.
Ruled out in this context	An unavailable mandatory key factor prevents this password-only route.
Inconclusive	A converter result alone does not identify every required factor; inspect relevant vault configuration.

If you do not yet have this clue: start with Inspect source, backups, configuration and repository artifacts.

3.1.8.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Complete database, compatible converter, and every required factor; a feasible password candidate strategy.

3.1.8.4 Discover and verify prerequisites

file FILE
keepass2john FILE > keepass.hash

3.1.8.5 Why it works

Cracking targets the database's password-derived protection. A key file or other required factor is independent; the password alone may not unlock the vault.

3.1.8.6 Execute and choose variants

keepass2john vault.kdbx > keepass.hash
john --wordlist=wordlist.txt keepass.hash
john --show keepass.hash

Hashcat alternative after confirming KDBX/KDF and input format:

hashcat -hh | grep -i keepass
hashcat -a 0 -m 13400 keepass.hash wordlist.txt -r /usr/share/hashcat/rules/best64.rule
hashcat -m 13400 keepass.hash --show

Mode 13400 covers common KeePass 1/2 AES formats. Installed help and example hashes decide for the actual file. A recovered master password still requires opening and validating the vault.

3.1.8.7 Worked example — hypothetical

Observation: a backup contains a vault. Test: inspect required factors and convert its verifier. Illustrative output: the candidate is recovered but the vault still requests a key file. Interpretation: search the relevant backup context for that factor.

3.1.8.8 Verify the result

Open the database with all factors and distinguish vault credentials from target account credentials.

3.1.8.9 Failure and fallback

Missing factors, unsupported versions or malformed conversion require fixing the input, not endless password guessing.

3.1.8.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A secret-like value, key file, stored hash, challenge response or ticket	Artifact provenance and format; possible local/domain/application identity and compatible protocol	§3.1.5 — Classify the artifact and its identity context
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
JavaScript endpoints, backup names, exposed configuration or Git metadata	Readable application artifact or a complete recoverable repository; preserve the public-source scope	§2.1.8 — Inspect source, backups, configuration and repository artifacts

3.1.9 Inspect and recover SSH private-key access

Choose when: A private key from a file read, share, repository or home directory · Result: A usable key and a verified SSH authentication context

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.9.1 Purpose and result

A usable key and a verified SSH authentication context.

3.1.9.2 Recognition clues

A private key from a file read, share, repository or home directory.

3.1.9.2.1 Find the clue from your starting access

Where to investigate: Trace readable key files from home/configuration/backups to a specific username; inspect the key parser's response before testing the server.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Verify the key parses and an SSH authentication/session succeeds under the correct target identity.

Failure/next check: Invalid format, line endings, wrong passphrase and server rejection are separate layers.

file KEY
ssh-keygen -y -f KEY

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.

KEY: OpenSSH private key
Enter passphrase for KEY:

Recognize this detail: The artifact is a private key protected by a local passphrase; this is separate from the SSH account password.

Still missing before method selection: Determine the protecting passphrase, associated remote user, accepted algorithm and server key authorization.

Outcome after checking	Example and next decision
Enabled after validation	The key parses and the correct server account accepts it: use its permitted shell/subsystem/forwarding capability.
Ruled out in this context	The artifact contains only a public key: reject private-key authentication with that file.
Inconclusive	A decrypted key rejected by the server leaves username/authorization/policy unresolved.

If you do not yet have this clue: start with Recover credentials from Linux user, service and process trails.

3.1.9.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct key format, passphrase if encrypted, matching server account/key authorization and accepted algorithm/policy.

3.1.9.4 Discover and verify prerequisites

chmod 600 KEY
ssh-keygen -y -f KEY

3.1.9.5 Why it works

A private-key passphrase protects the file locally; it is not the remote account password. Server acceptance still depends on user, authorized key, ownership and SSH policy.

3.1.9.6 Execute and choose variants

ssh2john id_rsa > ssh.hash
john --wordlist=wordlist.txt ssh.hash
john --show ssh.hash
chmod 600 id_rsa
ssh-keygen -y -f id_rsa > derived.pub
ssh -vv -i id_rsa -o IdentitiesOnly=yes -p PORT USER@TARGET

Cracking a key passphrase unlocks the file; it does not prove the matching public key is authorized. Permission denied (publickey) can mean wrong user/server, missing authorization or server algorithm/policy after a successful local unlock.

3.1.9.6.1 Hashcat variant — only for a supported OpenSSH format

hashcat -hh | grep -i 'OpenSSH\|Private Key'
hashcat -a 0 -m MODE ssh.hash wordlist.txt -r RULE_FILE

Choose MODE from the complete $sshng$... structure and installed help. Token-length or unsupported-cipher errors require a compatible parser/tool, not --force with a wrong mode.

3.1.9.7 Worked example — hypothetical

Observation: a key parser requests a passphrase. Test: recover its protection using the linked converter procedure, then authenticate as the evidence-backed user. Illustrative output: the key decrypts but the server rejects that username. Interpretation: revisit account mapping rather than cracking again.

3.1.9.8 Verify the result

Verify the key parses and an SSH authentication/session succeeds under the correct target identity.

3.1.9.9 Failure and fallback

Invalid format, line endings, wrong passphrase and server rejection are separate layers.

3.1.9.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
An SSH service and a known password, private key or agent context	Compatible authentication method, correct user, accepted key policy and the requested shell/subsystem permission	§1.2.10 — Use SSH passwords, keys and forwarding-capable access
SSH reaches a server that can access the needed internal service	Accepted SSH identity and forwarding policy; local listener availability and SSH-server-to-destination route	§6.1.3.7 — Forward a selected service through an SSH client-side listener
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse

3.1.10 Recover Linux account passwords from matched records

Choose when: Readable password verifiers and account metadata · Result: A recovered local account password with a justified privilege/reuse test

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.10.1 Purpose and result

A recovered local account password with a justified privilege/reuse test.

3.1.10.2 Recognition clues

Readable password verifiers and account metadata.

3.1.10.2.1 Find the clue from your starting access

Where to investigate: Inspect permission-backed account backups or privileged read results; associate shadow verifiers with the matching passwd metadata.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Tie the recovered password to the correct user and validate an allowed login/sudo transition.

Failure/next check: Mismatched snapshots or locked/expired accounts can defeat use even after recovery; inspect account state.

file passwd.txt shadow.txt
head -n 3 passwd.txt
head -n 3 shadow.txt

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.

passwd: USER:x:USER_ID:GROUP_ID:...:/home/USER:/bin/bash
shadow: USER:$ALGORITHM$SALT$VERIFIER:...

Recognize this detail: The matching account name and verifier prefix identify an offline password-recovery candidate.

Still missing before method selection: Confirm snapshots, hash format and account state; a locked field or absent salt is not a normal usable verifier.

Outcome after checking	Example and next decision
Enabled after validation	A complete supported verifier and feasible candidate space exist: recover, then validate the matching account.
Ruled out in this context	The password field is locked with no usable verifier: reject recovery from that field.
Inconclusive	Mismatched backups or unknown account scope require source consistency checks.

If you do not yet have this clue: start with Recover credentials from Linux user, service and process trails.

3.1.10.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct passwd/shadow pairing or known hash format; account identity and a feasible recovery strategy.

3.1.10.4 Discover and verify prerequisites

unshadow passwd.txt shadow.txt > linux.hashes
john --wordlist=WORDLIST linux.hashes

3.1.10.5 Why it works

The verifier encodes algorithm and salt; passwd metadata maps it to a user. Reading a verifier does not itself change UID or authorize sudo.

3.1.10.6 Execute and choose variants

unshadow passwd.copy shadow.copy > linux.hash
john --wordlist=wordlist.txt --rules=Jumbo linux.hash
john --show linux.hash

Preserve username, UID, shell and lock markers. A recovered password does not override SSH settings, su policy or a disabled account.

3.1.10.7 Worked example — hypothetical

Observation: a backup exposes account metadata and shadow records. Test: combine the matched pair and recover one selected account. Illustrative output: a password is shown for a local user. Interpretation: validate that local identity and inspect its rights.

3.1.10.8 Verify the result

Tie the recovered password to the correct user and validate an allowed login/sudo transition.

3.1.10.9 Failure and fallback

Mismatched snapshots or locked/expired accounts can defeat use even after recovery; inspect account state.

3.1.10.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
sudo -l grants an operation under a more useful identity	Exact executable/run-as/argument rule permits a useful primitive; password tags, environment and policy do not invalidate it	§5.1.8 — Use an allowed sudo operation to cross a privilege boundary
A new Linux foothold or an identity/privilege change	A working command channel and accurate effective identity, group, mount and process context	§5.1.5 — Establish Linux state and choose an escalation candidate

3.1.11 Recover or reuse an NT password hash

Choose when: An NT verifier from an appropriate credential source · Result: A recovered password or a verified hash-backed authentication capability

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.11.1 Purpose and result

A recovered password or a verified hash-backed authentication capability.

3.1.11.2 Recognition clues

An NT verifier from an appropriate credential source.

3.1.11.2.1 Find the clue from your starting access

Where to investigate: Inspect the output schema of a justified local/domain credential source, keeping RID, machine and domain labels.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Verify source/type, identity context and the exact permitted service action.

Failure/next check: Local/domain confusion, remote UAC and denied NTLM are different from an invalid hash. Use tickets only when their own prerequisites exist.

head -n 3 hashes.txt

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.

USER:RID:LM_HASH:NT_HASH:::
Source: matched local registry extraction

Recognize this detail: The source and record fields identify an NT verifier for that local account, not a captured challenge response.

Still missing before method selection: Verify the actual NT field, account scope and an accepting service/client with the required destination right.

Outcome after checking	Example and next decision
Enabled after validation	A compatible service accepts the correctly qualified hash identity: use only its verified authorization.
Ruled out in this context	The source produced Net-NTLMv2 or DCC2 instead: reject direct NT-hash reuse.
Inconclusive	An unlabeled hexadecimal value remains unknown until the source/account is resolved.

If you do not yet have this clue: start with Extract local account hashes from matched SAM and SYSTEM.

3.1.11.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct account/domain and actual NT hash; recovery mode or an accepting NTLM service with required destination rights.

3.1.11.4 Discover and verify prerequisites

hashcat -m 1000 hashes.txt WORDLIST
nxc smb TARGET -d DOMAIN -u USER -H HASH

3.1.11.5 Why it works

Pass-the-Hash uses a long-term NT key in an NTLM exchange; it does not convert every captured hash-like value into a reusable password equivalent.

3.1.11.6 Execute and choose variants

Offline recovery:

hashcat -a 0 -m 1000 nt.hash wordlist.txt -r /usr/share/hashcat/rules/best64.rule
john --format=NT --wordlist=wordlist.txt nt.hash

Compatible SMB validation:

nxc smb TARGET -d DOMAIN -u USER -H NT_HASH --shares
smbclient //TARGET/SHARE -U 'DOMAIN\USER' --pw-nt-hash NT_HASH

NT hashes come from a producing context such as SAM, LSASS or NTDS. A visually similar 32-hex application digest is not PtH material.

3.1.11.6.1 Variant — remote access/execution when the identity has matching rights

impacket-wmiexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'
impacket-psexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /pth:NT_HASH /cert:ignore

WMI needs administrative rights plus DCOM/RPC/SMB reachability and normally runs as the authenticated user. PsExec-style execution needs service-control and writable-share rights and commonly yields SYSTEM. RDP hash authentication depends on target/client support and policy. Detailed method selection belongs to the lateral-movement procedure.

3.1.11.7 Worked example — hypothetical

Observation: a matched SAM/SYSTEM extraction yields a local NT hash. Test: qualify the target-local identity for one reachable service. Illustrative output: authentication succeeds but execution is denied. Interpretation: record valid authentication and investigate effective rights.

3.1.11.8 Verify the result

Verify source/type, identity context and the exact permitted service action.

3.1.11.9 Failure and fallback

Local/domain confusion, remote UAC and denied NTLM are different from an invalid hash. Use tickets only when their own prerequisites exist.

3.1.11.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A password, actual NT hash, AES/NT long-term key or ticket is available	Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization	§6.4.4.6 — Select password, NT hash, key-to-ticket or ticket authentication
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
A destination grants administrative-share write and service-control rights	SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context	§6.4.4.7 — Execute through uploaded service creation using PsExec

3.1.12 Recover a password from a captured NTLM response

Choose when: A complete challenge-response record · Result: A recovered password from the response's offline verifier

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.12.1 Purpose and result

A recovered password from the response's offline verifier.

3.1.12.2 Recognition clues

A complete challenge-response record.

3.1.12.2.1 Find the clue from your starting access

Where to investigate: Use the saved authorized capture's structure and source context; inspect username/domain/challenge/response fields before selecting recovery.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct challenge/response formatting and feasible candidates; acquisition method must fit the allowed context

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Retain response provenance and recovered account/password mapping; confirm relevant login rights separately.

Failure/next check: Incomplete captures or wrong separators break recovery. Prohibited spoofing/poisoning workflows are not an operational exam acquisition method.

head -n 2 responses.txt

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.

USER::DOMAIN:SERVER_CHALLENGE:NT_PROOF:BLOB

Recognize this detail: A challenge-bound response supports its appropriate offline verification workflow; it is not the long-term NT hash.

Still missing before method selection: Check complete capture format, account mapping and feasible candidates; acquisition/relay policy is a separate issue.

Outcome after checking	Example and next decision
Enabled after validation	A complete supported record permits offline recovery and later password validation.
Ruled out in this context	Using this response directly as an NT hash is the wrong mechanism: reject that authentication attempt.
Inconclusive	Truncated challenge/blob fields cannot support a valid recovery conclusion.

If you do not yet have this clue: start with Classify the artifact and its identity context.

3.1.12.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct challenge/response formatting and feasible candidates; acquisition method must fit the allowed context.

3.1.12.4 Discover and verify prerequisites

hashcat -m 5600 responses.txt WORDLIST

3.1.12.5 Why it works

The captured response is bound to its challenge and exchange. It is not an NT hash for direct Pass-the-Hash; relay is a separate live protocol mechanism with additional policy and signing prerequisites.

3.1.12.6 Execute and choose variants

hashcat -a 0 -m 5600 netntlmv2.hash wordlist.txt
john --format=netntlmv2 --wordlist=wordlist.txt netntlmv2.hash

A Net-NTLMv2 response is not an NT hash and cannot be supplied to -H or -hashes. Relay forwards a live authentication exchange and requires received/coerced authentication, compatible protocols, signing/channel-binding conditions and useful rights.

The OSCP+ exam prohibits spoofing, including NBNS. Do not use Responder poisoning on the exam. Keep capture/relay work to explicitly authorized labs and recheck the current guide.

3.1.12.7 Worked example — hypothetical

Observation: a complete response capture is available from an authorized lab record. Test: run the correct offline mode. Illustrative output: a password is recovered. Interpretation: validate its account context rather than feeding the response to a hash-authentication client.

3.1.12.8 Verify the result

Retain response provenance and recovered account/password mapping; confirm relevant login rights separately.

3.1.12.9 Failure and fallback

Incomplete captures or wrong separators break recovery. Prohibited spoofing/poisoning workflows are not an operational exam acquisition method.

3.1.12.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
A supported stored verifier or converted protected artifact	Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend	§3.1.7 — Recover passwords with feasible dictionary, rule and mask attacks
Domain credentials or a domain-joined foothold	Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew	§6.2.9.5 — Establish domain identity, DC, DNS, time and route

3.1.13 Recover a password from cached domain logon verifiers

Choose when: A DCC2/MSCache record from matched SECURITY/SYSTEM material · Result: A recovered domain password, subject to current account state

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.13.1 Purpose and result

A recovered domain password, subject to current account state.

3.1.13.2 Recognition clues

A DCC2/MSCache record from matched SECURITY/SYSTEM material.

3.1.13.2.1 Find the clue from your starting access

Where to investigate: Inspect SECURITY/SYSTEM parser output and distinguish cached-domain logon verifiers from local SAM hashes and service secrets.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct username/salt/iteration context and feasible offline candidates

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Confirm artifact format, account mapping and current password acceptance.

Failure/next check: No recovery does not disprove account existence; stale cached credentials may fail current online authentication.

head -n 3 dcc2.txt

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.

$DCC2$ITERATIONS#USER#VERIFIER

Recognize this detail: The DCC2 structure and username-associated derivation identify offline cached-logon material.

Still missing before method selection: Verify iteration/username context, source consistency and current online account state after any recovery.

Outcome after checking	Example and next decision
Enabled after validation	A complete supported record and feasible candidates enable the DCC2 recovery workflow.
Ruled out in this context	DCC2 is not accepted directly as an NTLM long-term hash: reject that reuse route.
Inconclusive	A recovered old password may be stale; validate current account acceptance without assuming extraction failed.

If you do not yet have this clue: start with Extract LSA secrets and cached-domain verifiers.

3.1.13.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct username/salt/iteration context and feasible offline candidates.

3.1.13.4 Discover and verify prerequisites

hashcat -m 2100 dcc2.txt WORDLIST

3.1.13.5 Why it works

Cached interactive-logon verifiers support offline logon checks; they are not reusable NT hashes. Their derivation makes cracking materially different from NT recovery.

3.1.13.6 Execute and choose variants

hashcat -hh | grep -i 'Domain Cached'
john --format=mscash2 --wordlist=wordlist.txt dcc2.hash

Preserve the username because it participates in the verifier. DCC2 is an offline recovery target, not ordinary PtH material.

3.1.13.7 Worked example — hypothetical

Observation: cached domain data is extracted. Test: classify it before selecting a tool mode. Illustrative output: DCC2 is identified and one password is recovered. Interpretation: validate against the live domain; the cached value may be stale.

3.1.13.8 Verify the result

Confirm artifact format, account mapping and current password acceptance.

3.1.13.9 Failure and fallback

No recovery does not disprove account existence; stale cached credentials may fail current online authentication.

3.1.13.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A password tied to a plausible user and service	Correct local/domain/application identity, reachable compatible service, accepted authentication and account state	§3.1.6 — Validate known passwords and context-specific reuse
Domain credentials or a domain-joined foothold	Correct realm/domain and account qualification; reachable DC/services, usable DNS and acceptable clock skew	§6.2.9.5 — Establish domain identity, DC, DNS, time and route
A supported stored verifier or converted protected artifact	Correct format/mode, complete salt/context, justified candidates and an available offline tool/backend	§3.1.7 — Recover passwords with feasible dictionary, rule and mask attacks

3.1.14 Classify tickets and use a compatible cache

Blocks: 5; recurring identity thread. Operational procedure | Quick sheet

3.1.14.1 Purpose and result

A verified Kerberos authentication capability for an appropriate service.

3.1.14.2 Recognition clues

A ccache/kirbi file or an existing ticket cache.

3.1.14.2.1 Find the clue from your starting access

Where to investigate: Inspect an existing ticket/cache before collecting new material; identify its client, service, realm and validity.

Discovery action — reference example:

Access/context: A credential artifact with a recorded source and possible account context

Conditions, effects and verification

Requires: Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route

Action class: Credential processing and selected authentication; online guessing can affect lockout state.

Stop/verify: Inspect principal, ticket service, realm and lifetime, then verify the actual service action.

Failure/next check: Expired tickets, wrong hostname/SPN, cache format and time skew require different fixes; an IP-only connection can break correct Kerberos naming.

klist -c FILE

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.

Default principal: USER@REALM
Service principal: cifs/TARGET_HOST@REALM
No krbtgt ticket listed

Recognize this detail: This is service-scoped CIFS material, not a TGT for requesting arbitrary services.

Still missing before method selection: Check lifetime, cache format, exact SPN/name, route and destination object authorization.

Outcome after checking	Example and next decision
Enabled after validation	The matching SMB service accepts the ticket and allowed operation: use that scoped capability.
Ruled out in this context	A CIFS-only ticket does not enable a WinRM-specific authentication path.
Inconclusive	An unreadable/expired cache or unknown principal requires inspection/conversion rather than guessed reuse.

If you do not yet have this clue: start with Inventory, convert and import tickets in the correct logon context.

3.1.14.3 Prerequisites

Starting access: A credential artifact with a recorded source and possible account context. Required conditions: Correct principal/realm, valid lifetime, service scope, compatible cache format and naming/KDC route.

3.1.14.4 Discover and verify prerequisites

klist -c FILE

3.1.14.5 Why it works

A TGT can request service tickets; a TGS is scoped to a service/SPN. A ticket for CIFS cannot simply be used as a WinRM credential.

3.1.14.6 Execute and choose variants

Inspect before use:

klist
KRB5CCNAME=TICKET.ccache klist
impacket-ticketConverter TICKET.kirbi TICKET.ccache

Compatible client example:

export KRB5CCNAME=TICKET.ccache
impacket-wmiexec -k -no-pass 'DOMAIN/USER@HOST.DOMAIN'

Verify client principal, realm, TGT versus service ticket, SPN, start/end time, clock, DNS/FQDN and routes. A readable cache does not prove authorization. Roasting, forging and detailed PtT/overpass belong to the AD procedures.

3.1.14.7 Worked example — hypothetical

Observation: a cache contains a CIFS ticket but no TGT. Test: inspect client/server principals and lifetime. Illustrative output: the target CIFS SPN matches. Interpretation: choose a compatible SMB client, not an arbitrary remote service.

3.1.14.8 Verify the result

Inspect principal, ticket service, realm and lifetime, then verify the actual service action.

3.1.14.9 Failure and fallback

Expired tickets, wrong hostname/SPN, cache format and time skew require different fixes; an IP-only connection can break correct Kerberos naming.

3.1.14.10 Continue from the interpreted result

Observed result	Check before proceeding	Next numbered section
A valid ticket/cache or a long-term key that can request a TGT	Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context	§6.3.11.13 — Inventory, convert and import tickets in the correct logon context
A password, actual NT hash, AES/NT long-term key or ticket is available	Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization	§6.4.4.6 — Select password, NT hash, key-to-ticket or ticket authentication
An IP connection works while hostname/Kerberos access fails	Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time	§6.1.3.18 — Preserve DNS, Kerberos names and time across a pivot

3.1.15 Sources and shared concepts

Supplied PEN-200 Ch 16 pp442–493. Hashcat examples, John documentation.

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