Choosing The Dig Site & Starting Our Tunnels
Last updated
Last updated
In the above image, the attack host starts the SSH client and requests the SSH server to allow it to send some TCP data over the ssh socket. The SSH server responds with an acknowledgment, and the SSH client then starts listening on localhost:9050. Whatever data you send here will be broadcasted to the entire network (172.16.5.0/23) over SSH. We can use the below command to perform this dynamic port forwarding.
The -D argument requests the SSH server to enable dynamic port forwarding. Once we have this enabled, we will require a tool that can route any tool's packets over the port 9050
We can do this using the tool proxychains
Proxychains is often used to force an application's TCP traffic to go through hosted proxies like SOCKS4/SOCKS5, TOR, or HTTP/HTTPS proxies.
To inform proxychains that we must use port 9050, we must modify the proxychains configuration file located at /etc/proxychains.conf. We can add socks4 127.0.0.1 9050 to the last line if it is not already there.
Now when you start Nmap with proxychains using the below command, it will route all the packets of Nmap to the local port 9050, where our SSH client is listening, which will forward all the packets over SSH to the 172.16.5.0/23 network.
we can only perform a full TCP connect scan over proxychains. The reason for this is that proxychains cannot understand partial packets. We also need to make sure we are aware of the fact that host-alive checks may not work against Windows targets because the Windows Defender firewall blocks ICMP requests (traditional pings) by default.
We first use the Ubuntu server as host to transfer the malicious files to the Windows machine
on Ubuntu server:
We download the file from the Windows machine:
Then we create a reverse port forward from the port 8080 of the Ubuntu server to our machine's port 8000
After creating the SSH remote port forward, we can execute the payload from the Windows target. If the payload is executed as intended and attempts to connect back to our listener, we can see the logs from the pivot on the pivot host.
On Attacker machine, start msfconsole and:
Our Meterpreter session should list that our incoming connection is from a local host itself (127.0.0.1) since we are receiving the connection over the local SSH socket, which created an outbound connection to the Ubuntu server. Issuing the netstat command can show us that the incoming connection is from the SSH service.
We can create a Meterpreter shell for the Ubuntu server with the below command, which will return a shell on our attack host on port 8080.
Before copying the payload over, we can start a multi/handler, also known as a Generic Payload Handler (as above, different payload).
We can copy the backupjob binary file to the Ubuntu pivot host over SSH and execute it to gain a Meterpreter session.
We need to make sure the Meterpreter session is successfully established upon executing the payload.
So assuming that the firewall on the Windows target is allowing ICMP requests, we would want to perform a ping sweep on this network. We can do that using Meterpreter with the ping_sweep module, which will generate the ICMP traffic from the Ubuntu host to the network 172.16.5.0/23.
Here are two helpful ping sweep for loop one-liners we could use for Linux-based and Windows-based pivot hosts.
It is possible that a ping sweep may not result in successful replies on the first attempt, especially when communicating across networks. This can be caused by the time it takes for a host to build it's arp cache. In these cases, it is good to attempt our ping sweep at least twice to ensure the arp cache gets built.
There could be scenarios when a host's firewall blocks ping (ICMP), and the ping won't get us successful replies.
In these cases, we can perform a TCP scan on the 172.16.5.0/23 network with Nmap. Instead of using SSH for port forwarding, we can also use Metasploit's post-exploitation routing module socks_proxy to configure a local proxy on our attack host.
We will configure the SOCKS proxy for SOCKS version 4a. This SOCKS configuration will start a listener on port 9050 and route all the traffic received via our Meterpreter session.
Confirming Proxy Server is Running
After initiating the SOCKS server, we will configure proxychains to route traffic generated by other tools like Nmap through our pivot on the compromised Ubuntu host.
add the below line at the end of our proxychains.conf file located at /etc/proxychains.conf if it isn't already there. (if there isn't a fiel already, remember to include the [ProxyList] section before this line)
Finally, we need to tell our socks_proxy module to route all the traffic via our Meterpreter session. We can use the post/multi/manage/autoroute module from Metasploit to add routes for the 172.16.5.0 subnet and then route all our proxychains traffic.
OR from meterpreter directly:
After adding the necessary route(s) we can use the -p option to list the active routes to make sure our configuration is applied as expected.
Testing Proxy & Routing Functionality
Port forwarding can also be accomplished using Meterpreter's portfwd module.
We can enable a listener on our attack host and request Meterpreter to forward all the packets received on this port via our Meterpreter session to a remote host on the 172.16.5.0/23 network.
The above command requests the Meterpreter session to start a listener on our attack host's local port (-l) 3300 and forward all the packets to the remote (-r) Windows server 172.16.5.19 on 3389 port (-p) via our Meterpreter session.
Now, if we execute xfreerdp on our localhost:3300, we will be able to create a remote desktop session.
Netstat Output
Similar to local port forwards, Metasploit can also perform reverse port forwarding with the below command, where you might want to listen on a specific port on the compromised server and forward all incoming shells from the Ubuntu server to our attack host.
We will start a listener on a new port on our attack host for Windows and request the Ubuntu server to forward all requests received to the Ubuntu server on port 1234 to our listener on port 8081.
Configuring & Starting multi/handler
Generating the Windows Payload
As above, be mindful that the UbuntuIP used here is the network interface for the windows network segment.
Finally, if we execute our payload on the Windows host, we should be able to receive a shell from Windows pivoted via the Ubuntu server.
