If you are reading this text, odds are that you have used Nmap before. For those who have not, here is a short description of this powerful enumeration tool. Nmap (Network Mapper) has been around since 1997 and was originally created by Gordon "Fyodor" Lyon. Even if you have never used the program before, you have probably seen its output in at least one of the many films it has been in.
Nmap can be used to scan a network, monitor services, assist in system inventory tasks, and so on. Depending on which options are selected, Nmap will be able to provide operating system type, open ports, and more. As if that were not enough, the Nmap Scripting Engine can be used to extend base functionality even further.
There are now a large number of scripts included in Nmap. The purpose of these scripts ranges from guessing Apple Filing Protocol (AFP) passwords to verifying whether connectivity can be established to X-servers.
The Nmap suite also includes:
- Zenmap: This is the graphical user interface for Nmap.
- Ncat: This is based on Netcat, but updated with a larger feature set such as ncat chaining, SSL support, and more. Binaries are available.
- Ncrack: This is used to test authentication implementations and password strength. It provides support for many commonly used protocols.
- Ndiff: This can be used to baseline a network. Compare Nmap scans against each other.
- Nping: This allows you to craft custom packets that can then be integrated into your scans. It is able to perform raw packet manipulation.
The Nmap command syntax is: nmap -{type(s)} -{opt(s)} {target}
The following are the useful options:
The following are the useful types:
The following are the output types:
We will begin by trying some basic scans against our Ubuntu_TestMachine_1 at 192.168.50.20. Here, we will perform a simple scan to determine what ports are open on our target system using the -A option.
# nmap -A 192.168.50.20 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2920:32 EDT Nmap scan report for 192.168.50.20 Host is up (0.00045s latency). Not shown: 999 closed ports PORT STATE SERVICE VERSION 80/tcp open http Apache httpd/2.4.7 ((Ubuntu)) |_http-title: Site doesn't have a title (text/html). MAC Address: 08:00:27:64:38:C7 (Cadmus Computer Systems) Device type: general purpose Running: Linux 3.X OS details: Linux 3.2 –3.19 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.46 ms 192.168.50.20 OS and Service detection performed. Report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 11.24 seconds
Looking at the highlighted results, we can determine that there is an open port at 80/tcp running an Apache httpd web server version 2.4.7. We also see that the operating system running on the target is Linux 3.X. In addition, the -A flag initiated a traceroute command that provides us with the fact that the target is only one hop away.
That is a lot of information gained from a very simple command.
Nmap can be used for a variety of purposes. In addition to being a fast network discovery tool, it can also be used to stealthily baseline your network, fingerprint services, map out firewall rules, and can be configured to bypass IDS signatures. We will now try out some of the more advanced features that Nmap makes available to us. This information is by no means holistic, so we will be focused on the features that will assist us in testing secured environments.
The network scanning process involves sending specially crafted packets to network hosts and examining the results for certain criteria. Based on these results, you will hopefully be able to determine which hosts are on the network, what services they are running, and at which version level these services are. This information is then used to decide what types of attacks are likely to be successful. There are several methods we can use to try to determine this information, some are akin to walking down the street screaming your name, whereas others are analogous to creeping along in the shadows at night.
In a secured environment, you are likely to be dealing with IDS's that look for specific behaviors such as: how many packets were sent out, how fast they were sent, whether the traffic is unusual, and so on. Firewalls will be prone to flag any abnormal connection attempts. To ensure you have a slight opportunity at remaining undetected, there are certain measures that need to be taken.
You can change the timing of your scans using the following Nmap options:
- -T(0-5): The -T(0-5) templates allow you to set the aggressiveness of the scan. This is the most simplistic method of detection avoidance. Zero is paranoid and five is insane and should be used only on a LAN. This is much faster than setting these options individually, but reduces the control you have over the scan.
- --max-hostgroup: This will limit the hosts that are scanned to only one at a time. You can change the value to anything you are comfortable with, but remember that IDS's will combine the probes you send out when checking against their signatures (for example, five probes in 2 minutes, and so on).
- --max-retries: In penetration testing, this is a setting that you may not want to adjust unless you are very certain of the network's stability. You could reduce this value to 0 if you are very paranoid and not concerned with missing a potentially vulnerable system in your scan.
- --max-parallelism 10: This would only allow 10 outstanding probes to be out at once. Use this to control how many probes you want out at once.
- --scan-delay: This allows you to set a pause between probes.
Let's try some of these options in the following command:
# nmap -P0 -n -sS --max_hostgroup 1 --max_retries 0 --max_parallelism 10 192.168.50.0/24
Retransmission caps will be hit; ports will be given up upon. By the time the scan completes, we will know which systems are live on the 192.168.50.X subnet.
This is the result of a typical scan from 192.168.50.10 to 192.168.75.11.
root@kali:~# nmap -T5 192.168.50.10 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2921:32 EDT Nmap scan report for 192.168.50.10 Host is up (0.0017s latency). Not shown: 995 closed ports PORT STATE SERVICE 21/tcp open ftp 79/tcp open finger 80/tcp open http 110/tcp open pop3 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 13.19 seconds
We can see from this output that 21, 79, 80, 110, and 443 are open on this host.
Tip
This scan type would be detected by most IDS's even if they are running in a default configuration; however, network- and host-based firewalls may ignore the traffic by default unless specifically configured to log permitted traffic. If you want to see the results in action, turn on ufw and use it to open and close specific ports. This exercise may help to fully understand the resulting output.
Were you to try this scan with a stateful host-based firewall blocking traffic to port 79 and 21, you would see traffic similar to the following:
root@kali:~# nmap -T5 192.168.50.10 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2922:02 EDT Nmap scan report for 192.168.50.10 Host is up (0.0014s latency). Not shown: 995 closed ports PORT STATE SERVICE 21/tcp filtered ftp 79/tcp filtered finger 80/tcp open http 110/tcp open pop3 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 15.22 seconds
By reviewing the highlighted code closely, we can see that the port state is filtered for ports 21 and 79. Although we were not able to establish if the ports are open, we do know that they exist on the target machine to some context.
Using -sS against a wide-open host at 192.168.50.10 from 192.168.75.11, we see the following:
root@kali:~# nmap -sS -T5 192.168.50.10 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:02 EDT Nmap scan report for 192.168.50.10 Host is up (0.00040s latency). Not shown: 995 closed ports PORT STATE SERVICE 21/tcp filtered ftp 79/tcp filtered finger 80/tcp open http 110/tcp open pop3 443/tcp open https Nmap done: 1 IP address (1 host up) scanned in 14.23 seconds
Just as in the preceding example, this indicates that we have at least five open and/or filtered ports available. Be sure to use different scan types when attempting enumeration of the target network, or you may miss out on something that could make a huge difference to your testing efforts.
If the only scan we had attempted had been the null scan, we would have been very disappointed:
root@kali:~# nmap -sN -T5 192.168.50.10 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:12 EDT Nmap scan report for 192.168.50.10 Host is up (0.00051s latency). All 1000 scanned ports on 192.168.50.10 are open|filtered Nmap done: 1 IP address (1 host up) scanned in 20.24 seconds
This tells us that all of the ports are open|filtered. We can assume that we have some firewall action, but we did not actually learn anything immediately useful.
As we did not find anything on our null scan, we proceed to use the ACK scan type.
root@kali:~# nmap -sA -T5 192.168.50.10 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:22 EDT Nmap scan report for 192.168.50.10 Host is up (0.00059s latency). Not shown: 999 filtered ports PORT STATE SERVICE 443/tcp unfiltered https Nmap done: 1 IP address (1 host up) scanned in 51.22 seconds
At least this scan provided us with one unfiltered port. If we really wanted to perform testing, we would need all of the open ports, not just one!
Using different scan types might draw more attention to you, but sometimes it's necessary in order to gather the data you need. Ideally, you would begin by scanning with the least noticeable scan types and work your way up based on the type of information you are gathering. Always double-check before you move on to the next subnet, especially if you have good reason to believe that there are some valuable ports available that are just not showing up.
Since the odds of remaining undetected are slim, we will need to try to deflect the blame. We can use an idle scan to have a zombie take all of the credit for our scan.
Tip
The https://nmap.org/ has a very detailed and thorough description of how an idle scan works. Take a look at https://nmap.org/book/idlescan.html for a full overview of how these work.
An important item to remember about idle scanning (-sI) is that you will need to find a zombie host that has a good TCP sequence prediction rating. The idle scan is aptly named, as the machine being used as our scapegoat must be as close to idle as possible. Many in the industry suggest network-enabled printers as perfect zombies because they typically do not have constant traffic, and their sequence prediction difficulty ratings are usually very low.
The first step of an idle scan is to locate possible zombies. You can find the TCP sequence prediction ratings by performing the following (verbose, OS detection, no ping, and no name resolution):
# nmap -v -O -Pn -n 192.168.50.10
The section of the output that you will want to focus on is as follows:
Network Distance: 1 hop TCP Sequence Prediction: Difficulty=195 (Good luck!) IP ID Sequence Generation: Sequential
The preceding system is not ideal, but should be able to be used as a zombie. The higher the difficulty rating is, the more likely your attempt to use this machine as a zombie will fail. Also, the fact that the generation is sequential will improve the likelihood of the scan being successful.
Let's review the concept of an idle scan:
- Send SYN/ACK to zombie, which in turn provides an RST with a fragment identification number (IPID).
- A specially crafted packet with the IP address of the zombie host is sent to the target machine.
- A closed port on the target machine will cause an RST to be sent to the zombie, in which case nothing happens. An open port on the other hand will cause the target machine to respond to the IP address of our forged packet with a SYN/ACK, which in turn causes our zombie machine to send the target an RST once it realizes that there is no valid connection. The IPID has now been incremented!
- We close the loop by sending our zombie another SYN/ACK and checking to see if the IPID has increased by two—once for our RST and once for the target machines, RST.
- Repeat until all target machine ports have been probed!
When looking at how the zombie scan works, it is easy to see that the proper usage of an idle scan can be useful in slowing down members of the blue team (defensive security professionals).
So, what is the syntax of this command? With this much power, it has to be super difficult, right? You might be pleasantly surprised when looking at the following command structure:
nmap -p 23,53,80,1780,5000 -Pn -sI 192.168.1.88 192.168.1.111
Here, we used -p to initiate a scan of TCP ports that we already know are opened; we also indicated that we did not want to ping (which would give us away) with -Pn, and then initiated an idle scan (-sI) using 192.168.1.88 as our zombie and 192.168.1.111 as our target. This results in the following output on the sample network:
Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:32 EDT Idle scan using zombie 192.168.1.88 (192.168.1.88:80); Class: Incremental Nmap scan report for 192.168.1.111 Host is up (0.036s latency). PORT STATE SERVICE 23/tcp open telnet 53/tcp open domain 80/tcp open http 1780/tcp open unknown 5000/tcp open upnp MAC Address: 30:46:9A:40:E0:EE (Netgear) Nmap done: 1 IP address (1 host up) scanned in 1.18 seconds
If we look at the output from Wireshark, we can see some strange activity coming from 192.168.1.88 to 192.168.1.111:
Looking at the Wireshark results, we see that the previous Nmap command initiated a lot of traffic from 192.168.1.88 to 192.168.1.111 on our network. This traffic is what will initiate the activity needed to increase the IPID that tells us that the target system has open ports.
The only way to truly avoid an IDS rule is to know what they are and test your attacks in a virtual environment. We will dedicate an entire chapter of this book to avoid detection. Be prepared to take the time to understand what an IDS looks for and use the methods we have already described to manage your scans to perform detection avoidance.
The use of Nmap decoys can be an interesting concept. We tell Nmap to add additional hosts to the scan. You will not get any response from these decoys, but they will make it more difficult for an administrator to determine which IP is actively scanning, and which IP is just there to muddy the waters, so to speak. Ideally, you would be initiating a scan that will have enough live decoys to drive down the detection capability of the targets administrators.
An item of note is that you are able to perform many of the scan types when using decoys. You will not be restricted and can use all of your tricks without hesitation.
Let's give this a try in our virtual lab:
# nmap –D 192.168.75.10,192.168.75.11,192.168.75.1,ME -p 80,21,22,25,443 -Pn 192.168.75.2
Here, we invoke Nmap followed by the -D switch, which will cause us to perform a decoy scan. We follow this command with a listing of decoys of our choice, all of which are live machines in this case. Once again we do not want to send out a ping request, so we stop this action using -Pn. The chosen port range was set with -p as 80,21,22,25, and 443.
Here are the results of this scan:
Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:42 EDT Nmap scan report for 192.168.75.2 Host is up (0.00036s latency). PORT STATE SERVICE 21/tcp filtered ftp 22/tcp filtered ssh 25/tcp filtered smtp 80/tcp open http 443/tcp filtered https MAC Address: 08:00:27:DF:92:32 (Cadmus Computer Systems) Nmap done: 1 IP address (1 host up) scanned in 14.35 seconds
Nothing new here; we once again determined which ports are opened, filtered, or closed. The real magic occurred on the wire. Let's take a look at what is seen by a network-based firewall:
If you take a look at the source field, you should note that the decoys we used are now populating the firewall filter that has been set to record all traffic. Using enough decoys, you could create a storm of sorts and thus fully confuse and delay the administrator of the network while you are performing your enumeration.
The Nmap scripting engine allows you to create and use custom scripts that perform many different functions. As previously mentioned, Nmap comes with many of these scripts already packaged for you. A fully detailed guide to the Nmap Scripting Engine (NSE) is available at https://nmap.org/book/nse.html. Using the --script option, you are able to invoke your own scripts or pick and choose from the vast repository of scripts that are already available.
Using Nmap's --script-help option will allow you to display several helpful fields of a particular script without actually running it. For instance, if we look at Kali Nmap's script folder at /usr/share/nmap/scripts and performed an ls -lah, we see a long list of scripts:
This list continues much further than what is displayed in this book and is constantly being updated. So, what if you want to learn about banner.nse? This script looks interesting, and we can make assumptions based on the name, but it would be better to look at the description provided by the author, by typing:
# nmap --script-help "banner.nse" Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:48 EDT banner Categories: discovery safe http://nmap.org/nsedoc/scripts/banner.html
A simple banner grabber connects to an open TCP port and prints out anything sent by the listening service within five seconds.
The banner will be truncated to fit into a single line, but an extra line may be printed for every increase in the level of verbosity requested on the command line.
So, in this case, our assumption was more than likely correct. Not only do you learn that the banner.nse file is used to connect to open TCP ports for banner grabbing, but also that it is considered to fall under the category of discovery and safe, both of which are categories that you can call when using the script option from the command line. You can also visit http://nmap.org/nsedoc/ for easy access to script information.
We do not yet have anything that banner.nse would work on in our lab, but let's go ahead and run the scripts that are initiated by the simple -sC option. If you have not already looked at the Nmap NSE website to see which scripts these are, you may want to give it a quick visit to ensure that you fully understand the scripts that are being initiated before this is tried on a production network.
Take a look at the output produced by the following command:
# nmap -Pn -sC 192.168.50.11 Starting Nmap 6.49BETA4( https://nmap.org ) at 2015-08-2923:52 EDT Nmap scan report for 192.168.50.11 Host is up (0.00090s latency). Not shown: 995 closed ports PORT STATE SERVICE 21/tcp open ftp |_ftp-bounce: no banner 79/tcp open finger | finger: | Debian GNU/Linux Copyright (c) 1993-1999 Software in the Public Interest | | Your site has been rejected for some reason. | | This may be caused by a missing RFC 1413 identd on your site. | | Contact your and/or our system administrator. |_ 80/tcp open http |_http-title: Site doesn't have a title (text/html). 110/tcp open pop3 |_pop3-capabilities: capa APOP 443/tcp open https |_http-title: eBox Platform |_http-methods: No Allow or Public header in OPTIONS response (status code 403) |_sslv2: server still supports SSLv2 Nmap done: 1 IP address (1 host up) scanned in 18.39 seconds
The -sC option provides us with many details that the other scan types just did not manage to present. There is a cost associated with this. Many of the scripts that you have just seen run are very noticeable on the network and/or on the host they are being run on. Taking a look at the previous output, we can now see that not only is pop3 open at port 110, but also that it has capa and APOP capabilities. We also know now that this system will support connections to SSLv2, which is a known vulnerable protocol that we can possibly exploit to our advantage.
All of these preloaded scripts are great, but what if you want to add additional scripts to your arsenal, either because you wrote them yourself or because someone you trust has provided you with the latest and greatest thing they developed and you want to take advantage of it when performing your penetration tests? This can be very simple!
- Add the
script.nsefile to the directory where the other Nmap NSE scripts are located. - Run the following command to update the database that bundles the scripts via categories:
# nmap -script-updatedb - Now, you can use your new scripts via the nmap
--script "scriptname.nse"or using the categorical grouping that the script was associated with.
While many penetration testers would not be caught under any circumstances using this GUI frontend to Nmap, there are many features of the GUI that can assist the tester with organizing the different data from network service scanning on a network. Additionally, you can always type all of the commands into the Command window and carry out any type of scan equivalent to using the command line. One of the nice features of the tool is the fact that it records the information from the scan and this allows us to map the network. You can access the tool by navigating to Applications | Information Gathering | zenmap. An example of the GUI is shown in the following image:
As the image shows, the listing of the hosts that the Nmap tools has discovered is shown. There are a number of additional items that are of interest; we will not cover them all here, but you are encouraged to review them at your leisure. We will look at one more of the items before moving on, and that is the feature for the Topology, and example of this is shown in the following image:
As the image shows, though this option allows us to map the network topology, it is not as helpful when we are doing an internal test and the network is flat. It is, however, very helpful when the network is layered and not flat.