Overview#
Tunnels let you move traffic through an agent to reach otherwise unreachable hosts on the target network. Three tunnel types are supported:
| Type | Description |
|---|---|
| Port forward | Bind a port on the teamserver (or your local machine) and forward connections to a specific host:port via the agent |
| SOCKS proxy | Bind a SOCKS5 proxy endpoint — all connections through it are routed via the agent |
| Reverse forward | The agent opens a listener on the target network and forwards connections back through the C2 channel to a destination you specify |
Bind Modes#
Every tunnel has a bind mode that controls who can use it:
| Mode | Flag | Accessible to |
|---|---|---|
| Teamserver-bind | --bind <host:port> | All operators and tools running on the teamserver |
| Operator-bind | --bind-local <host:port> | Only the operator’s local machine (CLI/TUI only) |
Teamserver-bind tunnels are ideal when multiple operators need access, or when you want to route agentless tool operations through the tunnel. Operator-bind tunnels keep the port local to your workstation — nothing is opened server-side.
Port Forwarding#
Forward a local port to a host:port reachable from the agent.
Teamserver-Bind#
| |
Any connection to 127.0.0.1:8888 on the teamserver is forwarded through the agent to 10.10.10.5:80.
Operator-Bind#
| |
The port 8888 is opened on your local machine only. No port is opened on the teamserver. The CLI opens a TCP listener locally and relays traffic to and from the agent via the teamserver WebSocket connection — no server-side bind occurs.
Example: Reach an Internal Web Server#
| |
SOCKS Proxy#
Open a SOCKS5 proxy endpoint. All connections through it are routed via the agent.
Teamserver-Bind#
| |
Operator-Bind#
| |
As with port-forward operator-bind tunnels, the CLI opens a local TCP listener and relays traffic through the teamserver WebSocket. The SOCKS5 negotiation happens locally in the CLI process.
Example: Browser Traffic Through an Agent#
Configure proxychains or your browser proxy settings to point at 127.0.0.1:1080, then browse as if you were on the target network:
| |
Or use curl directly:
| |
Reverse Port Forwarding#
The agent opens a listener on the target network. Connections to that listener are forwarded back through the C2 channel to a destination you specify.
| |
Any host on the target network that connects to WORKSTATION-01:4444 will be forwarded to 127.0.0.1:4444 on the teamserver. Useful for catching reverse shells from hosts the agent can reach but you cannot.
Dynamic Relay Management#
Open or close relay ports on a running agent without rebuilding or redeploying it.
| |
relay open tells the running agent to start listening for interior agent connections on the specified port. relay close stops that listener. The agent’s relay capability must declare the TCP relay protocol for these commands to apply.
This is useful when you need to enable relaying on an agent that was not originally deployed with a relay port, or to change the relay port after deployment.
Tunnel Lifecycle#
List Active Tunnels#
| |
Close a Tunnel#
| |
Closing a tunnel terminates any active connections through it and instructs the agent to clean up its side. For reverse forward tunnels, the agent receives a tunnel_close task that stops its remote listener and tears down any open connections through that listener.
Tab completion for tunnel close supplies full tunnel UUIDs.
Web UI: Tunnels page — shows all active tunnels with a close button per row. The page updates live as tunnels are opened and closed.
Agent Disconnect#
When a session-mode agent disconnects, all its tunnels are automatically closed and their status is updated. Any active connections through those tunnels will be dropped.
Using Tunnels with Agentless Tools#
SOCKS tunnels integrate directly with the agentless tools proxy system.
Auto-Created Proxy Config#
When you create a teamserver-bind SOCKS tunnel, the teamserver automatically registers a corresponding proxy config. You can reference it when running agentless tool operations:
| |
The --tunnel flag selects the SOCKS proxy config associated with that tunnel ID. The SSH tool routes its connection through the SOCKS proxy, reaching hosts that are only accessible via the agent.
Manual Proxy Config#
If you prefer explicit control, create a proxy config pointing at the tunnel’s bind address:
| |
Quick Reference#
| Task | Command |
|---|---|
| Port forward (teamserver-bind) | tunnel create <agent> --bind <host:port> --target <host:port> |
| Port forward (operator-bind) | tunnel create <agent> --bind-local <host:port> --target <host:port> |
| SOCKS proxy (teamserver-bind) | tunnel socks <agent> --bind <host:port> |
| SOCKS proxy (operator-bind) | tunnel socks <agent> --bind-local <host:port> |
| Reverse forward | tunnel reverse <agent> --remote-bind <host:port> --target <host:port> |
| List tunnels | tunnel list |
| Close tunnel | tunnel close <id> |
| Open relay port on agent | agents relay open <agent> <port> |
| Close relay port on agent | agents relay close <agent> |
Related Pages#
- Agent Management — agent lifecycle, relay chains
- Tools (Agentless Operations) — agentless operations that can route through tunnels
- REST API — tunnel and relay API endpoints