This is the SSH local Port Forwarding simulation. After enumerating the compromised Linux client, we discover that in addition to being connected to the current network (10.11.0.x), it has another network interface that seems to be connected to a different network (192.168.1.x). In this internal subnet, we identify a Windows Server 2016 machine that has network shares available.
how does it work with v0.78.5? sshuttle always stucks on c: connecting to server for me.
Version is 0.78.5 according to --version and i use "sshuttle -v -r @ " python3 sshuttle -r [email protected]:22000-oKexAlgorithms=diffie-hellman-group1-sha1 10.2.2.0/22
[Edit]: I was able to fix the cipher issue by adding to the /etc/ssh/ssh_config KexAlgorithms +diffie-hellman-group1-sha1 Ciphers +aes128-cbcv
This worked. I need to document this .
python3 -m pip install sshuttle==0.78.5
python3 sshuttle -r [email protected]:22000 10.2.2.0/22 (you have to be root for this to work(
confirm you are connected by ssh into the same account
Regardless of what kind of access I have to my beachhead, I’m going to want to scan the new network for host and port discovery. While it is possible to set up tunnels to scan, it’s very difficult to do, and flaky at best. If nmap isn’t already on the beachhead, my preferred method is to bring a copy of nmap that’s statically compiled to beachhead (typically via wget or curl on linux, or smb on windows).
You can compile the source yourself, or there’s a few GitHub repos out there with statically compiled tools for various oses / architectures:
For nmap, if you’re in a very stripped down container, you may get an error Unable to open /etc/services for reading service information. Just grab a copy of that file from your local box, upload it to the beachhead and drop it in /etc. You won’t have access to all the nmap scripts, but you can get feel for what exists.