Windows VM to Kali VM to SOCKS Proxy to Target Network
It’s always nice to have a Windows VM alongside your Kali VM during engagements. It’s useful for running tools like Bloodhound and PowerView using “runas /netonly” or getting an interactive shell using PowerShell Remoting. But what if you can’t reach your target network from your Windows VM?
Consider the following scenario. You’ve managed to get a meterpreter session against a host that is also connected to your target network. You add a route to this network through your meterpreter session and startup your socks proxy. Now you can use tools like proxychains on Kali to start attacking the target network. Great, but how do we get our Windows VM to use this proxy? Unfortunately, there’s no built-in way to get our Windows VM to use our proxy system-wide.
This will be a quick post covering a couple ways we can allow our Windows Attacking VM to make use of SOCKS proxies running on our Kali VM.
Here’s a diagram that hopefully makes what we’re trying to do a bit more clear.
There are two tools that I found easiest to work with when setting this up.
- Redsocks - Open Source
- ProxyCap - Closed Source/Shareware
I prefer ProxyCap for quick setup and out of the box support for proxy chains. But I also tried Redsocks and found it was pretty straightforward as well, albeit a little more involved setup.
ProxyCap is a Windows tool that allows you to redirect network connections through proxy servers. In other words, anything ran on our system will be proxy-aware. Using ProxyCap is very straightforward and ideal for anything requiring quick setup. You can download a free 30-day trial and try it out for yourself.
ProxyCap configuration is very straighforward. Fire up the configuration interface and add a new proxy, specifying our Kali VM ip as the host and the port the proxy is running on, in this case the default of 1080. Make sure you choose the right proxy type. Next create a new rule specifying that all traffic should be going through that proxy and we’re all set. Anything ran on our Windows VM will now be proxy-aware.
Redsocks is an open-source transparent TCP-to-proxy redirector. The github page to the redsocks project is included here: https://github.com/darkk/redsocks
This essentially allows our kali VM to act as a gateway for our Windows VM. With some iptables rules and redsocks magic, allow traffic from our Windows VM will be redirected to our proxy. Pretty cool stuff and even has a few additional features that I’m not going to be covering, such as handling UDP and DNS. Do note that proxy chain support isn’t directly built in. However, you can implement proxy chaning by running multiple redsocks instances and redirecting traffic from each one to the next. Nevertheless, basic setup using one proxy is relatively straight forward.
Once it is installed, a default configuration file will be available at “/etc/redsocks.conf”. You can specify a configuration file using the -c argument, so I recommend copying the default and not making any edits directly.
The configuration file is fairly straight forward, but the following changes will get you up and running quickly.
log_debug = on; log_info = on; log = "stderr"; daemon = off;
These will simply enable error logging and allow redsocks to run in a console so we can easily our connections working and identify any issues.
"local_ip = 0.0.0.0" "local_port = 12345"
We will allow redsocks to listen on every interface as we’ll be sending traffic from our Windows VM.
"ip = 127.0.0.1;" "port = 1080" "type = socks5"
These settings sep. In this case, we’re just running a SOCKS Proxy with SSH.
The configuration is now ready to go and redsocks can be started using
redsocks -c ourconfig.conf
A few more steps and we’ll be good to go. First enable IP forwarding.
echo 1 > /proc/sys/net/ipv4/ip_forward
Now we’ll need to setup our iptables rules to redirect traffic from our Windows VM to redsocks.
iptables -t nat -A PREROUTING -p tcp -d 172.16.1.0/24 -j REDIRECT --to-ports 12345 iptables -t nat -A OUTPUT -p tcp -d 172.16.1.0/24 -j REDIRECT --to-ports 12345
Finally, we need to add a new route on our Windows VM to specify that our Kali VM should be the gateway for the 172.16.1.0/24 network.
route add 172.16.1.0/24 kali-ip-here
And if all went well, our Windows VM can now reach the 172.16.1.0/24 network :)