Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

3 Answers 3

up vote 15 down vote accepted

"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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.
{"cc_re__cc_re__cc_by_sa_3_0": ["sites in the Stack Exchange network\">Area 51</a></li>\r\n                        <li><a href=\"//careers.stackoverflow.com?utm_source=stackoverflow.com&amp;utm_medium=site-ui&amp;utm_campaign=footerlink\">Stack Overflow Careers</a></li>\r\n                    \r\n                </ol>\r\n            </td>\r\n    </tr>\r\n</table>\r\n                </div>\r\n            </div>\r\n\r\n            <div id=\"copyright\">\r\n                site design / logo &#169; 2014 stack exchange inc; user contributions licensed under <a href=\"http://creativecommons.org/licenses/by-sa/3.0/\" rel=\"license\">cc by-sa 3.0</a>                   with <a href=\"http://blog.stackoverflow.com/2009/06/attribution-required/\" rel=\"license\">attribution required</a>\r\n            </div>\r\n            <div id=\"svnrev\">\r\n                rev 2014.11.27.2050\r\n            </div>\r\n            \r\n        </div>\r\n    </div>\r\n    <noscript>\r\n        <div id=\"noscript-warning\">Server Fault works best with JavaScript enabled<img src=\"http://pixel.quantserve.com/pixel/p-c1rF4kxgLUzNc.gif\" alt=\"\" class=\"dno\"></div>\r\n    </nosc"], "copyright__copyright__copyright": ["alted 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.\n\nhttp://support.microsoft.com/kb/913485\n\nshare|improve this answer\n\nYour Answer\n\n\u00a0\ndiscard\n\nBy posting your answer, you agree to the privacy policy and terms of service.\n\nNot the answer you're looking for? Browse other questions tagged or ask your own question."]}