Can cached domain logon verifiers taken from a laptop's SECURITY hive be replayed to the domain?
answer
- verifier, not credential
- for signing in with no controller reachable
- no protocol speaks it
- salted, many iterations, slow
- cracking yields plaintext, not a hash
basics
~10 sNo. Cached domain logon verifiers exist only so a laptop can validate a logon while no domain controller is reachable. No authentication protocol accepts them, so the only route is slow offline password guessing.
solid answer
~50 sWindows caches a verifier for recent domain logons in the `SECURITY` hive so a user can sign in to a laptop away from the network — ten of them by default. The cached value is deliberately not the account's NT hash and deliberately not something any protocol speaks: it is a slow key derivation, PBKDF2-HMAC-SHA1 with thousands of iterations, salted with the user name, computed over the password-derived hash. Because no service will accept it as proof of possession, it cannot be presented anywhere; the only attack is guessing candidate passwords and running the same derivation. Compared with an unsalted NT hash, that is orders of magnitude slower per guess and the salt kills precomputation. The payoff is real when it lands, though: a successful guess yields the plaintext password, which then also opens the user's password-chained stores.
go deeper
Know why the cache exists at all: it lets someone sign in to a domain-joined laptop when no domain controller can be reached, by checking the typed password locally.
Explain the construction — salted, heavily iterated, derived from the password hash — and state plainly that no authentication protocol will accept the stored value.
Show you can correct the confident "cached credentials, so pass them" answer and reason about the actual economics: slow per guess, no precomputation, but plaintext as the prize.
Frame the tradeoff you would set fleet-wide: how many logons to cache on which classes of machine, weighed against offline sign-in for travelling staff and against password length policy.
## Why the cache exists at all A domain account is validated by a domain controller. A laptop on a train has no controller, so Windows keeps a **verifier** for a small number of recent interactive domain logons — the policy is "Interactive logon: Number of previous logons to cache", ten by default on client Windows. When the user signs in offline, the machine recomputes the verifier from the typed password and compares. The key word is *verifier*, not *credential*. Its whole job is to answer "is this the same password as last time" locally. It is never sent anywhere and nothing on the network is prepared to receive it. ## What the stored value actually is On modern Windows the format is commonly called MSCACHEv2 or DCC2. Its construction is deliberate: - start from the password-derived hash for the account; - salt with the (lower-cased) user name, so two users with the same password produce different verifiers and precomputed tables are useless; - run **PBKDF2-HMAC-SHA1** with a high iteration count — 10240 by default — so each candidate guess costs real work. That is a password-hashing construction chosen for storage, not an authentication token. Contrast it with the NT hash, which is a single unsalted MD4 over the password — fast to compute, identical across users with the same password, and accepted by protocols as proof of possession. ## The wrong answer, and why competent people give it The common senior-level error is: *"cached credentials, so we can pass them."* The instinct comes from a true fact about a different artefact — a stored password derivative that a challenge-response protocol will accept without ever seeing the password. Cached domain verifiers look superficially like the same thing: they live on a workstation, they are derived from the password, they are called "cached credentials" in everyday speech. But the property that makes a derivative replayable is that **some verifier on the other end expects exactly that value**. Nothing expects the cached logon verifier except the local logon path on that one machine, which already has its own copy. There is no service to present it to, no protocol field to put it in, and no ticket to request with it. It is a dead end by construction. ## What it is worth, then Exactly one thing: an offline guessing target. The economics: | Property | NT hash | Cached domain verifier | |---|---|---| | Salted | no | yes, by user name | | Iterations | one MD4 | 10240 PBKDF2-HMAC-SHA1 | | Precomputation useful | yes | no | | Directly presentable to a service | yes | no | | Cracking yields | the password | the password | So per guess it is far slower, and rainbow-style precomputation is off the table. A long random passphrase behind it is, practically speaking, out of reach. A season-and-year password is not — iteration counts buy a factor, not immunity, and the attacker chooses the wordlist. When it does fall, the payoff is larger than a hash: **plaintext**. That is the account's actual password, which authenticates anywhere the account is valid and also satisfies the unwrap condition on the user's password-chained on-disk stores. A single cracked verifier can therefore convert a whole tier of otherwise-sealed local material. ## Where it sits in the ranking of on-disk material If you rank what a copied laptop yields by the work needed before it is usable, the cached verifiers are the bottom rung: not usable as-is, not openable with the user's session, only crackable — and only worth cracking when the password policy is weak or the account is one a human chose a memorable password for. Which is also the practical mitigation: length, uniqueness, and lowering the cached-logon count on machines that never leave the network to shrink how many accounts a stolen laptop even holds a verifier for.
- Why is a cached domain verifier so much slower to attack than an NT hash?The NT hash is a single unsalted MD4 over the password: one cheap operation per guess and identical for any two users sharing a password, so precomputation works. The cached verifier is PBKDF2-HMAC-SHA1 with 10240 iterations salted by the user name, so every guess costs thousands of hash operations and must be redone per account.
- What does the attacker gain when a cached verifier does crack?The plaintext password itself, not a derivative. That authenticates wherever the account is valid and also satisfies the unwrap condition for the user's password-chained local stores, so one crack can open material that was otherwise sealed. It is a slow attack with a disproportionately large payoff.
- Is reducing the number of cached logons a useful setting?On machines that never leave the corporate network, yes — it shrinks how many distinct accounts a copied laptop holds a verifier for, which matters most on shared or administrative workstations. Setting it to zero breaks offline sign-in entirely, so laptops usually keep a small non-zero value; it is a scoping control, not a strength control.
saying these in an interview costs you the question
- Says cached domain credentials can be passed to a service
- Calls the cached value the account's NT hash
- Thinks the cache is sent to a controller for validation
- Assumes high iteration counts make weak passwords safe
- Believes cracking it yields only another hash