If you’ve tried pivoting nmap through an SSH jump host, you’ve probably hit one of two outcomes: every port comes back as filtered<\/strong>, or every port comes back as open<\/strong>. Both are wrong and in this post I will show you how I got to a satisifying result. (Spoiler: Using ligolo-ng)<\/p>\n\n\n\n Scenario: You’ve got an attack host, a pivot you can SSH into, and a target on an internal subnet that’s only reachable from the pivot:<\/p>\n\n\n\n The target lives on The textbook answer (or rather the one I learned in HTB Academy) Open a SOCKS proxy with SSH, point proxychains at it, run nmap.<\/p>\n\n\n\n nmap result:<\/p>\n\n\n\n Checking with netcat I figured, the tunnel is fine, but the combination of the SOCKS proxy and Nmap is the problem.<\/p>\n\n\n\n Three things compound. First, proxychains forces nmap’s non-blocking sockets into blocking mode. Nmap’s whole scan engine is built around firing off I have tried What really made me wonder: Even Nmap’s own sshuttle uses iptables rules to redirect outbound TCP into a local Python process that forwards over SSH.<\/p>\n\n\n\n What you get: all 1000 default ports open. The first time I saw that I thought I’d found a goldmine :’D<\/p>\n\n\n\n sshuttle’s iptables You can skip the proxy problem entirely:<\/p>\n\n\n\n Accurate, fast, done \u2014 if nmap is on the pivot. On real engagements and most CTF labs, it isn’t, and uploading a static binary adds operational noise you might not want. Worth knowing about, though.<\/p>\n\n\n\nAttack Host (10.10.14.12) --> Pivot (10.129.229.129) --> Target (172.16.5.35)\n<\/code><\/pre>\n\n\n\n172.16.5.0\/24<\/code>. You want to scan it from your attack host and get real results.<\/p>\n\n\n\nFailed approach 1: SSH dynamic forward + proxychains<\/h2>\n\n\n\n
> ssh -D 9050 -i ~\/.ssh\/id_rsa user@pivot-host\n\n> proxychains nmap -sT -Pn -n 172.16.5.35\n<\/code><\/pre>\n\n\n\nPORT STATE SERVICE\n22\/tcp filtered ssh\n135\/tcp filtered msrpc\n445\/tcp filtered microsoft-ds\n3389\/tcp filtered ms-wbt-server\n<\/code><\/pre>\n\n\n\nWhy does nmap show all ports as filtered through proxychains?<\/h3>\n\n\n\n
connect()<\/code> in non-blocking mode and using select()<\/code>\/poll()<\/code> to track dozens of probes in flight. Proxychains intercepts those calls and makes them blocking, so probes that should return instantly hang instead. Nmap’s reads the hang as “no response” and labels the port filtered.<\/p>\n\n\n\n-n<\/code>, --max-parallelism 1<\/code>, --max-rtt-timeout 5000ms<\/code>, bumping tcp_read_time_out<\/code> to 30000, or swapping socks4<\/code> for socks5<\/code>… none of that fixes it. The socket-level mismatch between nmap and proxychains is just how those two tools interact.<\/p>\n\n\n\n--proxies socks4:\/\/127.0.0.1:9050<\/code> flag has the same problem. Apparent the scan engine was never designed to run through a SOCKS proxy.<\/p>\n\n\n\nFailed approach 2: sshuttle<\/h2>\n\n\n\n
> sudo sshuttle -r user@pivot-host 172.16.5.0\/24 --ssh-cmd \"ssh -i ~\/.ssh\/id_rsa\"\n\n> nmap -sT -Pn -n 172.16.5.35\n<\/code><\/pre>\n\n\n\nWhy does nmap show all ports as open through sshuttle?<\/h3>\n\n\n\n
REDIRECT<\/code> rule funnels every outbound TCP connection into its local listener \u2014 and that listener accepts the connection immediately, before it has any idea whether the real target is reachable. From nmap’s perspective the three-way handshake completes on every port, because it’s completing against the local Python process, not the target. Nmap sees a successful connect()<\/code> and dutifully reports “open.”<\/p>\n\n\n\nApproach 3: just run nmap on the pivot<\/h2>\n\n\n\n
ssh -i ~\/.ssh\/id_rsa user@pivot-host \"nmap -sT -Pn 172.16.5.35\"\n<\/code><\/pre>\n\n\n\nApproach 4: ligolo-ng – the fix<\/h2>\n\n\n\n