So we’ve figured out our logon types and have an unexpected but surprisingly loving relationship with the humble network logon. We are also appropriately wary of the untrusted workstation.
But relationships are hard, and your eyes and hands wander, and before you know it you’re back up to your old tricks, using interactive sessions like it’s no big deal and generally being a one-man (or woman) APT-enabler.
What sort of trouble can your dalliances get you into?
Cached Credential Theft
By default, any interactive logon to a domain-joined computer will generate a cached credential on the host. This allows the user to log on even if the domain controller is unavailable.
In an environment with reliable wired connections, this is likely unnecessary, but this functionality is critical for road warriors. Cached credentials are enabled by default.
The cached credentials are stored in one of two formats. Windows XP and earlier use MS-CACHE v1, while Vista and beyond use MS-CACHE v2.
MS-CACHE v1 = MD4(MD4(Unicode(Password))) + Unicode(ToLower(username))) MS-CACHE v2 = PBKDF2(HMAC-SHA1, 10240, MSCachev1, username)
In the MS-CACHE v2 formula, the
10240 represents the iteration count of the PBKDF2 algorithm. This makes it very computationally expensive to generate the hash. On identical hardware, the hash computations/second for MS-CACHE v1 can be measured in tens of millions, MS-CACHE v2 in the hundreds, as in 10^2. Cached credential theft is not a good thing, but it could get a lot worse.
Like cleartext credential theft, for example.
Cleartext Credential Theft
When Windows XP xploded (ha! hahaha!) on the scene circa 2001, it brought with it
WDigest.dll, the charming and harmless Windows implementation of a digest authentication protocol for use with HTTP for single signon-y things.
The details of WDigest aren’t super important to what we’re talking about here, but just know that it existed to make life a bit easier and a bit more secure for Windows users accessing web content. Think SSO combined with challenge/response mechanism similar to NTLM and you’re barking up the right tree.
All good so far.
WDigest requires the user’s cleartext credentials, not the LM or NT hash, to perform its SSO functionality, which
lsass.exe would then store, since that’s what it does.
So, since about 2001, and especially since the release of tools such as Mimikatz and Windows Credential Editor (WCE), a user with administrator privileges on a system can retrieve the credentials for pretty much any user with an active interactive/service/batch session.
What’s the big deal? Administrators can do all the things. That’s what they do! Admin things! And if you’re already an administrator, what more could you want?
The big deal is that the administrator may just be administrator of the local system, while the sessions on the system could have domain-wide privileges.
Say, because they’re Domain Admins.
Hostname: WS01.null.local / S-1-5-21-1356770036-3235504158-1924197432 .#####. mimikatz 2.1 (x64) built on Mar 31 2016 16:45:32 .## ^ ##. "A La Vie, A L'Amour" ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` ( [email protected] ) '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 18 modules * * */ mimikatz(powershell) # sekurlsa::logonpasswords Authentication Id : 0 ; 304121 (00000000:0004a3f9) Session : Interactive from 1 User Name : Administrator Domain : NULL Logon Server : DC01 Logon Time : 10/12/2016 9:00:57 PM SID : S-1-5-21-1356770036-3235504158-1924197432-1107 msv :  Primary * Username : Administrator * Domain : NULL * LM : 921988ba001dc8e14a3b108f3fa6cb6d * NTLM : e19ccf75ee54e06b06a5907af13cef42 * SHA1 : 9131834cf4378828626b1beccaa5dea2c46f9b63 tspkg : * Username : Administrator * Domain : NULL * Password : [email protected] wdigest : * Username : Administrator * Domain : NULL * Password : [email protected] kerberos : * Username : Administrator * Domain : NULL.LOCAL * Password : [email protected] ssp : credman :
This is about as bad as it gets from a I-effed-up-and-logged-onto-the-wrong-box-the-wrong-way perspective. For all intents and purposes, an attacker with your credentials is pretty much you. A notable exception to this is two-factor authentication, but even this has its limitations.
Luckily, Microsoft fixed this in Windows 2012 R2 and 8.1, and then backported the fix with KB2871997 in May of 2014. Unluckily for the 95% of Windows users who just install the damn patches without reading the damn patch notes, the fix wasn’t fully enabled by default. The path will prevent every SSP in LSASS with the exception of WDigest from storing cleartext credentials.
To prevent WDigest from storing cleartext, you need to set the following registry key:
Key: HKLM\System\CurrentControlSet\Control\SecurityProviders\WDigest Setting: UseLogonCredential Value: 0
And there you go. If the patch is already installed, it should start working immediately for all new logon sessions, but I’ve found that some sessions kinda linger, so a reboot may not be a bad idea.
And there we go. Credential theft problem: solved!
Welll… there’s still the tokens.
- Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain)
- Cracking MS CACHE v2 hashes using GPU
- MSCash Hash Primer for Pentesters
- MSCash2 Algorithm
- Protecting Privileged Domain Accounts: Safeguarding Password Hashes
- Protecting Windows Networks - Dealing with credential theft
- What is Digest Authentication?
- Windows LSA Secrets