Reverse Shell Indicators

A Debian-first guide to spotting outbound shell activity, suspicious connections, unusual parent-child process chains, and likely callback behavior.

What this is

A reverse shell is a shell or command session initiated from the victim system back to an attacker-controlled host. Instead of the attacker directly logging in, the compromised system connects outward and hands over command access.

Reverse shells are common in post-exploitation scenarios because outbound connections are often easier to establish than inbound access.

What it looks like

A shell process tied to a network connection
bash, sh, python, perl, or nc connected to a remote IP
Unexpected outbound connections to unfamiliar hosts or high ports
Shells launched by web services or application accounts

Detect

Review active TCP connections with process association

sudo ss -tpn

Search for common reverse shell tooling in processes

ps aux | grep -E "nc |ncat|netcat|bash -i|/dev/tcp|python|perl|php|socat"

Check the full process tree

ps auxf

A reverse shell often stands out when a web server, script, or service launches a shell unexpectedly.

Inspect a suspicious PID in detail

sudo readlink -f /proc/<PID>/exe
sudo tr '\0' ' ' < /proc/<PID>/cmdline; echo
sudo ls -lah /proc/<PID>/cwd

Review recent logs around suspicious timing

sudo journalctl --since "1 hour ago"

Contain

Block outbound access to the suspicious remote IP

sudo ufw deny out to <IP_ADDRESS>

Terminate the suspicious process

sudo kill -TERM <PID>
sudo kill -KILL <PID>

Stop the launching service if needed

sudo systemctl stop <service_name>
sudo systemctl disable <service_name>

If the shell came from a web application or service account, contain the origin too.

Recover

Determine how the shell started

ps auxf
crontab -l
sudo crontab -l
sudo systemctl list-units --type=service --state=running

Check for related file changes in likely locations

sudo find /tmp /var/tmp /dev/shm /var/www -type f -mtime -2 2>/dev/null

Review accounts and privilege changes

sudo grep "Accepted" /var/log/auth.log
sudo grep "sudo" /var/log/auth.log

A reverse shell is a strong sign of compromise. Recovery should include checking persistence, reviewing web content or launched scripts, and validating that no new users, cron jobs, or services were created.

Prevent

Reverse shells usually happen after another weakness is exploited. Prevention is about reducing code execution paths and limiting egress where practical.

Option 1 — Reduce exposed services and vulnerable apps

sudo ss -tulnp
sudo systemctl list-units --type=service --state=running

Option 2 — Review outbound connections regularly

sudo ss -tpn

Option 3 — Monitor temporary and web directories

sudo find /tmp /var/tmp /dev/shm /var/www -type f 2>/dev/null | less

Option 4 — Keep software updated

sudo apt update
sudo apt upgrade

Option 5 — Use restrictive firewall rules where possible

sudo ufw status numbered

Optional Tools & Hosting

Manual review comes first. Future recommendations may include low-cost infrastructure or monitoring options that help surface suspicious outbound behavior faster, but the core response remains command-driven.

Notes

A reverse shell is much more serious than simple scanning or probing.
If you find one, assume deeper review is necessary.
The key question is not just what process ran, but what allowed it to run.

Environment Note

All commands shown are based on Debian-based systems unless otherwise noted.