OSCP: One Captured Hash, Two Very Different Decisions

One Captured Hash, Two Very Different Decisions

On an internal engagement you poison an SMB share and capture an NTLMv2 response for CORP\jsmith, a helpdesk user. From a separate misconfigured backup share you recover the local SAM database from a workstation and extract the NTLM hash of the local Administrator account on that one machine. Your cracking rig does roughly 1.1 MH/s on hashcat mode 5600 and about 8 GH/s on mode 1000. The written password policy states a 12-character minimum with complexity; no lockout threshold is documented anywhere you can read. You have rockyou.txt, a 2-million-entry corporate-themed wordlist, and rules files. You do not have any credentials that work yet, and the client's rules of engagement permit password guessing against production accounts only if lockout is proven not to be triggered.

1. Decide what to do with each hash, and defend the choice in terms of expected time cost.

Read the worked answer

Two hashes, two completely different cost models.

Local Administrator NTLM: no cracking is required. NTLM is pass-the-hash capable, so the hash is already a credential for that workstation. Cost: one tool invocation. Ceiling: one machine, unless the local admin password is reused across the fleet - which you can test cheaply by attempting the same PtH against the next host and watching for STATUS_LOGON_FAILURE.

jsmith NTLMv2: this hash cannot be passed; NetNTLMv2 requires a challenge-response, so it must be cracked or relayed. At 1.1 MH/s, mode 5600 with rockyou plus best64 rules is a few minutes - worth doing immediately. A 2-million corporate wordlist with a heavy rule set is hours, and a 12-character complexity policy means pure brute force is off the table forever. Decision: run the cheap dictionary pass now, and if it fails, do not queue an overnight job.

The misjudgement to avoid is grinding on the domain hash while an immediately usable local credential sits unspent. Also consider relaying the NTLMv2 instead of cracking it if SMB signing is absent on the target - that converts the same capture into access without any GPU time.

2. Before any guessing against domain accounts, how do you prove whether lockout exists - with only a domain user's context, or none at all?

Read the worked answer

Prove it from policy, never from a probe against a live user.

Any domain-joined host, ordinary user: net accounts /domain prints the lockout threshold and duration. This is a single authenticated read and cannot lock anyone out.
RSAT or PowerShell with any valid credential: Get-ADDefaultDomainPasswordPolicy returns LockoutThreshold, LockoutDuration and ObservationWindow. Fine-grained policies can override at the OU level: Get-ADFineGrainedPasswordPolicy -Filter * and check AppliesTo.
Pure LDAP, no RSAT: query the domain object's lockoutThreshold/lockoutDuration attributes via ldapsearch against 389 using any authenticated bind.
No credentials at all: you cannot read policy anonymously. In that case, do not spray. Instead look for the value indirectly - a previously captured net accounts output in a share, a GPO report in SYSVOL, or documentation. If none exists, treat the threshold as 1 and do not guess.

If you do spray after proving a threshold, design to it: one password, one attempt per account, spaced beyond the observation window, with a decoy account of your own in the target list so a lockout shows up benignly. badPwdCount and lockoutTime are readable per user by any authenticated principal, so poll them between rounds rather than trusting your own bookkeeping.