Another scenario that is getting all too familiar:
It is another day in the office. The external penetration test is going as planned. You broke in to the internal network and you have transports in place. You just need that last trophy before you can call it a day! You finally find the system where it is stored. You prep for the attack, and check to make sure all is setup correctly.
- Route set through a meterpeter session that can talk to the internal box
- exploit/multi/handler set up and ready to catch all the shells
- RHOST is correct
- RPORT is correct
- Payload is correct
- LHOST is correct
- LPORT is correct
- DisablePayloadHandler is true
With confidence you launch the exploit and wait, and wait, and nothing. No shell. All the output said the exploit was successful, but nothing. You take a deep breath, and decide to change it up to a bind payload, thinking outbound traffic is being blocked. You get everything set back up, but this time change your payload to bind, so the meterpeter session would just listen and you can just connect to it. You launch your exploit again, it says it successful but no shell. You check to see if the port opened up. Nothing is there, another failed attempted. You notice a new shell drops in. This shell just happens to be a box that you had recently compromised just changing transports, a few minutes later all your shells come back online on a different transport. Some alarm got triggered somewhere. You are still in and they have not flushed you out. A deep breath is taken, routes are flushed and reset back up through one of the shells that just came back online. You drop in to this session and check to see how many jumps it is between you and your target. Two jumps, two simple jumps. After a light check you see that the jump in between is a firewall. Damn, an internal firewall is setup limiting traffic to and from your target. What can we try next? Reverse shell failed, bind failed, and a transport got burned, not good so far.
Lets see what’s going on and find another way we can get around this issue. In modern network engineering this becoming more and more a common practice. An internal firewall is used to segment off part of the network to only trusted traffic. Thus only allowing inbound traffic from specific IPs and outbound traffic to only specific IPs. We can get to our target box because our traffic is routed through our victim. Unfortunately this does not pivot our new reverse shell back out. In a nutshell, when you launch an exploit with this method it is launched through your meterpeter session and then hits your target. Your target processes the payload, and attempts to call back directly to your Metasploit Server (C2 server). A C2 server, Command and Control server, is your computer or server that is hosting your Metasploit instance, where shells call back to.
Port Forwarding
A meterpeter shell has the capability of port forwarding. This can be used to help shape traffic or connect to services normally not reachable on an internal network. The most common use case of port forwarding brings a target port locally to your C2 server through the victims computer. This process sets up a listening port on your C2 server, when connected to it will forward all traffic through the meterpeter session and out the victim’s computer to the destination IP and port you specified. Port forwarding in this method is extremely useful when accessing services such as RDP, file shares, etc. that are only accessible from the victims computer.
Examples on how to set up local port forwarding.
portfwd add -l [local port on C2 to listen on] -p [remote port to connect to] -r [remote ip to connect to]
The example image below shows how the traffic is shaped when connecting to a port on the target system through a local port forward.
With the update to meterpeter’s portforwarding capabilities we can now do reverse port forwarding. This means we can set the listening port on the victim computer, and have our session to forward the traffic to an IP and port of your choosing. This is great as now you can drop a service inside a compromised network. This leads to a whole list of evil things we can do. My favorite thing to do with with this is set my listener inside the target network. By doing this you can set your payloads to point at the victim IP and port to have the traffic relayed out. This reduces the number of connections to your C2 server. With less connections out bound to your server, it is harder to detect.
We choose our victim that we are currently utilizing for routing and set up reverse port forwarding on it. Now all traffic is routed back out to our C2 server through our pivot box. Just remember to change your payload information, the LHOST will now be the victims IP, and the LPORT will be the listening port on the victim. If everything goes as planned, the traffic flow will look something similar to the diagram below with the reverse port forward in place to catch your shells.
Example of reverse port forwarding.
portfwd add -R -l [port to connect to] -p [port on victim to listen on] -L [remote host to connect to]
This is nothing new to have a reverse shell calling back through a compromised host. In the past you set a handler up on a compromised host to catch the shell, it is just not a little known fact. What makes reverse port forwarding more powerful then the previous setup, is you can have a chain of them. A reverse port forwarding chain to shape your traffic all the way out of the compromised network. Or you can set up the reverse port forward to point to a backup C2 server, or your friends. In the end don’t limit yourself to just forwarding in a listener. Think of some edge cases like cloning an internal website, kill it, host your own, forward it in. Enjoy the chaos. Embrace your creativity with this one.
