Recovering Remote Windows Passwords in Plain Text with WCE

I recently talked about recovering Windows passwords remotely in plain text using “Mimikatz”, but it is not the only program that will do it. One of my favorite security teachers, Professor Sam Bowne at City College of San Francisco, has released a tutorial on using the Windows Credentials Editor (WCE) to do the same thing.

I was following the tutorial and ran into a snag. On my backtrack machine my Metasploit Path is different, though we are using the same version of Backtrack (5r2). So the directories that are mentioned did not exist on my machine.

Basically I followed the tutorial step by step, but on my machine I had to do 2 things differently:

  • I needed to copy the wce.rb Ruby script into the “/opt/metasploit/msf3/scripts/meterpreter” directory.
  • Also, the wce-x86.exe (or wce-x64 if using 64 bit) into the “/opt/metasploit/msf3/data/post” directory.

I am not sure of why the paths are different, maybe because I was using the “Live” bootable version of Backtrack 5r2.

The tutorial functioned flawlessly after that. After obtaining a remote session using Backtrack’s Social Engineering Toolkit, I ran bypassuac to get System level authority and at the meterpreter prompt simply ran wce.rb:

Two strange things that I noticed was that the username for “Secure_User” was cut off, but the long complex password for the user was indeed correctly recovered. But the user “Fred” had no password on this test machine, and WCE mirrored the password for the “Secure_User” account.

Odd, but it did recover the password in plain text.

Mimikatz seems to do a better job at recovering passwords, but WCE is just as easy to use. Both offer other features and functions. I think I like both!

*** Update***

Hernan from Amplia Security (creator of WCE) contacted me as soon as I posted this article. As fast as I could run some tests for him, he created a fix for this.

In a test version he sent me, WCE correctly recovered and displayed both users with passwords and those without:

Thanks Hernan, awesome job!  🙂

LM Hash flaw: Windows Passwords Under 15 Characters Easy to Crack

Solid State Drive (SSD) based cracking programs have really been a hot topic over the past few years. They are fast, very fast. I did an article a while back on using SSD based look up tables to crack 14 character Windows passwords in 5 seconds.

The blazing speed is possible because of the characteristics of the LM based password hashes that Windows stores along with the stronger NTLM based hashes. The LM based hashes can be cracked with SSD based tables in about 5 seconds. The NTLM version of the password hash is more secure and can take significant time to crack. The solution then is simple, disable LM password hashing.

Sounds simple doesn’t it? Well, the problem is, it doesn’t work. Even when you tell Windows to not store the less secure LM hash of the password, it still does.

Mike Pilkington posted an exceptional article today on this at the SANS Computer Forensics Blog. In his article, “Protecting Privileged Domain Accounts: LM Hashes — The Good, the Bad, and the Ugly“, Mike shows that even when Windows policy is set to disable LM hashes, the hashes are still created!

The interesting thing is that the lower security hashes are not present on the SAM stored on the hard drive. But when the security accounts are loaded into active RAM, Windows re-creates the LM hashes!

According to Mike’s article, the LM Hash can be pulled from active RAM using the Windows Credential Editor (WCE).

What is the solution then? Make your passwords at least 15 characters! The LM Hash only supports passwords of 14 characters or less, so if your password is over 14 characters, Windows can not create the less secure hash.

Why would Windows do this? Some older programs still use LM based security, so most likely Windows creates it even when you tell it not to for backwards compatibility.

For more information, check out Mike’s article.