29

How are cached Active Directory domain credentials stored on a Windows client? Are they stored in the local SAM database, thus making them susceptible to the same rainbow table attacks that local user accounts are susceptible to, or are they stored differently? Note, that I do realize that they are salted and hashed, so as not to be stored in plain-text, but are they hashed in the same way as local accounts and are they stored in the same location?

I realize that at a minimum they're be susceptible to a brute force attack, but that's a much better situation than being vulnerable to rainbow tables in the event of a stolen machine.

Improve this question

3 Answers 3

Reset to default
21

"Cached credentials"

Cached credentials for an AD domain are actually salted double hashes of the password and stored in the HKLM\Security hive. The file location of the hive is: %systemroot%\System32\config\SECURITY

Only the "system" user has access to the registry keys:
HKLM\Security\Cache\NL$n where n is an index 1 to the maximum number of cached credentials.

Susceptibility to Attacks

WinNT to WinXP used "Lan Manager" hashes for local accounts, which are easily broken on modern hardware. Cracking usually takes several minutes (I recently did 3 passwords in 00:08:06) with just a "normal" desktop computer. Lan Manager hashes are not salted, so there are publicly available rainbow tables too.

Vista and later use NT hashes for local accounts. Windows 2000 and later use NT hashes for domain accounts as well. NT hashes are salted double-MD4 hashes. The per-entry salt prevents the use of rainbow tables, but MD4 can be executed very fast on modern hardware: about 6 compute-years for a 60-bit password. With luck and a 6 GPU cluster a cracker can break this sort of password in ~6 months. Taking that to the cloud, about $35k on Amazon EC2 GPU - depending on availability, it could be hours.

Improve this answer
4
  • I guess the bigger part of my question was whether or not these stored credentials are susceptible to the same rainbow table-based attacks as local accounts of if they are hashed in a different method
    – MDMarra
    Dec 3, 2012 at 16:04
  • Updated... Vista+ it's all the same. Older versions were different.
    – Chris S
    Dec 3, 2012 at 16:09
  • "The NT hash of the password is calculated by using an unsalted MD4 hash algorithm." -- Straight from TechNet: technet.microsoft.com/en-us/library/hh994565(v=ws.10).aspx
    – thepip3r
    Sep 4, 2014 at 18:35
  • That page is wrong, NT hashes are salted. See Joe's answer below for a link to a KB.
    – Chris S
    Sep 4, 2014 at 18:42
5

The credentials aren't actually cached on the local machine. See this excerpt from MS:

Security of cached domain credentials

The term cached credentials does not accurately describe how Windows caches logon information for domain logons. In Windows 2000 and in later versions of Windows, the username and password are not cached. Instead, the system stores an encrypted verifier of the password. This verifier is a salted MD4 hash that is computed two times. The double computation effectively makes the verifier a hash of the hash of the user password. This behavior is unlike the behavior of Microsoft Windows NT 4.0 and earlier versions of Windows NT.

http://support.microsoft.com/kb/913485

Improve this answer
3
  • Right, I understand that the credentials themselves are not actually cached, but my question was more along the lines of "are the resulting hashes stored in the local SAM database the same way that local accounts are, thus making them vulerable to the same attacks." I'll edit this in a minute to be a bit more clear.
    – MDMarra
    Dec 3, 2012 at 15:45
  • 1
    meh.. to me this is mincing words. the nature of "hashing" is a one-way process that creates basically an obfuscated value of the password using a cryptographically secure algorithm. The problem is that MD4 may have been cryptographically secure 10-15 years ago but is not even close anymore (neither is MD5 or SHA1 from a cryptographer's standpoint). So, if you have present-day hardware that can quickly brute force the key space of the algorithm or uncover a collision, then you can easily derive the password from the hash...
    – thepip3r
    Sep 4, 2014 at 18:42
  • If the credentials are stored in any way or form so that they can be verified in offline mode - then they are for all intents and purposes cached, no matter how the data in that cache looks
    – NiKiZe
    Jan 10, 2019 at 7:56
4

They are handled by the Credential Manager, for which there is a Credential Manager API. The salted hashes are stored in a somewhat secure manner on disk and accessed via HKLM\Security. (Which can only be accessed by LocalSystem by default, but is easy to bypass, for example, by psexec -i -s regedit.exe.)

On a running Windows system however, the situation is more dire, as recently used credentials can be gotten and easily reversed into plain-text by hooking a DLL into Lsass. (See Mimikatz.)

So yeah, you'll find some sort of hash (or hash of a hash, or 'verifier' or whatever you want to call it) at HKLM\Security\Cache on the client. But I don't think there's any feasible way to attack the hash on disk. It's not the same old kind of NTLM hash that is attackable.

Improve this answer
1
  • Offline password cracking in the SAM is completely different than hooking LSASS in memory as Mimikatz and WCE do. And depending on the password complexity, offline password cracking of the SAM can be VERY easy (see samdump2)
    – thepip3r
    Sep 4, 2014 at 18:37

You must log in to answer this question.

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