New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pwdump on Windows 10 after password change with anniversary update installed #2
Comments
According to Passcape, Windows 10 anniversary update uses new SAM encryption. Hashes are stored differently too. That's why PWDUMP seems always returns an empty hash. |
I've found out that much on my own but thank you for the link. The issue is also impossible to google for because any 'windows' and 'anniversary' results are full of irrelevant info. The problem is in two lines at each of: The new method doesn't put 20 in that spot so the default empty string hashes are printed instead. The two last fields are not the last login date too, since I kept one account with unchanged password and its V field stayed the same. Any ideas would be appreciated. |
Thanks for all the info and the research you already did! Sadly I haven't had time to revisit this tool for a while and haven't tested the way the latest Windows 10 updates handle cached password hashes. I'm marking this as an enhancement, and I'll try to get around to seeing what needs to be done to support the newest version of Windows. In the meantime, if you find any more information in your searches, please let me know! |
This open source tool has support for the new scheme (it's AES encrypted) but it's written in C, a little hard to read and uses Win API a lot: https://github.com/gentilkiwi/mimikatz I looked at the code a while back to get the hash extracting code out of it but got stuck at one of the Win API functions, something with crypto that 'imports the key into the context' I think. I can dig binary blobs out of the registry in Python but I have no idea what 'importing a key' means according to MSDN. |
The relevant commit is 823d376d8044e112acd1e03225a5eba0e97d0397 (previous one is abaa6ca9b1c4bd76d75a5bdfef8b35cbe82603ce if you want to diff). This tweet seems to indicate that main changes are getSamKey and getHash: https://twitter.com/gentilkiwi/status/762465220132384770 What he calls sam key from the F binary in sam is called hbootkey (and what he calls sys key is called boot key) in creddump7. In getHash there is also a new switch for decoding the hash via kull_m_crypto_genericAES128Decrypt again instead of the old method. Another resource describing this stuff that I used a little but not too extensively was this, it of course doesn't describe the new format: http://www.beginningtoseethelight.org/ntsecurity/index.htm |
In case someone wants to work with new SAM and SYSTEM hives on Linux. I tested mimikatz and it works, extracts the hashes, even on wine (on Fedora 24). The problem is, it doesn't support redirection of input from easily since it's an interactive windows command line program so it'd be hard to use in a script (which is my use case, I harvest SAM and SYSTEM from many images of entire NTFS filesystems and give the extracted hashes to john to see if someone forgot a password or set it to qwerty). I'll ask about this feature in mimikatz but first I'll see if there isn't anything like that in there already to not bother the author needlessly, really all that'd be needed is reading from file and outputting to file instead of the terminal and the rest (including generating the commands, harvesting it's result from mimikatz output, making a john hash file, getting SAM and SYSTEM) can be handled outside wine. In case you are on Linux and want to do this, this might be your workaround for the meantime. Downside being the need for wine and the problem with input. If I find anything more either about fixing creddump or a possible outside of windows workarounds for this use case I'll add it here too. Edit (6 XII 2016): Turns out you can pass mimikatz commands at the command line so passing lsadump::sam + right sam and system paths after /sam: and /system windows style args (all as one string) and then 'exit' will make it dump everything to screen, then it's easy enough to parse that into normal format. This is still a crutch but it's here in case you need it. |
There is still a bug when using creddump7 with SAM/SYSTEM hives from Windows systems that where installed with RC4 and then later on updated to AES encryption. In other words: combination of revision 2 (oldstyle) hbootkey and revision 2 (newstyle) salted user hashes. |
pwdump7.1 hashes are not correct for me in windows 7 or windows 10. |
still does not work for win 10. |
What versions of Win10 do you have? (run winver.exe to see) |
@tijldeneut sorry for being afk. |
No problem, my question: does Mimikatz work or not? Try this: open cmd (as administrator) and type "net user test test /add", this will add a user "test" with password "test". Then run mimikatz/creddump/… whatever and get the hash. To be sure: go to e.g. crackstation.net and crack the hash or to tobtu.com/lmntlm.php to generate them there and verify that the hash is indeed for "test" (0CB6948805F797BF2A82807973B89537). |
When using pwdump on SAM and SYSTEM files from Windows 10 from anniversary the local password is always 31d6cfe0d16ae931b73c59d7e0c089c0 which john cracks to '' (empty string).
This has started happening recently and I suspect it's only applicable to password that were changed AFTER anniversary update, because it's not happening on all, but only on some of anniversary machines.
It also happened on a clean win 10 anniversary install, despite setting a password when creating an account it shown hash of an empty string.
The text was updated successfully, but these errors were encountered: