Cached Domain Credentials: The Laptop That Remembers Your Password

Here is a fact that surprises people the first time they hear it: your Windows laptop can log you into your domain account when it is sitting on a plane with no network. There is no domain controller to check your password against at 35,000 feet - and yet it works. That is by design, and the mechanism behind it is cached domain credentials.

The feature is genuinely useful. Without it, every remote or occasionally-connected machine would be locked out the moment it lost line of sight to a DC. But like most convenience features on Windows, the security cost is quiet and easy to ignore - and on a domain-joined fleet it is a lateral-movement goldmine.

What actually gets cached

Windows does not store your plaintext password, and it does not store the NTLM hash either. When you log on to a domain account interactively, the machine derives and stores a verifier known as MSCACHEv2 (also called DCC2, Domain Cached Credentials v2, introduced with Vista/Server 2008). It is a PBKDF2-wrapped, salted hash of your credentials, kept under the registry hive:

HKLM\SECURITY\Cache

That hive is only readable by SYSTEM, so a normal user can't just open regedit and read it. The number of accounts cached this way is governed by a single policy value:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  CachedLogonsCount   (REG_SZ, default "10")

Default of 10 means the last ten distinct domain accounts to log on interactively each leave a cached verifier behind - including that domain admin who RDP'd in once to fix a printer.

Why attackers love it

• It survives offline. An attacker with SYSTEM/admin on one box can dump the cache from HKLM\SECURITY\Cache with tooling like secretsdump or Mimikatz's lsadump::cache - no DC contact, no network noise.
• DCC2 is crackable offline. Unlike a Kerberos TGT, an MSCACHEv2 verifier is a password hash you can throw at Hashcat (-m 2100). Weak or reused passwords fall in hours. There is no online lockout to slow the attacker down.
• Privileged accounts get cached where they shouldn't. The real damage is a Tier-0 or helpdesk-admin credential cached on a Tier-2 workstation. Crack that verifier and you have escalated across your admin tiers without ever touching a domain controller.
• It's invisible to most audits. The cache doesn't show up in a share scan or a running-process review. If you aren't specifically checking CachedLogonsCount and who has logged on, you don't know it exists.

What to audit

You are balancing two things: usability for legitimately-offline users, and blast radius when a machine is compromised. A few checks give you most of the visibility:

1. The cache depth. Read CachedLogonsCount. On always-connected servers and domain controllers it should be 0. On kiosks and fixed desktops, a low value (1-4) is reasonable. Only genuinely mobile laptops need the default of 10.
2. Privileged accounts on non-privileged machines. Cross-reference interactive/RDP logon history (Security event IDs 4624 type 2/10) against your admin groups. A domain admin that logged on to a standard workstation left a crackable verifier behind.
3. Password policy strength. The cache is only as safe as the password behind it. Short or reused domain passwords make DCC2 cracking trivial - this is where a strong policy and not reusing admin passwords across tiers pays off.
4. Full offline-lockout candidates. Domain controllers and servers that never operate disconnected can safely set CachedLogonsCount = 0, removing the cache entirely.

A quick manual pass:

# How many accounts does this machine cache?
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon' `
  -Name CachedLogonsCount -ErrorAction SilentlyContinue |
  Select-Object CachedLogonsCount

# Who has logged on interactively / over RDP recently? (mind the noise)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4624 } -MaxEvents 200 |
  Where-Object { $_.Properties[8].Value -in 2,10 } |   # LogonType 2=interactive, 10=RDP
  ForEach-Object { $_.Properties[5].Value } | Sort-Object -Unique

Reading the cached verifiers themselves requires SYSTEM and is exactly what you're trying to prevent an attacker from doing - so the audit angle is about reducing what's cached and who's exposed, not dumping it yourself.

How WinSentinel handles it

WinSentinel's Identity & Credential module scores this without any registry spelunking. It reads CachedLogonsCount and flags values that are too high for the machine's role, correlates recent privileged logons against your admin groups to surface "a domain admin cached a verifier on this workstation," and folds it in next to the rest of the credential-hygiene picture (local admin sprawl, stale accounts, password-never-expires, LAPS posture). Each finding carries a severity, a plain-English explanation of the risk, and - where it's safe to automate - a one-click fix such as lowering the cache depth on a machine that never operates offline.

All of this runs locally on a single machine and is part of the free, open-source tier - install with dotnet tool install --global WinSentinel.Cli and run winsentinel --audit. If you run more than a handful of endpoints, WinSentinel Pro rolls the same credential-hygiene checks up across your whole fleet, so "which machines have a Tier-0 admin cached on them?" becomes one query instead of one login at a time.

Offline logon is a feature you asked for. A crackable domain-admin verifier sitting on a laptop is the bill that comes with it - so audit how deep the cache goes and who's in it.