Nmap is a free, open source tool for running scans on networks and discovering potential vulnerabilities. If you’re a pentester, Nmap is a crucial part of your reconnaissance for understanding the landscape of what you’re working with. As a developer or sysadmin, you should absolutely learn how to use Nmap to scan your networks! It gives you a “black box” view of what’s going on in your network and allows you to view it the way hackers do. So if you can spot any issues - chances are, someone malicious already has!
Note: if you’re a web developer hosting your website on a third-party service, you might not have permission to do networks scans. AWS allows customers to carry out penetration tests, but other hosters might not. Make sure you check first!
- Penetration testers
Nmap is pretty easy to install on Windows and MacOS - check out the official download page. I recommend using Zenmap, the GUI that comes with the Windows and MacOS download. Zenmap looks like this:
If you’re on Ubuntu or similar, you can instead run something like this:
sudo apt-get install nmap
Scanning for Ports With Nmap
Nmap is a powerfully versatile tool with many options. So many that the people behind Nmap managed to write a 468-page long book on it.
I’ll go over the basic usage of Nmap first, and then we can get into some of the fancier options. I’ll use Yahoo.com at my target host since they’ve got an active bug bounty program and won’t arrest me.
Here’s a basic scan:
nmap -sS yahoo.com
The -sS flag performs a SYN scan, scanning many ports without ever completing a TCP connection. This is a great option if you don’t want to be too noisy. This shows us there are two open ports, 80 and 443 (for HTTP and HTTPS). Pretty much what we’d expect!
Let’s add another flag to this, -O.
nmap -sS -O yahoo.com
This time, we see the ports and also some guesses of what OS the server might be running. Knowing what OS is running on a server is an important part of reconnaissance since some vulnerabilities are OS-specific. For example, OpenSSH 5.3 is ancient and has exploits publicly available, and if you see it on a server, chances are it’s vulnerable. The most notable exception to this is if the server runs Redhat OS, since Redhat has patched around OpenSSH 5.3’s issues.
Side note: the -O flag is slow, so drop it from your scan if you don’t need it.
Let’s check out another flag, -sV.
nmap -sS -O -sV yahoo.com
PORT STATE SERVICE VERSION 80/tcp open http-proxy Apache Traffic Server 113/tcp closed ident 443/tcp open ssl/http-proxy Apache Traffic Server
This time, we see the version of what software is running on the ports! This is crucial for discovering vulnerabilities since older software tends to have more exploits available. Try also throwing in the -v flag, which gives you more verbose information about the output.
Next, let’s try specifying what ports we want to check for instead of just doing a general scan.
nmap -sS -sV -v -p 22 yahoo.com
PORT STATE SERVICE VERSION 22/tcp filtered ssh
We can see that port 22 is filtered on Yahoo, which means we’d probably have a hard time attacking it. You can specify a range of ports by replacing -p 22 with something like -p 1-165535. The flag that I usually use is –top-ports 1000, which as the name implies, scans the most common 1000 ports.
Putting it all together, this is what I’ll usually run to get an overall look of the host:
nmap -sS -sV -O -v --top-ports 1000 yahoo.com
Here, we’re doing a sneaky scan (sS), version detection (sV), operating system detection (O), verbose output (v), and scanning the top 1000 ports.
Now you know the basics of port scanning with Nmap!
Scanning IP Ranges
Scanning IP ranges instead of a single host is useful if you’re testing on your own servers. I don’t recommend doing this on servers you don’t own, since you might miss and scan someone who’s not your target.
Nmap uses CIDR notation, so you can just run something like this:
nmap -sV --top-ports 1000 192.168.1.0/24
Nmap has five timing options, officially named: paranoid, sneaky, polite, normal, aggressive, insane. You can specify this with the T flag, e.g. -T0 for paranoid and -T5 for insane. By default, Nmap runs on “normal” mode, so -T3 does nothing. I’ll usually run my scans on -T4 if I know it won’t upset the client.
If you want to save Nmap’s results to a file for later, add the -oN filename flag. -oX filename outputs results in XML format, which is useful if you’ve got scripts that process Nmap output.
Nmap comes with some scripts you can enable! I don’t normally use them since I prefer other tools, but here’s a good guide explaining them.
The Fun Part: Exploitation
Now that we know what’s running on a host, we want to exploit it.
Attacking networks is an entire topic of its own, but I’ll cover some of the basics here!
Port 22: SSH
If the network has port 22 open and ssh running on it, that’s a good starting point. If you can successfully manage to log in through SSH, well… that’s a bad sign for the server.
First off, check the version of SSH that’s running (recall that you can do this with the -sV flag). Google that version and chuck in the keyword “exploit”. If it’s an older version of SSH, you have good chances of finding publicly available exploits that you can just copy and run.
If that doesn’t work, you still have a chance of getting a login. Go back to your terminal and run something like this:
“remote_username” can be any number of things, but the common names I’d check for are admin and root. Try some common passwords, and also try some company-specific things (does the network admin have a dog? kids? try their names). You can also try to run a bruteforce scan, but that’s out of the scope of this post.
SSH is a special case because of the severity of compromise possible if you get a login, but other services can be equally vulnerable.
Once you’ve run an Nmap scan with version detection enabled, see if anything other than just port 80 and 443 shows up. Google the name of any services you find and figure out what they do, and if any exploits are publicly available. You know how developers joke about ripping all their work off StackOverflow? Pentesters pretty much do the same but with CVE (Common Vulnerabilities and Exposures) databases.
Once you’ve run out of services to Google public exploits for, you can double back and check if any of the services have login portals. For example, if the service is webmail, you can try logging in to it with netcat by trying out default usernames and passwords for that service.
How do I fix my vulnerable server?
Check out these posts though: