Cracking cached domain credentials (DCC2 / MS-Cache v2)

You popped local admin on a laptop. No domain controller in reach, no clean domain credentials in memory, just a workstation that has been off the corporate network for a week. The user has still logged in during that week. So where did Windows check the password?

Cached domain credentials. DCC2. They are sitting in the registry, and on the right engagement they are the only foothold you have into the domain.

What they are and where they live

When a domain-joined machine cannot reach a DC, it still needs to let the domain user log in. So Windows caches a verifier from the last successful logon and validates against that offline. By default it keeps the last ten.

That verifier is MS-Cache v2, also called DCC2 (Domain Cached Credentials version 2). It lives in the registry under HKLM\SECURITY\Cache, which is locked away under SYSTEM and not readable as a normal admin. You need to be SYSTEM, or you dump the hive offline.

The important property: DCC2 is a one-way derivation. It is not the password, not the NT hash you can pass, and it never touches the network. The machine computes it locally and compares. Which means your only path is to crack it.

Getting them out

Impacket's secretsdump.py reads them straight if you point it at the local hives. Grab SYSTEM and SECURITY (from a live box with reg save, or from a disk image) and run it in LOCAL mode:

secretsdump.py -security SECURITY -system SYSTEM LOCAL

The cached creds come out in a clearly labelled block:

[*] Dumping cached domain logon information (domain/username:hash)
CONTOSO.LOCAL/jdoe:$DCC2$10240#jdoe#a1b2c3d4e5f6...

mimikatz does it live from SYSTEM with lsadump::cache. Same data, same format. Either way you end up with the DCC2 hash:

$DCC2$10240#user#hexdigest

The 10240 is the iteration count. The user is the account name folded into the derivation, which is why DCC2 cannot share a precomputed table the way unsalted hashes can. The username is effectively the salt.

Cracking it: mode 2100, and patience

Feed the whole $DCC2$... string to hashcat mode 2100:

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

John calls it mscash2:

john --format=mscash2 --wordlist=rockyou.txt dcc2.txt

Now the warning. Do not treat this like NTLM. DCC2 is PBKDF2-HMAC-SHA1 wrapped around the NTLM hash, with 10240 iterations. That iteration count exists specifically to be slow, and it works. Where raw NTLM cracks at tens of billions per second, DCC2 on the same GPU manages somewhere in the low hundreds of thousands per second. That is five orders of magnitude slower.

So the brute-force instinct is wrong here. A 14-million-word run with a heavy rule set that finishes in seconds against NTLM can run for hours against DCC2, and a mask attack past a handful of characters is hopeless. You do not throw the kitchen sink at DCC2.

You throw a scalpel. Targeted lists. The company name with seasons and years, the help-desk reset pattern, anything you already cracked elsewhere in the domain, mangled with a focused rule set. The whole discipline of picking the right wordlist and rules matters far more on DCC2 than on a fast hash, because every wasted candidate costs real GPU time. If you are unsure which mode a given hash even maps to, the hashcat mode lookup sorts it before you waste a run.

When you do crack it, you have the cleartext. That is the only usable output. There is no pass-the-DCC2.

When this is the play

DCC2 shines in one specific spot: you have local admin or SYSTEM on an endpoint, but no line to a DC and no other domain creds. A stolen or seized laptop. A workstation you compromised that has been offline. A forensic image.

In those cases the cached entries are your bridge from local to domain. Crack one and you have a real domain user's password, which you can then spray, reuse, or escalate with. It is slow, so you commit to it only when faster paths (LSASS dumps, tickets, NetNTLMv2 capture) are closed.

The defender's side

Two levers, both blunt and both effective.

Limit the cached logon count. The policy Interactive logon: Number of previous logons to cache defaults to 10. On servers and high-value hosts that never need offline logon, set it to 0 or 1. Fewer cached verifiers means fewer hashes for an attacker to walk away with, and on a server the offline-logon scenario rarely justifies the exposure.

But the real defense is the same one that defends everything else: password strength. DCC2's slowness only buys you time. A user with Summer2026! falls to a targeted list regardless of 10240 iterations, because the candidate is in the first thousand guesses. A user with a long random passphrase survives, because the slowness multiplied by a huge keyspace becomes geological. The iteration count is a force multiplier on a strong password and nearly worthless on a weak one. So the cached hash exposure is real, but the password policy is what decides whether the exposure ever turns into a domain credential.