ligolo-ng is a reverse TCP/TLS tunneling tool built on a TUN interface, letting authorized pentesters pivot through compromised footholds without SOCKS proxies or proxychains.
| Tool | nicocha30/ligolo-ng — advanced, simple tunneling/pivoting tool using a TUN interface, written in Go |
| Category | Network tunneling and pivoting framework |
| Primary Use | Establishing high-performance tunnels from reverse TCP/TLS connections during authorized penetration tests, enabling tools like nmap to reach internal networks directly |
| Safe Use | For authorized penetration tests, red team engagements within contracted scope, and lab environments only; not for unauthorized access to third-party systems |
| Telemetry Note | Leaves a reverse TLS connection from agent to relay, TUN interface creation on the operator host, and connect()-style TCP behavior rather than raw packets — all observable to defenders monitoring egress patterns |
ligolo-ng occupies a specific niche in the offensive security toolchain: it replaces the traditional SOCKS-proxy-plus-proxychains pivoting workflow with a genuine layer-3 experience built on a TUN interface. The project, written in Go and licensed under GPL-3.0, describes itself as simple, lightweight and fast, and its architecture backs that claim. Rather than forwarding individual TCP or UDP streams through a userspace proxy that every tool must be configured to use, ligolo-ng presents the tunneled remote network as a locally routable interface, which means standard utilities work unmodified. For authorized pentesters who spend their days chaining footholds into internal network access, this is a meaningful ergonomic and performance improvement over the chisel/Meterpreter route-and-proxy pattern.
The architectural decision that distinguishes ligolo-ng from its predecessors is its use of Gvisor to build a userland network stack. When the operator runs the relay/proxy server, a TUN interface is created locally; packets directed at that interface are translated by the userland stack and forwarded over the multiplexed connection to the remote agent. The README illustrates the mechanism for TCP: an incoming SYN is translated into a connect() call on the agent side, a successful connection generates a SYN-ACK back toward the operator, an ECONNRESET, ECONNABORTED or ECONNREFUSED syscall result produces an RST, and a timeout produces silence. This translation layer is what makes the tunnel feel like real networking to scanning tools while requiring no privileged execution on the target.
That privilege asymmetry is worth pausing on, because it shapes where the tool fits operationally. On the agent side — the component running on the assessed host — no administrative access is required, since everything happens in userspace via syscalls. On the relay/proxy side, the operator needs sufficient privileges to create a TUN interface, which on a typical Linux attack box is unremarkable. The trade-off is documented honestly in the caveats: because the agent is unprivileged, raw packet forwarding is impossible, so an nmap SYN scan is actually executed as a full TCP connect() on the remote end. The README advises using --unprivileged or -PE with nmap to avoid false positives — a small but telling detail that signals the author has actually used the tool against real networks.
Protocol coverage is deliberately scoped: TCP, UDP, and ICMP echo requests. That is enough for the overwhelming majority of post-exploitation enumeration and lateral movement simulation, though it excludes exotic protocols and full raw-packet tricks. Performance claims are backed with an iperf3 benchmark in the README showing sustained throughput around 104–106 Mbits/sec between two 200 Mbits/sec endpoints, with only two retransmissions over ten seconds. For a userland stack tunneled over a reverse TLS connection, that is respectable, and the multiplexing design means a single agent connection carries many concurrent sessions rather than opening a socket per target.
The 0.8 release substantially expanded the project beyond its original single-operator design. It introduces an API and a web interface contributed by Jeremie Bedjai, enabling what the README calls multiplayer operation — multiple operators sharing a relay and selecting agents collaboratively. A configuration file now persists tunneling and proxy settings across sessions, a daemon mode supports running ligolo-ng as a persistent service, and an auto-bind feature can automatically configure tunneling whenever a specific agent connects. Route and interface management is now automatic (an autoroute capability) across Windows, Linux, MacOS and BSD, and operators can remotely terminate an agent. Collectively these features push the tool toward team-scale engagements rather than solo console work.
Connection handling shows attention to real-world network instability. Both reverse and bind connection modes are supported, so the operator can either have the agent dial out to the relay or have the relay connect inward depending on egress filtering. Websocket transport is available for environments where that shape blends in better. The README also highlights automatic tunnel and listener recovery after network issues — valuable when a flaky uplink would otherwise force rebuilding sessions mid-engagement. Automatic certificate configuration via Let's Encrypt simplifies standing up a TLS-protected relay on infrastructure you control, though the todo list notes that mTLS support is still missing, meaning agent-to-relay authentication remains a weak point worth considering when modeling detection and abuse in lab exercises.
The feature list rounds out with socket listening and binding on the agent, multiple concurrent tunnels, and broad platform support for the agent binary — a practical necessity given how heterogeneous assessment targets tend to be. The comparison section in the README is refreshingly substantive: instead of marketing, it explains precisely why SOCKS proxies and TCP/UDP forwarders are inferior for scanning workflows, namely the per-tool configuration burden of proxychains and the latency it adds. The single static Go binary distribution model keeps deployment trivial on both ends, and full documentation lives at docs.ligolo.ng rather than being duplicated in the repository.
From a defensive research perspective, ligolo-ng is a useful artifact to study because its traffic pattern is distinctive in specific ways. The agent initiates a long-lived reverse TLS connection to an operator-controlled relay, and the connect()-based semantics mean scanning behavior manifests as completed TCP handshakes from the agent host rather than half-open scans — a footprint that differs from raw SYN scanning and can inform detection logic on the source side. Blue teams modeling this tool in a lab can also leverage the absence of raw packet forwarding: anything requiring true layer-2 manipulation will not traverse a ligolo-ng tunnel. Note the TUN interface and translated packets exist only on the operator's relay, not on the monitored endpoint, so detection emphasis belongs on egress connections and behavioral context.
Used strictly within authorized engagement scope, contractually defined lab environments, and purple-team exercises, ligolo-ng is one of the cleaner pivoting tools available. Its 4985 stars, active 0.8 development cycle, and documented performance envelope indicate a mature project that has moved from a clever concept — Gvisor-based userspace networking for tunnels — toward a team-oriented platform with persistence, automation, and a web console. For professionals who need to reason carefully about how modern tunneling tooling behaves on both sides of the wire, the repository is well worth reading in full, caveats and todo list included.
nicocha30/ligolo-ng.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.