Route a selected internal subnet through Ligolo-ng

Needs: Compatible proxy/agent, permitted local interface/route management, reachable carrier and selected assigned subnet

On Kali

# On Kali
./proxy -selfcert -laddr 0.0.0.0:LIGOLO_PORT

In the proxy console, obtain the fingerprint

# In the proxy console, obtain the fingerprint
certificate_fingerprint

On the pivot

# On the pivot
./agent -connect LHOST:LIGOLO_PORT -accept-fingerprint CERT_FINGERPRINT

In the Ligolo console

# In the Ligolo console
interface_create --name ligolo
session
ifconfig
interface_add_route --name ligolo --route INTERNAL_SUBNET
tunnel_start --tun ligolo

Manual Linux alternative

# Manual Linux alternative
sudo ip tuntap add user "$USER" mode tun ligolo
sudo ip link set ligolo up
sudo ip route add INTERNAL_SUBNET dev ligolo

# Then use normal clients
ip route get INTERNAL_HOST
nmap -sT -Pn -n -p PORTS INTERNAL_HOST
curl -v http://INTERNAL_HOST:PORT/

# Add one narrow route
sudo ip route add 240.0.0.1/32 dev ligolo
nmap -sT -Pn -n -p PORTS 240.0.0.1

Use this only when the desired service is bound to 127.0.0.1 on the agent.

In the selected Ligolo session

# In the selected Ligolo session
listener_add --addr 0.0.0.0:PIVOT_PORT --to 127.0.0.1:KALI_PORT --tcp
listener_list

Kali listener

# Kali listener
ncat -lvn 127.0.0.1 KALI_PORT

Cleanup

# Cleanup
listener_stop LISTENER_ID

Verify → Verify route/interface ownership, destination application and each necessary reverse listener.

If it fails → Overlapping routes, wrong session/interface or absent privilege can create a misleading connected agent without a working path. More detail ↓

If → then

A credential appears valid but the destination's usable access is unknown → Match route, destination service and effective authorization
Needs: Real source-to-service route, correct identity context and protocol-specific execution/logon rights
An IP connection works while hostname/Kerberos access fails → Preserve DNS, Kerberos names and time across a pivot
Needs: Reachable correct resolver/KDC path, matching target SPN/hostname, realm configuration and acceptable time
A pivoted exploit reaches its target but its shell/download cannot return → Build the callback and delivery routes separately from the attack route
Needs: Target-to-listener/download-server path, correct advertised address and compatible reverse listener/forward

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Route a selected internal subnet through Ligolo-ng

USE WHEN: Several protocols/subnets require a route-style interface through an agent
STARTING ACCESS: A pivot identity/process or reachable SSH service and a drawn source-to-destination path
RESULT: A verified routed connection path including supported loopback/listener features

Recognize the clue

Use the pivot's route/interface evidence and the intended application's transport needs to decide whether a routed interface is appropriate.

ip route
ip link
./proxy -h

SYNTHETIC EXAMPLE OUTPUT

Existing routes: SELECTED_SUBNET absent
Required client: unsuitable for current SOCKS path
Local interface/route permissions: inspect

Means: A selected internal network and proxy-incompatible client suggest a route-style agent, subject to its own transport behavior.

Confirm: Verify compatible proxy/agent, local privileges, carrier, selected route/interface, DNS and any separate reverse listener.

After validation: The routed application test works on the selected subnet: choose the agent route.
Ruled out in this context: A conflicting/unmodifiable route prevents this design: reject it or select an approved alternate subnet mapping.
Still inconclusive: Agent connection alone does not prove interface, route or destination reachability.

Troubleshooting: Overlapping routes, wrong session/interface or absent privilege can create a misleading connected agent without a working path.

10.1 Proxy and agent

On Kali:

In the proxy console, obtain the fingerprint:

On the pivot:

-ignore-cert is a controlled-lab/debug fallback, not the baseline.

10.2 Current managed interface and route

In the Ligolo console:

Manual Linux alternative:

Then use normal clients:

Ligolo translates connections through a userland network stack. Ordinary TCP clients generally work without ProxyChains, but raw-packet assumptions, ICMP details and some UDP behavior can differ from direct access. Use connect-based validation first.

10.3 Pivot loopback services

Ligolo maps its special 240.0.0.0/4 range to the selected agent's loopback. Add one narrow route:

Use this only when the desired service is bound to 127.0.0.1 on the agent.

10.4 Callback or file-server listener on the agent

In the selected Ligolo session:

Kali listener:

An internal target connects to PIVOT_REACHABLE_IP:PIVOT_PORT; Ligolo relays it to Kali's loopback listener. Cleanup:

Why it works

A TUN-style interface lets applications use a route rather than per-tool SOCKS settings. Agent loopback aliases and reverse listeners solve different destination/callback problems and require their documented configuration.

Worked example · hypothetical

Observation: SOCKS transport limits block the intended client. Test: create the documented selected route and validate one destination service. Illustrative output: the service is reachable through the interface. Interpretation: verify name resolution and any callback listener independently.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗