Pivoting
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 j0hn@10.11.1.252: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 .
/home/kali/sshuttle-0.78.1
confirm you are connected by ssh into the same account
Scanning / nmap
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:
https://github.com/andrew-d/static-binaries
https://github.com/static-linux/static-binaries-i386
https://github.com/yunchih/static-binaries
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.
nmap -Pn -v -sT -sV -p-
Last updated