Webshell vs Reverse Shell: Foothold vs Interactive Session
The difference between a webshell and a reverse shell, why testers often use both, and how each one looks to a defender.
After getting code execution on a web server, you have two ways to keep working: leave a webshell behind, or fire a reverse shell back to yourself. They are not competitors — they solve different problems, and a thorough authorized test often uses both. Knowing which to use when, and what each one costs you in detectability, is the point of this post.
What Each One Is
A webshell is a script you place on the server (commonly .php, .jsp, .aspx) that executes commands passed in an HTTP request and returns the output in the response. You "use" it by sending requests:
GET /uploads/shell.php?c=id
It rides the web server's existing listening port — no new connection leaves the box.
A reverse shell is an interactive session: the server connects out to your listener and you get a live shell. See what is a reverse shell.
The Trade-offs
| Webshell | Reverse shell | |
|---|---|---|
| Interactivity | Per-request, stateless, clunky | Live, interactive (after a TTY upgrade) |
| Egress needed | No — uses inbound HTTP | Yes — needs outbound to you |
| Persistence | Survives until the file is found | Dies when the connection drops |
| Footprint | A file on disk + web-log entries | An outbound connection |
The headline: a webshell needs no egress because the traffic is inbound HTTP that the firewall already allows — which is exactly why it works on locked-down networks where a reverse shell can't get out. But it is a poor place to actually work: no interactive programs, no persistent shell state, a new process per command.
Why Testers Use Both
The common pattern: drop a small webshell first as a reliable foothold that survives drops and needs no egress, then use it to launch a reverse shell for comfortable interactive work. If the reverse shell dies — flaky network, killed process — the webshell is still there to relaunch it. The webshell is your anchor; the reverse shell is your workspace.
The same code-execution primitive feeds both. A PHP reverse shell payload and a PHP webshell come from the same foothold, often the same LFI or upload bug.
How They Look to a Defender
Worth knowing when you are also testing detection. A webshell shows up as an unexpected script in a web-accessible directory and as anomalous requests in the access logs — odd parameters, commands in query strings, requests to a file that should not exist. A reverse shell shows up as an outbound connection from a web server that has no business dialing out. Different artifacts, different hunt; see detecting reverse shells.
Clean Up Both
An engagement is not finished until the webshell file is removed and any reverse shell sessions are closed — see authorized testing cleanup.
Generate the Reverse Shell
For the interactive half, the reverse shell generator gives you a payload with your LHOST/LPORT and the matching listener.
Authorized Testing Only
Webshells and reverse shells are for web applications you own or are explicitly authorized to test. Authorization is what makes the work legitimate.