Skip to main content
  1. Documentation/
  2. User Guide/

Tunnels and Proxies

Table of Contents
Route traffic through compromised hosts using port forwards, SOCKS proxies, and reverse forwards — without redeploying agents or changing infrastructure.

Overview
#

Tunnels let you move traffic through an agent to reach otherwise unreachable hosts on the target network. Three tunnel types are supported:

TypeDescription
Port forwardBind a port on the teamserver (or your local machine) and forward connections to a specific host:port via the agent
SOCKS proxyBind a SOCKS5 proxy endpoint — all connections through it are routed via the agent
Reverse forwardThe agent opens a listener on the target network and forwards connections back through the C2 channel to a destination you specify
Tunnels require session-mode agents. Beacon agents cannot support tunnels because they only connect periodically — tunnels need a persistent C2 connection.

Bind Modes
#

Every tunnel has a bind mode that controls who can use it:

ModeFlagAccessible 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
#

1
2
3
tantoc2[eng]> tunnel create WORKSTATION-01 --bind 127.0.0.1:8888 --target 10.10.10.5:80
Tunnel created: fwd-a1b2c3d4
Listening on 127.0.0.1:8888 → 10.10.10.5:80 via WORKSTATION-01

Any connection to 127.0.0.1:8888 on the teamserver is forwarded through the agent to 10.10.10.5:80.

Operator-Bind
#

1
2
3
tantoc2[eng]> tunnel create WORKSTATION-01 --bind-local 127.0.0.1:8888 --target 10.10.10.5:80
Tunnel created: fwd-a1b2c3d4 (operator-local)
Listening on 127.0.0.1:8888 (local) → 10.10.10.5:80 via WORKSTATION-01

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
#

1
2
3
4
5
tantoc2[eng]> tunnel create WEB-RELAY --bind 127.0.0.1:9090 --target 192.168.100.20:443
Tunnel created: fwd-b2c3d4e5

# Now curl the internal server from the teamserver
$ curl -k https://127.0.0.1:9090/admin

SOCKS Proxy
#

Open a SOCKS5 proxy endpoint. All connections through it are routed via the agent.

Teamserver-Bind
#

1
2
3
tantoc2[eng]> tunnel socks WORKSTATION-01 --bind 127.0.0.1:1080
Tunnel created: socks-c3d4e5f6
SOCKS5 proxy on 127.0.0.1:1080 via WORKSTATION-01

Operator-Bind
#

1
2
3
tantoc2[eng]> tunnel socks WORKSTATION-01 --bind-local 127.0.0.1:1080
Tunnel created: socks-c3d4e5f6 (operator-local)
SOCKS5 proxy on 127.0.0.1:1080 (local) via WORKSTATION-01

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:

1
2
3
4
# /etc/proxychains4.conf
socks5 127.0.0.1 1080

proxychains firefox

Or use curl directly:

1
curl --socks5 127.0.0.1:1080 http://intranet.corp.local/

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.

1
2
3
tantoc2[eng]> tunnel reverse WORKSTATION-01 --remote-bind 0.0.0.0:4444 --target 127.0.0.1:4444
Tunnel created: rev-d4e5f6g7
Agent listening on 0.0.0.0:4444 (target network) → 127.0.0.1:4444 (teamserver)

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.

1
2
3
4
5
tantoc2[eng]> agents relay open RELAY-DMZ 8443
Relay port 8443 opened on RELAY-DMZ

tantoc2[eng]> agents relay close RELAY-DMZ
Relay port closed on RELAY-DMZ

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
#

1
2
3
4
5
tantoc2[eng]> tunnel list
ID              Type    Bind                  Target               Agent          Status
fwd-a1b2c3d4   forward  127.0.0.1:8888        10.10.10.5:80        WORKSTATION-01  active
socks-c3d4e5f6  socks    127.0.0.1:1080        -                    WORKSTATION-01  active
rev-d4e5f6g7   reverse  0.0.0.0:4444 (remote)  127.0.0.1:4444      WORKSTATION-01  active

Close a Tunnel
#

1
2
tantoc2[eng]> tunnel close fwd-a1b2c3d4
Tunnel fwd-a1b2c3d4 closed.

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:

1
2
3
4
5
tantoc2[eng]> tools run ssh exec \
    --target 192.168.100.15:22 \
    --username alice \
    --credential alice-ssh-key \
    --tunnel socks-c3d4e5f6

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:

1
2
tantoc2[eng]> proxies create --name via-workstation --type socks5 --host 127.0.0.1 --port 1080
tantoc2[eng]> tools run ssh exec --target 192.168.100.15:22 --proxy via-workstation ...

Quick Reference
#

TaskCommand
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 forwardtunnel reverse <agent> --remote-bind <host:port> --target <host:port>
List tunnelstunnel list
Close tunneltunnel close <id>
Open relay port on agentagents relay open <agent> <port>
Close relay port on agentagents relay close <agent>

Related Pages#