Port Forwarding
Most of lateral movement techniques showed require specific ports to be available for an attacker. In real-world networks, these ports may be blocked preventing from reaching SMB, RDP, WinRM or RPC ports.
To get around, we can use port forwarding techniques which consists of using any compromised host as a jump box to pivot to other hosts. Some machines may have different network permissions that host different services depending on what the target is.
SSH Tunneling
SSH used to be a protocol only associated with Linux systems, Windows now ships with the OpenSSH client by default.
Assume we have control over the PC-1 machine and we would like to use it as a pivot to access a port on another machine that we could not directly connect from the outside.
We will start a tunnel from the PC-1 machine, acting as an SSH client, to the Attacker's PC, which will act as an SSH server. The reason to do so is that you'll often find an SSH client on Windows machines, but no SSH server will be available most of the time.
For this we can create a user specifically with /bin/true which means it won't get a normal shell. It just acts as a tunnel for our connection
SSH Remote Port Forwarding
Imagine a firewall policy that blocks outside connections from accessing port 3389. If the attacker has compromised PC-1 and it has access to port 3389, we can pivot using remote port forwarding to make it accessible from PC-1 (SSH Client) to the Attacker's machine (SSH Server).
To forward port 3389 back to our attacker's machine:
One that is running we can go to the attacker's machine and RDP into forwarded port
SSH Local Port Forwarding
Local port forwarding allows us to "pull" a port from an SSH server into the SSH client. In our scenario, this could be used to take any service available in our attacker's machine and make it available through a port on PC-1. That way, any host that can't connect directly to the attacker's PC but can connect to PC-1 will now be able to reach the attacker's services through the pivot host.
Using this type of port forwarding would allow us to run reverse shells from hosts that normally wouldn't be able to connect back to us or simply make any service we want available to machines that have no direct connection to us.
Notice that we use the IP address 127.0.0.1 in the second socket, as from the attacker's PC perspective, that's the host that holds the port 80 to be forwarded.
Since we are opening a new port on PC-1, we might need to add a firewall rule to allow for incoming connections (with dir=in). Administrative privileges are needed for this:
Once your tunnel is set up, any user pointing their browsers to PC-1 at http://IP:80 and see the website published by the attacker's machine.
Port Forwarding With Socat
If SSH is not available we can use socat to pivot. Though we need to transfer the executable file on the host to make it work, making it more detectable than SSH.
To access port 3389 on the server using PC-1 as a pivot point:
As usual, since a port is being opened on the pivot host, we might need to create a firewall rule to allow any connections to that port:
To expose port 80 from the attacker's machine similar to pulling a port:
Less likely
Detection
More likely
Not needed
Firewall Configurations
Needed to open specific ports
Dynamic Port Forwarding and SOCKS
Allows us to pivot through a host and establish several connections to any IP addresses/ports we want by using a SOCKS proxy.
Since we don't want to rely on an SSH server existing on the Windows machines in our target network, we will normally use the SSH client to establish a reverse dynamic port forwarding with the following command:
In this case, the SSH server will start a SOCKS proxy on port 9050, and forward any connection request through the SSH tunnel, where they are finally proxied by the SSH client.
We can also use any of the tools through the SOCKS proxy by using proxychains. Makes sure the configurations file /etc/proxychains.conf is pointing to any any connection to the same port used by SSH for the SOCKS proxy server
To execute the command through proxychains:
Task 5
Our objective will be to connect via RDP to THMIIS . Initial credentials are given (assume we captured with admin access).
User: jasmine.stanley
Password: G0O6Zd5aM
SSH to the credentials
We need to connect through RDP but we will find that port 3389 has been filtered via firewall and not available directly. Using socat, we will forward the RDP port to make it available on THMJMP2 to connect from our attacker's machine.
Normally, you'd have to add a firewall rule to allow traffic through the listener port, but THMJMP2 has its firewall disabled to make it easier.
Once the listener is active, we log into a user's account through RDP from the attacking machine
Last updated