Tunnel Techniques Explained: When an AI Agent Needs to Pave a Road into the Internal Network

Core question: After an agent establishes a foothold, the next obstacle is often not "what else can we exploit" but "the connection simply does not work" — the target sits inside a network, has no outbound internet, and is shielded by firewalls. Tunneling exists to solve exactly this. Angle of this article: principles and defensive detection. Everything is a reading of public project designs — no operational steps.

Why getting in makes things harder

Suppose an agent already has code execution on a target server. It now faces:

• No outbound internet (the default state of many internal hosts);
• A firewall that allows only certain protocols (often just HTTP/HTTPS);
• No route between the target's segment and the attack host.

Even with execution, every operation must first find a way to send instructions in and get results out. Doing that with the crudest method — smuggling commands through web request parameters — is painfully slow and generates enormous log noise.

Tunneling turns that detour into a stable channel: once established, all subsequent tool traffic flows through it, like laying a dedicated line between two places.

Three mainstream approaches, three different principles

Approach one: SOCKS5 proxy (representative tool: chisel)

Data flow: attack host runs a server → target runs a client → they connect over WebSocket/HTTP → a SOCKS5 proxy port is exposed on the target side.

Any tool on the attack host then simply points its proxy setting at that port, and traffic is relayed through the target.

Applies when: the target can initiate outbound connections (at least to the attack host's listening port).

Characteristic: an application-layer proxy with excellent tool compatibility — nearly every tool supports SOCKS5.

Approach two: HTTP-disguised tunnel (representative tool: suo5)

Data flow: a file that looks like an ordinary web script (PHP/JSP) is placed on the target → the attack host communicates with it using normal HTTP requests → commands and results are hidden inside request/response content.

Key difference: because the traffic looks exactly like ordinary browsing, the target does not need outbound access — an accessible web service is enough.

Applies when: the target sits behind a firewall and can only communicate through an existing web service.

Cost: throughput is bound by HTTP round-trips, and something must first be placed on the target — which is itself a discoverable artifact.

Approach three: TUN virtual adapter (representative tool: ligolo-ng)

Data flow: the target runs an agent → the attack host runs a proxy → a TUN (virtual network interface) is created → the attack host's operating system gains an extra network adapter.

The most intuitive analogy: the first two approaches stretch a line between two places; this one plugs the target's internal network directly into your machine as a network interface. You can then reach internal IPs directly, without per-port forwarding.

Applies when: long-running, high-volume, multi-protocol access is needed.

Cost: requires creating a virtual adapter on the attack host (elevated privileges), raising the deployment bar.

How to choose

Situation	Recommended	Why
Target has egress; only some traffic needs relaying	SOCKS5 proxy	Best tool compatibility, simplest deployment
Target has no egress but an accessible web service	HTTP-disguised tunnel	The only workable path
The whole internal network should feel local	TUN virtual adapter	Configure once, use globally

Notably, open-source agentic pentest platforms generally implement automatic selection: probe whether the target has egress and which services are reachable, then pick an approach. That probe-decide-select loop is itself part of the agent's capability.

What defenders can see in traffic

Tunnels are designed to make traffic look normal — but the act of establishing and maintaining a channel tends to leave traces. Directions worth watching:

First, unusual outbound destinations. An internal server initiating long-lived outbound connections is itself notable — especially when the destination is not part of the organisation's known service range.

Second, the fingerprint of a single connection. A tunnel squeezes multiple protocols into one connection. A connection exhibiting database, file-sharing, and remote-desktop characteristics simultaneously is almost impossible in normal business traffic.

Third, non-business files appearing in web directories. HTTP-disguised tunnels require placing a file on the target. Routine file-integrity checks and directory baseline comparison are the foundation for catching this.

Fourth, abnormal connection duration and cadence. Humans take breaks; automated channels tend to hold connections open with steady heartbeats. That very regularity is a signal.

One line: a tunnel aims to make the channel invisible — it struggles to make the behaviour of establishing and maintaining it invisible at the same time.

How this relates to AI agents

Tunneling is not new. What changed is who decides when to open a tunnel and which kind.

Traditionally this was a human expert's judgement: inspect the environment, assess risk, choose a method. In agentic systems that judgement is decomposed into "probe facts → write into a knowledge graph → let the planner pick the matching subsystem". That means:

• Faster: time from discovery to channel establishment shrinks;
• More consistent: not necessarily smarter, but it misses fewer common cases;
• Still bottlenecked: public postmortems show that when the environment is hostile (missing tools, restricted network), the system is pushed onto inefficient paths and can even draw wrong conclusions.

For defenders, the change is predictable: the behaviour you need to detect becomes more regular, not more cunning — because automation produces regularity by construction.

Next steps

• To place tunneling within the broader attack chain, read the case study article in this series
• To see what happens after a channel exists, read credentials and AD concepts
• To learn how to study such tooling safely in isolation, read isolated research practice
• For a systematic defensive review, read defense lessons from the red-team postmortem