Nmap scripts don’t just blindly run; they’re categorized to give you a sense of their potential impact and purpose.
Let’s see how this plays out with a real scan. Imagine you’re trying to understand the security posture of a new web server. You’d likely start with something like:
nmap -sV --script "safe" 192.168.1.100
This command tells Nmap to perform a version scan (-sV) and then execute only the scripts categorized as "safe" against the target 192.168.1.100. The output will show you information about services running on the host, and for each service, it will list the results of the "safe" scripts. For instance, you might see a script like http-title reporting the title of the webpage:
Nmap scan report for 192.168.1.100
Host is up (0.0020s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page
8080/tcp open http-proxy? Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Apache2 Ubuntu Default Page
The safe category is your go-to for reconnaissance that won’t disrupt services. These scripts are designed to gather information passively, like checking HTTP titles, banner grabbing, or identifying the operating system. They’re the equivalent of a quiet walk-through, observing everything without touching anything.
Then there’s the auth category. These scripts are designed to test or bypass authentication mechanisms. You’d use these when you suspect a service might have weak credentials or is vulnerable to certain authentication bypass techniques. Running them might look like:
nmap -p 22 --script "auth" 192.168.1.100
Here, we’re specifically targeting port 22 (SSH) and running auth scripts. A common script in this category is ssh-auth-methods, which attempts to identify supported authentication methods. If a script in this category succeeds, it means it found a way to authenticate or gather information related to authentication. This is where you start probing for weaknesses, like trying default passwords or identifying weak cipher suites.
The vuln category is for scripts that actively check for known vulnerabilities. This is your more aggressive testing phase. These scripts often attempt to exploit a vulnerability or, at the very least, identify its presence. A vuln scan might look like this:
nmap -p 443 --script "vuln" 192.168.1.100
This command scans port 443 (HTTPS) and runs scripts specifically designed to detect vulnerabilities. A script like ssl-heartbleed would attempt to detect the Heartbleed vulnerability. If a script reports a vulnerability, it’s a strong indicator that the service is susceptible and needs immediate attention. These scripts are the most likely to cause issues if run against a production system in a sensitive state, as some might trigger error conditions or even crash a vulnerable service.
A crucial aspect of Nmap scripting is the default category. When you run Nmap without explicitly specifying --script, it automatically runs a set of default scripts. These are considered a good balance between information gathering and minimal risk. The default category often includes a mix of safe scripts and some less intrusive discovery scripts.
The discovery category itself is for scripts that gather information about hosts and networks, like ping sweeps or service detection. They are generally safe but more active than purely passive scripts.
Finally, there’s the external category. These scripts interact with external services or resources, like checking for common misconfigurations that might expose information to the internet or performing brute-force attacks against online services. These are generally more intrusive and should be used with extreme caution, often requiring explicit permission.
The real power comes from combining these categories. You might run a safe scan first to get a broad overview, then a discovery scan to map out the network, and finally, targeted vuln scans on specific services you’ve identified as potentially risky.
What most people don’t realize is that the script.db file, located in Nmap’s installation directory, is the central repository for all script metadata, including their categories, dependencies, and descriptions. Modifying this file or understanding its structure is key to advanced script usage and even creating your own custom scripts.
The next logical step after understanding script categories is learning how to chain them together for more complex reconnaissance workflows.