This past weekend I ended up coming into the SpiderLabs office and “nerded out” with my good friend Ryan Reynolds to follow-up on the research we released at DEFCON and BlackHat this year. As some of you may already know, our research was focused on corruption of LM and NTLM password hashes when they were extracted from the Windows registry (specifically, the SAM) by many tools.
In the process of going through one our test cases on a Windows 8 machine on Saturday, we stumbled across a new key (“UserPasswordHint”) that we had not seen before in the SAM database. To both of us, this seemed like a rather odd, but intriguing key that would be cool to explore a bit more “at some point”.
Well… being the impatient weirdo that I am, I could not wait and dove in headfirst as soon as I got home that night. This blog post will cover some of the details on how to extract/decode User Password Hints from the Windows registry and how I extended Metasploit’s Hashdump tools to incorporate this information.
Inside the Registry Data
For starters, the “UserPasswordHint” key on Windows 8 (and Windows 7) is stored in the following location:
HKLM\SAM\SAM\Domains\Account\Users\<userkey>\UserPasswordHint
If you’re running with SYSTEM access (you can use your imagination here), you can read this key easily by doing a reg query like so:
In first looking at the storage location here, I was a little disappointed thinking that the hint was encrypted in some way until I noticed the pattern of zeros. Having dealt with a fair amount of PHP malware in the last couple months, one of things the “baddies” do is chunk up their payload data into individual characters and then encode them in their ASCII numerical representation. Well in looking at this registry value, it seemed to follow a similar approach, so I wrote a little decoder in Ruby to see if I could learn this users password hint.
Here is the decode method I whipped up to do this:
Now you can use the value stored for this user and translate it back to the clear-text hint, like so:
Although this stuff looked a bit unreadable on the surface we can now see that it can clearly be decoded and could be used by tools that extract information from the SAM. This seems like it would be very helpful for penetration testers by giving them more insight into what the user’s password might be, so I decided to take it one step further.
Extending Metasploit's Hashdump Tools
In our recent hash corruption research, we ended up making a number of changes to the Metasploit Hashdump tools (hashdump.rb and smart_hashdump.rb) and became very familiar with how they work. As such, it just made sense to try integrating user password hint decoding with these tools so I sent a GitHub pull request on Sunday night to the Metasploit team to add this functionality.
Here is a preview of what these new additions will give users when dump hashes from a Meterpreter session:
As of yesterday, these password hint extraction features were merged into the Metasploit Project. I would like to extend a special thanks to @_sinn3r and @TheLightCosine for their ideas, de-turding and review of my code. Also, props to @_sinn3r for pointing out that Window XP also stores user password hints in another location in the registry in the decoded form (this was also included in the recent Metasploit improvements).
Parting Thoughts
I had a lot of fun with this little detour through the Windows Registry for a couple hours. If you use these tools and these new fangled hints help you out in some way, I would love to hear your story.
That is all for now. I hope to have more Windows Registry hijinks and other “hax” to talk about here in the near future, so please stay tuned.

Definitely it is well informative and impressive tool.I got beautiful idea to save the password and arranging it in a proper way.Because most of have used online service for exchanging data and share plan,ATM, e-banking.As result the importance of the password is too high.
Posted by: RobortWoods | 03 September 2012 at 02:47
Ahinson - Yeah, thanks for point of clarification on the encoding and why it's different. The blog post articulates the process I followed to get strings from the UTF16 content in my crude testing, which can be improved upon.
JayJay - Nice, like I said, "can be improved upon". Thanks!
Wanderer - Yeah, I had only done this testing on XP and Win8 before and had rarely set a hint for the user I was testing with. So the that key in the SAM was new to me as I noted above. Also, I had not seen that tool for erasing the hint before, I'll check that out. Thanks!
Terry - The focus here was grab this information automatically as a remote attacker in the post-exploitation phase. To me (to use your own words) it would seem like "watching someone walk all the way around the block just to go to their next door neighbors house" if they spent the time to copy and paste this out of the registry user by user then mapped that back to the user in the Names hive. But anyways, thanks for your comments.
Posted by: claudijd | 24 August 2012 at 08:52
irb(main):001:0> ['6D006F006E006B006500790020006500610074002E002E002E00'].pack('H*').unpack('v*').pack('C*')
=> "monkey eat..."
Posted by: JayJay | 24 August 2012 at 08:49
Are you serious?
You can open the SAM file in any damn Registry Viewer and see the password hint. The binary data will be viewed as Hex and ASCII.
Reading this article was like watching someone walk all the way around the block just to go to their next door neighbors house.
Posted by: Terry Olson | 24 August 2012 at 08:19
>>> we stumbled across a new key that we had not seen before
Kidding guys? The key was here since Windows Vista. Here's the program that diplays and removes Windows hints:
http://passcape.com/delete_password_hints
Posted by: wanderer | 23 August 2012 at 23:35
>>It's not ASCII, it's UTF-16, and I don't know Ruby but surely there's a simpler way of displaying a Unicode string?
The UTF encoding wasn't the problem, it was the conversion from binary to hex. Each byte in the byte array was converted to Hex then to its character equivalent.
The result is the hint string.
Posted by: Ahinson | 23 August 2012 at 08:58
Janmoesen - I don't necessarily think this information needs to be encrypted. You are correct in that anyone who has physical access can guess a username and obtain the associated hint on a one by one basis. The focus of my additions were to obtain this information remotely as part of a post-exploitation process and steal all the hints on the system.
Woody - Thanks for the link, I'll check that out.
Franklinheath - Thanks, a couple others have brought that up too on the pull request after it was merged. I'll probably submit another pull request to tighten that code up in Metasploit when I get a chance.
Unixtippse - Nice find, perhaps someone could extend the Mac OSX hashdump modules to grab those hints too.
Posted by: claudijd | 23 August 2012 at 08:12
Out of interest: what encryption would you suggest for something which is publicly accessible? The password hints can be seen by anyone trying to log on to the machine, no?
Posted by: Janmoesen | 23 August 2012 at 05:50
Don't know if you saw the article, but there are more goodies stored in Windows 8, clear text. No Registry access required - a full list of the contacts cache is in a fixed location on local storage. http://www.infoworld.com/t/microsoft-windows/windows-8-contacts-cache-exposes-personal-data-192542
Posted by: Woody Leonhard | 23 August 2012 at 05:32
It's not ASCII, it's UTF-16, and I don't know Ruby but surely there's a simpler way of displaying a Unicode string?
Posted by: Franklinheath | 23 August 2012 at 05:07
FYI, listing ALL teh password hints on a MacOS system goes like this:
dscl . -readall /users AuthenticationHint
Posted by: Unixtippse | 23 August 2012 at 04:09