smallsec
about | contact

Credential Theft

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.

1
2

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

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` ( benjamin@gentilkiwi.com )
 '## 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 :
   [00000003] Primary
   * Username : Administrator
   * Domain   : NULL
   * LM       : 921988ba001dc8e14a3b108f3fa6cb6d
   * NTLM     : e19ccf75ee54e06b06a5907af13cef42
   * SHA1     : 9131834cf4378828626b1beccaa5dea2c46f9b63
  tspkg :
   * Username : Administrator
   * Domain   : NULL
   * Password : P@ssw0rd
  wdigest :
   * Username : Administrator
   * Domain   : NULL
   * Password : P@ssw0rd
  kerberos :
   * Username : Administrator
   * Domain   : NULL.LOCAL
   * Password : P@ssw0rd
  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:

1
2
3

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.

Resources

<<
>>