Pivoting Inside Active Directory
Different pivoting techniques for lateral movement inside an active directory network
Summary
In this blog, we will take a look at some essential pivoting techniques inside an active directory with a practical demonstration on a Tryhackme room called "Lateral Movement and Pivoting"
In today's infrastructure, there is a high possibility that the network inside the enterprise is separated by different range networks making lateral movement tough for hackers.
But Adversaries and threat actors pivot to move around networks that are usually behind a firewall, having a different subnet.
In this blog, we will study different pivoting techniques with practical examples like -
SSH Remote Port Forwarding
SSH Local Port Forwarding
Port Forwarding with Socat
Dynamic Port Forwarding with SOCKS
Tunnelling Complex Exploits
Network Overview
Below is the network map for the AD Environment
Domain Controller -> 10.200.51.101 - THMDC
THMIIS -> 10.200.51.201
Distributor -> Only be used for fetching credentials
THMJMP -> 10.200.51.249 - Entry point machine
There are probably internal services running inside various machines
During practical scenarios, we will act as an Adversary, which has already gained an initial foothold in one of the machines via a valid set of credentials. Our goal is to pivot, access the internal services, compromise the Domain controller and run complex exploits with tunnelling.
Also before we begin, it is a good practice to create a separate user in our attacker Linux machine. The reason for that is to prevent any other useful user or root user to get shell access on the target machine. That will increase the chances of detection and might compromise our credentials.
With that in mind let's get started.
SSH Tunnelling
SSH Tunnelling can be used in different ways to forward ports through an SSH connection, which we'll use depending on the situation. To explain each case, let's assume a scenario where we've gained control over the PC-1 machine (it doesn't need to be administrator access) and would like to use it as a pivot to access a port on another machine to which we can't directly connect. 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.
SSH Remote Port Forwarding
In our example, let's assume that firewall policies block the attacker's machine from directly accessing port 3389 on the server. If the attacker has previously compromised PC-1 and, in turn, PC-1 has access to port 3389 of the server, it can be used to pivot to port 3389 using remote port forwarding from PC-1. Remote port forwarding allows you to take a reachable port from the SSH client (in this case, PC-1) and project it into a remote SSH server (the attacker's machine).
As a result, a port will be opened in the attacker's machine that can be used to connect back to port 3389 in the server through the SSH tunnel. PC-1 will, in turn, proxy the connection so that the server will see all the traffic as if it was coming from PC-1.
You might ask, what is the point of port forwarding if we have compromised PC-1 and can run an RDP session directly from there? The answer is simple: in a situation where we only have console access to PC-1, we won't be able to use any RDP client as we don't have a GUI. By making the port available to your attacker's machine, you can use a Linux RDP client to connect. Similar situations arise when you want to run an exploit against a port that can't be reached directly, as your exploit may require a specific scripting language that may not always be available at machines you compromise along the way.
Practical Demonstration
Attacker machine - Our Linux machine -> 10.50.49.125
Pivot machine - THMJMP1 -> 10.200.5.249
Target machine - THMIIS.za.tryhackme.com
-> 10.200.51.201
Get a set of valid credentials from the link below
After getting the credentials. access the THMJMP2 using ssh -> Username: jasmine.stanley Password: G0O6Zd5aM
Now use the SSH utility for remote port forwarding
The above command will establish an SSH session from THMPJMP1 to the attacker machine(10.50.49.125) using the chrollo17 user. Since the chrollo17 user isn't allowed to run a shell on the Attacker PC, we need to run the ssh command with the -N switch to prevent the client from requesting one or the connection will exit immediately. The -R switch is used to request a remote port forward, and the syntax requires us first to indicate the port we will be opening at the SSH server (3389), followed by a colon and then the IP and port of the socket we'll be forwarding (10.200.51.201:3389). Notice that the port numbers don't need to match, although they do in this example to avoid complexity
The command itself won't output anything, but the tunnel will depend on the command to be running. Whenever we want, we can close the tunnel by pressing CTRL+C as with any other command.
Now that our tunnel is established, we can go to the attacker's machine and RDP into the forwarded port to reach the server. For this, we will use the xfreerdp tool
As we can see, we now have access to the internal RDP 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.
The practical scenario will be the same as the previous example with slight changes. The command will be
The -L switch is for local port forwarding. 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 our THMJMP1 machine we might need to a firewall rule to allow for incoming connections, administrative privileges are needed for this.
Port Forwarding through Socat
In situations where SSH is not available, socat can be used to perform similar functionality. While not as flexible as SSH, socat allows you to forward ports in a much simpler way. One of the disadvantages of using socat is that we need to transfer it to the pivot host (PC-1 in our current example), making it more detectable than SSH, but it might be worth a try where no other option is available.
The basic syntax to perform port forwarding using socat is much simpler. If we wanted to open port 1234 on a host and forward any connection we receive there to port 4321 on host 1.1.1.1, you would have the following command
The fork option allows socat to fork a new process for each connection received, making it possible to handle multiple connections without closing. If you don't include it, socat will close when the first connection made is finished.
Coming back to our example, if we wanted to access port 3389 on the server using PC-1 as a pivot as we did with SSH remote port forwarding, we could use the following command
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
If, on the other hand, we'd like to expose port 80 from the attacker's machine so that it is reachable by the server, we only need to adjust the command a bit
As a result, PC-1 will spawn port 80 and listen for connections to be forwarded to port 80 on the attacker's machine
Practical Demonstration
For the practical demonstration, we will look at the same setup from previous examples
Attacker machine → Is our linux machine
Pivot machine → thmjmp2.za.tryhackme.com - 10.200.51.249
Target machine → thmiis.za.tryhackme.com - 10.200.51.201
To get the credentials set for machine THMJMP2, use the below link
The goal is to access RDP service running on THMIIS -> 10.200.51.201. There is a firewall that blocks us from accessing the RDP port 3389 from the external network. To begin the attack first ssh into THMJMP2 with the credentials -> Username: jasmine.stanley Password: G0O6Zd5aM
Now we will use the socat tool to access port 3389.
This will open port 1337 on THMJMP2. Make sure to enable the firewall rule to allow the port for connection.
Now after this. On the attacker, machine utilize the xfreerdp tool to connect to THMJMP2 on port 1337 which will redirect the traffic to the RDP service on THMIIS. Credentials for it are provided in the task
This gave us internal access to the RDP service running on THMIIS. You can now get the flag.
Dynamic Port Forwarding And SOCKS
While single port forwarding works quite well for tasks that require access to specific sockets, there are times when we might need to run scans against many ports of a host, or even many ports across many machines, all through a pivot host. In those cases, dynamic port forwarding allows us to pivot through a host and establish several connections to any IP addresses/ports we want by using a SOCKS proxy.
To understand this properly, let's take a look at a practical demonstration.
Practical Demonstration
Attacker machine - Our linux machine - 10.50.49.125
Pivot machine - THMJMP2 - 10.200.5.249
Target - pxeboot.za.tryhackme.com
The goal is to access the pxeboot website. For this we need to configure SOCK4 proxy on port 1337 in the file /etc/proxychains4.conf
After this access the THMJMP2 with the credentials we got from previous examples
Now we will start a reverse dynamic port forwarding
After this, we will be able to access the target's website
In the above command, we utilized proxychains to access resources in the target's machine. You can now run any commands using it to interact with the target.
Tunnelling Complex Exploits
Now after looking at various examples of port forwarding, we will take a look at how an adversary utilizes complex exploits to compromise targets behind a subnet.
Attacker machine → Our linux machine(10.50.49.125)
Pivot machine → THMJMP1 - 10.200.51.249
Target Machine → THMDC - 10.200.51.101
The THMDC server is running a vulnerable version of Rejetto HFS. The problem we face is that firewall rules restrict access to the vulnerable port so that it can only be viewed from THMJMP2.
Furthermore, outbound connections from THMDC are only allowed to machines in its local network, making it impossible to receive a reverse shell directly to our attacker's machine.
To make things worse, the Rejetto HFS exploit requires the attacker to host an HTTP server to trigger the final payload, but since no outbound connections are allowed to the attacker's machine, we would need to find a way to host a web server in one of the other machines in the same network, which is not at all convenient. We can use port forwarding to overcome all of these problems.
First, let's take a look at how the exploit works. First, it will connect to the HFS port (RPORT in Metasploit) to trigger a second connection. This second connection will be made against the attacker's machine on SRVPORT, where a web server will deliver the final payload. Finally, the attacker's payload will execute and send back a reverse shell to the attacker on LPORT
With this in mind, we could use SSH to forward some ports from the attacker's machine to THMJMP2 (SRVPORT for the web server and LPORT to receive the reverse shell) and pivot through THMJMP2 to reach RPORT on THMDC. We would need to do three port forwards in both directions so that all the exploit's interactions can be proxied through THMJMP2
Rejetto HFS will be listening on port 80 on THMDC, so we need to tunnel that port back to our attacker's machine through THMJMP2 using remote port forwarding. Since the attackbox has port 80 occupied with another service, we will need to link port 80 on THMDC with some port not currently in use by the attackbox. Let's use port 8888. When running ssh in THMJMP2 to forward this port, we would have to add -R 8888:thmdc.za.tryhackme.com:80 to our command.
For SRVPORT and LPORT, let's choose two random ports at will. For demonstrative purposes, we'll set SRVPORT=6666
and LPORT=7777
, but be sure to use different ports as the lab is shared with other students, so if two of you choose the same ports, when trying to forward them, you'll get an error stating that such port is already in use on THMJMP2.
To forward such ports from our attacker machine to THMJMP2, we will use local port forwarding by adding -L *:6666:127.0.0.1:6666
and -L *:7777:127.0.0.1:7777
to our ssh command. This will bind both ports on THMJMP2 and tunnel any connection back to our attacker machine.
Putting the whole command together, we would end up with the following.
I've used port 1234 for SRVPORT and 4321 for LPORT. Make sure you setup ssh configs in the attacker machine to make this magic work
Once all port forwards are in place, we can start Metasploit and configure the exploit so that the required ports match the ones we have forwarded through THMJMP2.
Here is the detailed explanation for the above commands
The LHOST parameter usually serves two purposes: it is used as the IP where a listener is bound on the attacker's machine to receive a reverse shell; it is also embedded on the payload so that the victim knows where to connect back when the exploit is triggered.
In our specific scenario, since THMDC won't be able to reach us, we need to force the payload to connect back to THMJMP2, but we need the listener to bind to the attacker's machine on 127.0.0.1. To this end, Metasploit provides an optional parameter ReverseListenerBindAddress, which can be used to specify the listener's bind address on the attacker's machine separately from the address where the payload will connect back.
In our example, we want the reverse shell listener to be bound to 127.0.0.1 on the attacker's machine and the payload to connect back to THMJMP2 (as it will be forwarded to the attacker machine through the SSH tunnel).
Our exploit must also run a web server to host and send the final payload back to the victim server. We use SRVHOST to indicate the listening address, which in this case is 127.0.0.1, so that the attacker machine binds the webserver to localhost. While this might be counterintuitive, as no external host would be able to point to the attacker's machine localhost, the SSH tunnel will take care of forwarding any connection received on THMJMP2 at SRVPORT back to the attacker's machine.
The RHOSTS is set to point to 127.0.0.1 as the SSH tunnel will forward the requests to THMDC through the SSH tunnel established with THMJMP2. RPORT is set to 8888, as any connection sent to that port on the attacker machine will be forwarded to port 80 on THMDC.
This was complicated as it should be🤯. However, after waiting for some time we can see that our port forwarding magic worked and gave us a shell on THMDC
This is how Adversaries compromise the internal machines in a hidden submit with possible exploits.
Conclusion
For me, even after understanding how each port forwarding technique works in detail. In the end, I tend to forget and had to look up notes for reference. Techniques like this are complicated and must be planned carefully.
Last updated