Ligolo-ng

The Proxychains Tax

The old pivoting tools all end the same way. They give you a SOCKS proxy.

To use it, you prefix every command with proxychains.

It works. It’s also miserable.

• Every tool needs the wrapper, and some won’t cooperate at all
• SOCKS is TCP-focused, so UDP and ping become a pain or flat-out impossible
• It’s slow. An nmap scan that takes 10 seconds direct can take 10 minutes through proxychains

Ligolo-ng throws all of that out.

Instead of a proxy you have to wrap around, it gives your machine a real network interface. The internal network behaves as if it were plugged straight into your laptop.

Your tools don’t even know a pivot exists. They just work, at full speed.

Ligolo-ng makes a remote network directly routable from your attacking machine. No proxychains, no per-tool config. This is why it’s the go-to pivoting tool today.

Two Pieces, One Reverse Connection

Ligolo-ng is two small programs. You only ever run two commands to connect them.

The agent, sitting on the pivot, connects back out to the proxy on your machine.

Remember the last note: outbound gets through the firewall, inbound doesn’t. Ligolo is built around that fact.

Once connected, the proxy creates a TUN interface on your Kali box.

Think of it as a virtual network card named ligolo.

Anything you route into it gets carried through the encrypted tunnel, out of the agent, and onto the internal network.

That’s the whole model:

• the agent is a dumb, unprivileged relay
• the proxy is a virtual network card
• the tunnel between them is one ordinary-looking outbound connection

Everything below is just wiring this up.

Setting It Up

Grab the two binaries from the releases page: the proxy for Kali, and an agent built for the pivot’s OS.

Four steps.

1. Build the interface (once)

On Kali, create the virtual ligolo card and bring it up:

You do this once per session. It’s the card your tunnels live on.

2. Start the proxy

• -selfcert generates a throwaway TLS certificate for you
• the proxy now listens on port 11601 and opens its own console

Downloaded the raw binary instead? Then it’s just ./proxy -selfcert.

3. Run the agent on the pivot

Move the agent onto the compromised host however you move any file. Then point it back at Kali:

• -connect is your Kali IP and the proxy port
• -ignore-cert says don’t fuss over the self-signed cert

Back in the proxy console, a new session appears. That’s your agent phoning home.

4. Start the tunnel, then add the route

Select the agent and start its tunnel:

ligolo-ng » session
? Specify a session : 1 - pivot@target
[Agent : pivot@target] » start

Newer releases rename start to tunnel_start (sometimes tunnel_start --tun ligolo). Same idea.

Now the one line that does the magic. Tell Kali the internal subnet lives on ligolo:

Traffic for 172.16.5.0/24 now flows into ligolo, through the tunnel, out the pivot.

Now Just Use Your Tools

There’s no step five.

Point anything at the internal network and it works, no proxychains in sight:

One rule for scanning through the tunnel:

Use nmap -sT (TCP connect), never the default SYN scan. The agent is unprivileged and ligolo rebuilds connections in software, so raw SYN packets lie to you. Add -Pn to skip host discovery.

Reaching the Pivot’s Own Localhost

Sometimes the best service on the pivot is bound to 127.0.0.1. Listening only to itself.

An admin panel or database that never faces the network.

Your route to 172.16.5.0/24 won’t touch it. Loopback isn’t on that subnet.

Ligolo reserves one address for exactly this: 240.0.0.1 maps to the agent’s own 127.0.0.1.

Route it:

Now hitting 240.0.0.1 is like hitting localhost on the pivot. That internal-only panel is suddenly in reach.

Getting Things Back: Listeners

Routing lets you reach in. But often you need traffic to come back out.

A reverse shell from a deep host. A tool download onto a machine that can’t see your web server.

The problem: a host buried three subnets deep has no route back to Kali. It can’t connect to you directly.

The fix is a listener. You tell the agent to open a port on the pivot and quietly carry anything that hits it back through the tunnel.

Run it inside the proxy console, on the selected session:

[Agent : pivot@target] » listener_add --addr 0.0.0.0:1234 --to 127.0.0.1:4444 --tcp

• --addr 0.0.0.0:1234 is the port the pivot opens (deep hosts connect here)
• --to 127.0.0.1:4444 is where it lands on your Kali machine

Reverse shell: point the payload at the pivot on 1234, catch it on Kali’s 4444.

The deep host talks to the pivot. The pivot carries the shell home.

File download: flip the ports the same way to let an isolated host pull tools off your Kali web server.

Pivoting from Windows

Nothing changes when the pivot is Windows. You just use the Windows agent.exe:

Same reverse connection. Same session. Same routing on your side.

Upload agent.exe with whatever access you have (an evil-winrm session, an SMB share, a web shell) and run it.

The agent needs no admin rights, so a plain user shell is enough.

One Hop Is Rarely the End

Everything so far gets you one network deeper.

But the real target often sits another hop beyond that, on a subnet only the second machine can see. Reaching it means chaining pivots.

That’s a move of its own, and it gets its own note next: the double pivot.

Clean Up After Yourself

Tunnels, listeners, and routes are noise you leave behind. Tear them down.

Inside the proxy console:

listener_list      # see what you opened
listener_stop       # close a listener

On Kali, drop the routes and interface:

A tidy pivot is a professional pivot. Leftover forwards and firewall holes are exactly the kind of thing that ends up in the findings report, against you.

Practice Boxes

• Wreath - TryHackMe. The classic beginner pivoting network: a few machines, chained hops, built for exactly this workflow.
• Inception - HackTheBox. Layered access that forces you to tunnel to reach the next stage.