Netcat, Listeners, and Reverse/Web Shells

Command injection and file upload get you code execution - but a single command is not interactive control. This lesson is the post-exploitation companion: start a netcat listener, catch a reverse shell fired from a vulnerable lab endpoint, and upgrade it to a usable TTY. Learn bind vs reverse shells, the common one-liners, web shells after file upload, and the egress/EDR defences that stop them - strictly on loopback or a lab box you own.

A note on scope within the curriculum. Every technique covered so far has targeted the web application layer — HTTP requests, form inputs, SQL queries, session tokens. This lesson crosses into post-exploitation territory: once a web vulnerability grants code execution, the next step in a real penetration test is to establish an interactive session — a shell — on the underlying host. Understanding this step is essential for seeing how a web vulnerability chains into full host compromise, and it is a standard skill in authorised pentesting and CTF competitions. The practical here runs only against your own loopback or a lab VM you control.

The injection lessons taught you how to make a vulnerable application run code — a command injected into a shelled-out call, a malicious file written through an upload, a payload that reaches eval. But running a single command is not the same as control. You can run id and watch the answer scroll past, yet you cannot explore the filesystem, pivot, or work interactively. The bridge from "I can run one command" to "I have an interactive session on this host" is a shell — and the classic, universal tool for catching one is **netcat (nc)**. This lesson is the post-exploitation companion to the command-injection, file-upload, and file-inclusion lessons.

Scope and safety warning — loopback / lab only. Catching a reverse shell is a genuine intrusion primitive. Everything here is to be practised only on a machine you own — your own loopback interface (127.0.0.1), an isolated lab VM such as DVWA or Metasploitable, or a target you hold explicit written authorisation to test. Opening a listener and pulling a shell from a system you do not own is unauthorised access. The unchanging rule applies: capability is never permission.

About the practical. The interesting half of a reverse shell — the listener — runs entirely on your machine, against your loopback, so it touches no one else. You will start a netcat listener, trigger a reverse-shell one-liner from a local lab endpoint, catch the connection, and upgrade it to a usable terminal. If you do not have Kali or a lab to hand, read the commands closely so you can recognise them; you do not need a live victim to finish the lesson.

In this lesson you will:

Distinguish a bind shell (a port opened on the victim) from a reverse shell (the victim connects out to you), and understand why the reverse shell usually wins against firewalls and NAT.
Use netcat in its two roles — as the listener that catches a shell (nc -lvnp <port>) and as the connector some payloads use to dial home.
Recognise the common reverse-shell one-liners (bash /dev/tcp, the mkfifo netcat fallback, python, php) and pick one based on what the target has installed.
Drop a web shell after a file upload, and upgrade a dumb shell to a real TTY for history, job control, and interactive tools.
Map the defences — egress filtering, EDR, least privilege, and fixing the root-cause injection/upload flaw.

Estimated time: eight to ten minutes.

When you are ready, send the Continue signal.

Netcat, Listeners, and Reverse/Web Shells

A note on scope within the curriculum. Every technique covered so far has targeted the web application layer — HTTP requests, form inputs, SQL queries, session tokens. This lesson crosses into post-exploitation territory: once a web vulnerability grants code execution, the next step in a real penetration test is to establish an interactive session — a shell — on the underlying host. Understanding this step is essential for seeing how a web vulnerability chains into full host compromise, and it is a standard skill in authorised pentesting and CTF competitions. The practical here runs only against your own loopback or a lab VM you control.

Scope and safety warning — loopback / lab only. Catching a reverse shell is a genuine intrusion primitive. Everything here is to be practised only on a machine you own — your own loopback interface (127.0.0.1), an isolated lab VM such as DVWA or Metasploitable, or a target you hold explicit written authorisation to test. Opening a listener and pulling a shell from a system you do not own is unauthorised access. The unchanging rule applies: capability is never permission.

About the practical. The interesting half of a reverse shell — the listener — runs entirely on your machine, against your loopback, so it touches no one else. You will start a netcat listener, trigger a reverse-shell one-liner from a local lab endpoint, catch the connection, and upgrade it to a usable terminal. If you do not have Kali or a lab to hand, read the commands closely so you can recognise them; you do not need a live victim to finish the lesson.

In this lesson you will:

Distinguish a bind shell (a port opened on the victim) from a reverse shell (the victim connects out to you), and understand why the reverse shell usually wins against firewalls and NAT.
Use netcat in its two roles — as the listener that catches a shell (nc -lvnp <port>) and as the connector some payloads use to dial home.
Recognise the common reverse-shell one-liners (bash /dev/tcp, the mkfifo netcat fallback, python, php) and pick one based on what the target has installed.
Drop a web shell after a file upload, and upgrade a dumb shell to a real TTY for history, job control, and interactive tools.
Map the defences — egress filtering, EDR, least privilege, and fixing the root-cause injection/upload flaw.

Estimated time: eight to ten minutes.

When you are ready, send the Continue signal.