The Network Mapper (NMAP) is an open-source, free, security scanner that is widely popular, and favorited, amongst security and network analysts. Commercial organizations have tried to emulate it’s effectiveness, but have often failed, usually resorting to integrating it into their platform as an added “feature”.
At its core, however, is an extremely powerful tool that we should all be familiar with. This post will explore how NMAP can be used as part of your bag of tricks.
About NMAP
NMAP is a what we call a network discovery and reconnaissance tool. It allows us to perform scans against a network to better understand our infrastructures security posture. These scans are so informative that they are used by good and bad actors alike. While the tool was first created as a network scanner, it has evolved over the years to be a tool that can be applied across your entire stack (i.e., application, network, etc..).
Note: Books have been written about NMAP and it’s application, but in this post we’ll keep it basic in an effort to introduce and provide a basic orientation of the tool.
By default, you run this tool via the command line, but there is a GUI option called Zenmap that offers an user interface. While I have not personally used it, it does appear to have all the same capabilities you’ll find in the terminal version.
Leverage the Scripting Libraries
One of the many reasons that NMAP is so heavily favored is how well maintained it is, and how rich it’s functionality is. The latter is made possible by the Nmap Scripting Engine.
The scripting engine comes installed by default when you install NMAP and provides a rich repo of pre-built tools that can be used out of the box. It also allows you to write your own scripts to automate tasks as required. We encourage you to watch this video from when NSE was introduced for a more thoughtful explanation of how it works:
You will find a complete list of the available scripts (600+), and corresponding categories, on the Nmap website. The categories are there to make your life a bit easier.
Every script is bound to a category, which means you can run a script individually or the category as a whole.
For example, let’s assume we were interested in the corresponding autonomous system (AS) number for a specific asset. We would look up the script – ASN-Query – and we would see the following:
Script types: hostrule
Categories: discovery, external, safe
You will also see an example of how to call the script (where the brackets are options you can call):
nmap --script asn-query [--script-args dns=] <target>
But if you prefer to call the entire category, you could just as easily do it like this:
nmap --script discovery <target>
This would run all the scripts that fall in the Discovery category.
Real-World Application
When you first get started, it can feel overwhelming, but you’ll quickly find it’s a very straightforward tool designed to make your life just a little easier.
For instance, let’s assume you that the team has just deployed 5 new servers to your stack. In it’s most basic form, Nmap can help you identify what the outside world can see.
Here is an example of what that might look like when checking one of the servers:
root@localhost:~# nmap 173.255.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-11 15:53 UTC
Nmap scan report for [server domain] (173.255.xxx.xxx)
Host is up (0.00043s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp filtered smtp
80/tcp open http
443/tcp open https
465/tcp filtered smtps
587/tcp filtered submission
This very basic scan shows me that this server is running SSH (port 22), HTTP/HTTPS (port 80/443) and a Mail Server (port 25). This would beg the question, should we be broadcasting that SSH is open? And why is the mail server running on a web server? Was that intentional? These days there are so many other options available to us that would allow us to move that mail server to a different environment for better functional isolation.
Another scan using the version category will then show us a bit more information like the versions of the software bound to each port:
root@localhost:~# nmap -sV 173.255.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-11 16:08 UTC
Nmap scan report for [server domain] (173.255.xxx.xxx)
Host is up (0.037s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
25/tcp filtered smtp
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
443/tcp open ssl/http Apache httpd 2.4.29 ((Ubuntu))
465/tcp filtered smtps
587/tcp filtered submission
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
You can also see details about OpenSSH, and the fact that I’m running Ubuntu. Armed with this information, a bad actor is able to quickly dismiss those things he knows won’t work because the environment doesn’t support it, but also can gain a much better understanding of what is available and what could be abused (i.e., investigate ways the current version might be abused).
A great example might be that this server is running Apache 2.4.29, which is susceptible to the recent CVE-2021-41773 (a path traversel vulnerability) vulnerability.
Another example might be that the OpenSSH is running on version 7.6, while the latest version of OpenSSH Is 8.8. A quick search would show us that this version of OpenSSH has a number of possible security concerns between CVE-2018-15473, CVE-2018-15919, and a number of other CVE’s as defined in the NIST database.
Now, if you five servers that just went live you can scan all five at the same time using a space to separate the IP values. Like this:
root@localhost:~# nmap -sV 192.155.xxx.xxx 198.58.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2022-01-11 19:06 UTC
Nmap scan report for server.domain1.net (192.155.xxx.xxx)
Host is up (0.037s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
25/tcp filtered smtp
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
443/tcp open ssl/http Apache httpd 2.4.29 ((Ubuntu))
465/tcp filtered smtps
587/tcp filtered submission
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap scan report for server.domain2.net (198.58.xxx.xxx)
Host is up (0.00037s latency).
Not shown: 996 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.3 (protocol 2.0)
25/tcp filtered smtp
465/tcp filtered smtps
587/tcp filtered submission
Again, we quickly see that the servers that have come online are in dire need of a few updates. When was the last time you checked what can be seen from the outside world?
Nmap Empowers The Analyst
Nmap is a great tool that every analyst should have as part of their arsenal of tools. Even in it’s most basic deployment, the insights you can gain about your environment can prove invaluable to helping you secure your perimeter.
Make note that you should only use this tool against assets you are responsible for, have permission to use them against, or own. If you have Nmap running, and want to verify it’s working use the server released for testing here: scanme.nmap.org