A quick something I’ve been wondering: why is the boot key used to access the encrypted SAM database hashes, (and not another key,) and also what encryption mechanism is actually used to encrypt the SAM database?

1 Answer 1


While I haven't verified this, the password hashes (and other secrets) in the SAM (and other system-wide locations) are almost certainly encrypted using DPAPI (or see https://en.wikipedia.org/wiki/Data_Protection_API), using the local machine key. On modern systems, this means AES-256 (though I think still in CBC mode) with HMAC-SHA2-512 for integrity (according to the answer here: https://stackoverflow.com/questions/51971447/which-encryption-algorithm-does-the-protectdata-class-use).

As for why the machine key is used, it's quite simple: the OS doesn't have access to any other keys before a user authenticates, and the OS needs the password hashes (or other credential verifiers) to authenticate users! Per-user DPAPI keys are protected using a key derived from the user's password (yes, even with Windows Hello, where either the password itself or its derived key is stored encrypted by a key derived from the Windows Hello secret, which uses far stronger hashing than the old NTLM hash that's mostly just unsalted MD4).

This does, of course, mean that any attacker who has full access to the file system (e.g. because the drive is being accessed "offline" under another OS) can extract the password hashes; all they need to do is extract their ciphertext from the SAM hive, extract the machine key, and apply the latter to the former. This is how offline password cracking tools for Windows work. There's no actual security boundary between attackers and the hashes, here - encrypting the hashes is really just obfuscation - but in theory there doesn't need to be, because the hashes can't be reversed. (Consider by comparison the /etc/shadow file on *nix, where password hashes are stored in plain text). Furthermore, any process running under any user can call DPAPI with the machine key, but that doesn't increase the risk; an attacker either needs offline access to the driver or Administrator-level permissions to read the SAM hive (much like how only root can read /etc/shadow), and if the attacker has that level of access, they can also access the machine key.

  • Yes- thank you. This is helpful- so how does a SAM dump program such as impacket-secretsdump collect the boot key in the first place? Commented May 13 at 6:35
  • The local machine key - what you're calling the "boot key" though I can't find anything else that uses that term (please link if you have something) - is stored in the hard disk - possibly in the SAM hive itself, though I'm not sure of that - in effectively plain text form (it's hard to get to, but there doesn't exist any secret to encrypt it with, so it's basically just hidden/obfuscated, not actually encrypted or anything). It's unique to every installation, so you need access to the computer (or disk) to find it, but it's available before any secret could be entered, so it's de facto public
    – CBHacking
    Commented May 13 at 8:15
  • Ohhh… I think I understand what you mean now! I only call it the “boot key” because when I use impacket to extract the local SAM hashes it displays what is says is a boot key: and then includes a long string of lowercase letters and numbers. I also looked it up. Thanks for the answer and follow up- upvoted! Commented May 13 at 9:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .