How the Windows boot key (syskey) works
The boot key is the root of all offline credential dumping. Here is where it lives, why it is scrambled across four registry keys, and how to reassemble it from the SYSTEM hive.
Almost everything an offline credential dumper does — decrypting SAM hashes,
LSA secrets, or NTDS.dit — starts with one 16-byte value: the boot key,
historically called the syskey. It is the master key the operating system
mixes into every credential-encryption routine, and it never leaves the
machine's registry. If you can read the SYSTEM hive, you can reconstruct it.
Where it lives
The boot key is not stored as a value. It is hidden in the class names of four subkeys under the current control set:
SYSTEM\CurrentControlSet\Control\Lsa\JD
SYSTEM\CurrentControlSet\Control\Lsa\Skew1
SYSTEM\CurrentControlSet\Control\Lsa\GBG
SYSTEM\CurrentControlSet\Control\Lsa\Data
A registry key's class name is an obscure, rarely used field in the nk
(named key) cell of a hive. That is precisely why Microsoft chose it — most
tooling never looks there. Each of the four class names is a UTF-16LE string of
eight hexadecimal characters, so together they encode 4 × 8 = 32 hex digits,
or 16 raw bytes.
The current control set is resolved from
SYSTEM\Select\Current, which is a little-endian integer;1meansControlSet001, and so on.
Reassembling it
Concatenating the four class strings gives you the scrambled key. The final step is a fixed byte permutation:
transforms = [8, 5, 4, 2, 11, 9, 13, 3, 0, 6, 1, 12, 14, 10, 15, 7]
bootKey[i] = scrambled[transforms[i]]
That descrambled 16-byte array is the boot key. From here it feeds three different key-derivation paths:
- SAM mixes it with two fixed strings and an MD5 to produce the hashed boot key, which then unwraps each account's NT/LM hash.
- SECURITY runs it through a 1000-round SHA-256 (Vista+) to recover the LSA key, which in turn unlocks LSA secrets and the cached-credentials key.
- NTDS.dit uses it to decrypt the Password Encryption Key (PEK) list.
Why class names, not a value
Reading a class name requires walking to the nk cell, reading its
class_name_offset and class_name_length fields, and following the offset
into the hive's data region. Many high-level registry libraries do not expose
this at all — they surface values and subkeys but skip the class. A dumper
therefore has to parse the hive structure a little more deeply than a typical
registry reader.
That single design decision — splitting the key, hiding it in an infrequently-parsed field — is a good reminder that obscurity slows tools down but never substitutes for the actual cryptography that follows.