Pwdump on Windows 10 after password change with anniversary update installed

[FRex]

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.

[pinsider]

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.

[FRex]

I've found out that much on my own but thank you for the link.
Sadly that tool is not open source and doesn't explain how it does it.

The issue is also impossible to google for because any 'windows' and 'anniversary' results are full of irrelevant info.
Is there a plan to crack this and support it in this tool?

The problem is in two lines at each of:
https://github.com/Neohapsis/creddump7/blob/master/framework/win32/hashdump.py#L200
https://github.com/Neohapsis/creddump7/blob/master/framework/win32/hashdump.py#L228

The new method doesn't put 20 in that spot so the default empty string hashes are printed instead.
Using info on this webpage http://www.beginningtoseethelight.org/ntsecurity/index.htm#D3BC3F5643A17823 I found out that 'only' LM, NT and two last unknown entries change in the V field after a password is changed.

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.
I'm considering asking on some Microsoft website if I can't find the answer to this soon.

[ropnop]

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!

[FRex]

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.

[FRex]

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.
Format of that F binary field changed and it's visible in the diff, there is a switch there for revision in function kuhl_m_lsadump_getSamKey in modules/kuhl_m_lsadump.c . The code then goes to kull_m_crypto_genericAES128Decrypt in modules/kull_m_crypto.c to decrypt the new sam key but then I get stuck since there are many calls to Crypt* functions in the win api. I didn't try to work out exactly how that would all map to AES in Python.

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

[FRex]

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.

[tijldeneut]

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.
Very simpel fix for which I just created a pull request. Great suite btw!

[imrecsoka]

pwdump7.1 hashes are not correct for me in windows 7 or windows 10.

[kolet]

still does not work for win 10.

[tijldeneut]

What versions of Win10 do you have? (run winver.exe to see)
Home/Enterprise/Pro, build, x64.
Was it a proper installation or an update from Win7 or other Win10 versions?
If you're willing to get your hands dirty, this blog might help understand the issue: http://www.insecurity.be/blog/2018/01/21/retrieving-ntlm-hashes-and-what-changed-technical-writeup/
Thanks

[kolet]

@tijldeneut sorry for being afk.
unfortunatly i dont know which ver is that.
i tried mimikatz i tried creddump i wrote the link that u gave ( 2 weeks ago) and used his tool. the hash is the same.

[tijldeneut]

No problem, my question: does Mimikatz work or not?
If Mimikatz doesn't work (disable your AV), then there is something wrong with your deductions and not with this program. Because Mimikatz just uses the Windows API's that Windows itself, uses…

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).