Operational Scenarios

Operational Scenarios

Real-World Deployment Examples

This page provides complete, tested operational scenarios for common deployment patterns. Each scenario includes the exact commands, expected behavior, session management, and operational notes.

---

Scenario 1: Honeypot Listener Array

Purpose

Deploy listeners on common service ports to capture incoming reconnaissance and exploitation attempts. All traffic is logged for analysis.

Deployment

# Deploy batch listeners on common ports with traffic capture and watchdog
socat-manager batch --ports 21,22,23,25,53,80,110,143,443,445,993,995,3306,3389,5432,8080,8443 \
    --capture --watchdog --max-restarts 20

# Or deploy from a config file:
socat-manager batch --file conf/honeypot-ports.conf --capture --watchdog

# Add dual-stack (TCP + UDP) for DNS and other UDP services:
socat-manager batch --ports 53,161,5353 --dual-stack --capture --watchdog

Monitoring

# Check all active listeners:
socat-manager status

# Check a specific port:
socat-manager status 8080

# Watch capture logs in real-time:
tail -f logs/capture-tcp4-8080-*.log

Cleanup

# Stop all listeners:
socat-manager stop --all

# Or stop by port:
socat-manager stop --port 8080

Notes

• Ports below 1024 require root: sudo socat-manager batch --ports 21,22,25,80,443 --capture
• Each port gets an independent session ID -- stopping one listener does not affect others
• With 17 ports × dual-stack, you would create 34 independent sessions
• Watchdog with --max-restarts 20 is more aggressive than the default 10 -- appropriate for long-running honeypots where you want maximum uptime
• Capture logs are created with 0o600 permissions and contain hex dumps of all traffic

---

Scenario 2: Network Pivoting via Port Forwarding

Purpose

Forward traffic through a compromised host to reach internal network services not directly accessible from the operator's position.

Deployment

# Forward local port 8080 to internal web server 192.168.1.10:80
socat-manager forward --lport 8080 --rhost 192.168.1.10 --rport 80 --watchdog

# Forward local 3389 to internal RDP server
socat-manager forward --lport 13389 --rhost 10.0.0.50 --rport 3389 --watchdog

# Forward local 5432 to internal PostgreSQL
socat-manager forward --lport 15432 --rhost 10.0.0.100 --rport 5432 --watchdog --capture

# Cross-protocol: listen TCP locally, forward UDP to internal DNS
socat-manager forward --lport 8053 --rhost 10.0.0.1 --rport 53 --remote-proto udp4

Using the Paired Forward Workflow

The interactive menu simplifies this common pattern:

python3 socat-manager.py
> 1 (Listen)
> Port: 8080
> Enable watchdog: y
> Execute: y
  [✓] Listener active on tcp4:8080 (SID a1b2c3d4)
> Configure a paired forward for this listener? y
> Remote host: 192.168.1.10
> Remote port: 80
> Enable watchdog: y
> Execute: y
  [✓] Forwarder active: tcp4:8080 ⇄ 192.168.1.10:80 (SID e5f6g7h8)

Notes

• The listener captures incoming data to a log file, then the forwarder relays bidirectionally to the internal target
• With --capture on the forwarder, all relayed traffic is captured in hex dump format
• Watchdog ensures the forwarder auto-restarts if the connection drops
• The --remote-proto flag enables cross-protocol forwarding for specialized scenarios

---

Scenario 3: TLS-Encrypted Tunnel for Secure C2

Purpose

Create an encrypted tunnel that accepts TLS connections and forwards plaintext traffic to an internal service. This encrypts traffic that would otherwise be visible to network monitoring.

Deployment

# Auto-generate self-signed certificate, tunnel to internal SSH
socat-manager tunnel --port 4443 --rhost 10.0.0.5 --rport 22 --watchdog

# With custom certificate and key
socat-manager tunnel --port 4443 --rhost 10.0.0.5 --rport 22 \
    --cert /opt/certs/server.pem --key /opt/certs/server.key

# With custom Common Name for the auto-generated cert
socat-manager tunnel --port 4443 --rhost 10.0.0.5 --rport 22 --cn vpn.example.com

# With traffic capture (captures the PLAINTEXT side, not the encrypted side)
socat-manager tunnel --port 4443 --rhost 10.0.0.5 --rport 22 --capture

Client Connection

From the operator's machine, connect through the tunnel:

# Connect to the TLS tunnel
socat - OPENSSL:target-host:4443,verify=0

# For SSH through the tunnel:
ssh -o ProxyCommand="socat - OPENSSL:target-host:4443,verify=0" user@localhost

# Or use openssl s_client for testing:
openssl s_client -connect target-host:4443

Notes

• Auto-generated certificates are self-signed and stored in certs/ with 0o600 permissions on the private key
• The verify=0 on the client side disables certificate verification (necessary for self-signed certs)
• If --dual-stack is enabled, the TLS tunnel runs on TCP and a plain (unencrypted) UDP forwarder is added alongside
• Tunnel mode rejects --proto udp with a clear error -- TLS requires TCP

---

Scenario 4: DNS Redirect with Dual-Stack

Purpose

Redirect DNS traffic (both TCP and UDP) to a controlled resolver for analysis or manipulation.

Deployment

# Redirect DNS on both TCP and UDP to a custom resolver
socat-manager redirect --lport 5353 --rhost 8.8.8.8 --rport 53 --dual-stack --capture

# Or redirect to an internal DNS server
socat-manager redirect --lport 5353 --rhost 10.0.0.1 --rport 53 --dual-stack --watchdog

Testing

# Test TCP DNS:
dig @localhost -p 5353 example.com +tcp

# Test UDP DNS:
dig @localhost -p 5353 example.com

Notes

• DNS uses both TCP and UDP -- dual-stack ensures complete coverage
• Each protocol gets its own session ID: stopping the TCP redirect does not affect the UDP redirect
• Capture logs record the raw DNS traffic in hex format for later analysis
• For ports below 1024, use sudo or setcap 'cap_net_bind_service=+ep' $(which socat)

---

Scenario 5: Multi-Forwarder Network with Session Management

Purpose

Deploy multiple forwarders for a complex pivot chain and manage them independently.

Deployment

# Web server pivot
socat-manager forward --lport 8080 --rhost 192.168.1.10 --rport 80 --name web-pivot --watchdog

# Database pivot
socat-manager forward --lport 13306 --rhost 192.168.1.20 --rport 3306 --name db-pivot --watchdog

# Admin panel pivot
socat-manager forward --lport 9090 --rhost 192.168.1.30 --rport 443 --name admin-pivot --watchdog --capture

Management

# List all forwarders:
socat-manager status

# Detail on the database pivot:
socat-manager status db-pivot

# Stop only the admin pivot:
socat-manager stop --name admin-pivot

# Stop all forwarders on port range:
socat-manager stop --port 8080
socat-manager stop --port 13306
socat-manager stop --port 9090

# Or stop everything:
socat-manager stop --all

Notes

• Custom --name makes sessions easier to identify in status output
• Each forwarder runs independently with its own watchdog
• Session detail (status <name>) shows process tree, port binding, and log files
• Stopping by name only stops the matching session -- other forwarders continue

---

Scenario 6: Watchdog Tuning for Different Environments

Long-Running Operations (High Uptime)

# Max 50 restarts, 2-second initial backoff
socat-manager listen --port 8080 --watchdog --max-restarts 50 --backoff 2 --capture

Short-Lived Operations (Quick Feedback)

# Max 3 restarts, 1-second backoff -- fail fast if there's a persistent issue
socat-manager forward --lport 8080 --rhost 10.0.0.5 --rport 80 --watchdog --max-restarts 3 --backoff 1

Conservative (Don't Hammer the System)

# Max 5 restarts, 10-second initial backoff (10→20→40→60→60)
socat-manager listen --port 8080 --watchdog --max-restarts 5 --backoff 10

---

Scenario 7: Interactive Menu for Operator-Guided Setup

For operators who prefer guided configuration over memorizing CLI flags:

python3 socat-manager.py

The menu walks through every option with validation, examples, and cancel support. After each mode execution, the menu returns cleanly for the next operation. The paired forward feature after listener setup eliminates the need to configure the common listen-then-forward pattern as two separate operations.