← Back to Blog

Detecting Reverse Shells on Linux

After gaining initial code execution on a target, an attacker's first priority is establishing persistent, interactive access. The most common method is a reverse shell — a technique where the compromised host initiates an outbound connection back to the attacker, providing a remote command line.

How reverse shells work

The mechanics are straightforward:

  • the attacker sets up a listener on their machine;
  • a payload on the victim starts a shell process (bash, sh, zsh, etc.);
  • the shell's standard input and output are redirected over a network socket to the attacker's listener;
  • the attacker now has interactive command-line access to the victim.

Common one-liners use bash -i >& /dev/tcp/..., nc, python, perl, or socat. The key pattern is always the same: a shell process makes an outbound network connection to a non-local address.

Why reverse shells are hard to catch

  • They use legitimate system binaries — no malware to scan for.
  • Outbound connections on common ports (80, 443) blend with normal traffic.
  • Encrypted channels (socat with TLS, SSH tunnels) evade payload inspection.
  • Traditional IDS/IPS solutions that focus on inbound connections miss the outbound initiation.

Network-only detection is insufficient. You need host-level visibility that correlates process identity with network activity.

How SecureExec detects reverse shells

SecureExec's reverse_shell built-in rule operates at the kernel level:

  • the Linux eBPF agent captures every outbound connect() call along with the process name that made it;
  • on the server, the rule checks whether the connecting process is a known shell binary (bash, sh, zsh, dash, ksh, csh, fish, ash);
  • loopback connections (127.0.0.0/8, ::1) are excluded to reduce noise;
  • any shell-to-external-IP connection triggers a critical severity alert immediately.

No signatures, no pattern databases — the detection is based on a behavioral invariant: shell processes should not make outbound network connections in normal operation.

What an alert gives you

When a reverse shell alert fires, SecureExec captures:

  • the process name and PID of the shell;
  • the destination IP address and port;
  • the parent process that spawned the shell;
  • full process lineage via process tree;
  • all correlated events in Elasticsearch for investigation.

This tells the analyst exactly which process is compromised, who spawned it, and where it is connecting — enough to begin containment immediately.

Act on reverse shells before damage spreads

Reverse shells are a critical post-exploitation indicator. Every second of undetected access increases the blast radius.

Try SecureExec to detect reverse shell activity in real time with process-level visibility on your Linux servers.