Nmap’s HTTP scripts let you poke around web servers with a surprising amount of detail, revealing not just what’s running, but how it’s running and what vulnerabilities might be lurking.
Let’s see what that looks like in practice. Imagine you’ve scanned a server and found port 80 open. Instead of just knowing "HTTP," you want to know what’s really going on.
nmap -p 80 --script http-enum,http-headers,http-methods,http-title,http-vhosts -sV 192.168.1.100
This command tells Nmap to scan port 80, run a few specific HTTP scripts (http-enum for common directories and files, http-headers for server response headers, http-methods for allowed HTTP verbs, http-title for the HTML title, and http-vhosts for virtual hosts). The -sV flag tries to determine the service version, which often helps the scripts make better guesses.
Here’s a snippet of what you might see:
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
| http-headers:
| HTTP/1.1 200 OK
| Date: Tue, 26 Oct 2023 10:30:00 GMT
| Server: Apache/2.4.41 (Ubuntu)
| Last-Modified: Mon, 20 Oct 2023 15:00:00 GMT
| ETag: "1234567890abcdef"
| Accept-Ranges: bytes
| Content-Length: 1024
| Content-Type: text/html
|
| http-methods:
| Supported Methods: GET HEAD POST OPTIONS
| Potentially risky methods: TRACE
|
| http-title: Apache2 Ubuntu Default Page
|
| http-vhosts:
| / 192.168.1.100:80
|_ *:80: Apache2 Ubuntu Default Page
This output tells us a lot. We know it’s Apache 2.4.41 on Ubuntu. We see the standard headers, including the Server string which can sometimes reveal exploitable versions. http-methods shows TRACE is allowed, which is often a security concern. http-title confirms the default Apache page. http-vhosts indicates it’s serving a default page at the IP address, but also hints that other virtual hosts could be configured.
The real power comes from understanding how these scripts build a picture. http-enum is like a lightweight directory brute-forcer. It checks for common files and directories like /admin, /login.php, /robots.txt, /backup.zip to see if they return a 200 OK status. http-headers just fetches the raw HTTP response headers, which are packed with metadata. http-methods sends an OPTIONS request to see which HTTP verbs the server will accept for a given resource. http-title fetches the main HTML page and extracts the <title> tag. http-vhosts attempts to guess other hostnames that might be configured on the same IP address and port by sending requests with different Host headers.
You can chain these scripts, or use more specific ones. For example, http-enum can be given a custom wordlist to find less common files. http-vhosts can be combined with a list of potential domain names for more targeted guessing.
This isn’t just about finding a web server; it’s about understanding its configuration, its publicly exposed files, and potential misconfigurations. The Server header, for instance, is often a goldmine. If it reveals an older, known-vulnerable version of Apache, you know exactly where to look for exploits. The Allow header, often revealed by http-methods, can show that methods like PUT or DELETE are enabled, which could lead to unauthorized file modifications or deletions if not properly secured.
When Nmap runs an http-* script, it’s essentially simulating a web browser or a client making requests to the web server. For http-enum, it constructs URLs based on common patterns and sends GET requests. If the server responds with a 200 OK status code and the content isn’t a standard error page, the script flags it. For http-headers, it’s a simple HEAD request to get just the headers, which are much smaller than the full page content. http-vhosts is more sophisticated: it sends requests with different Host headers (like Host: example.com) and analyzes the response to see if it matches the default page or a unique one for that virtual host.
The http-enum script, by default, checks a predefined list of common web application paths. This list is hardcoded within the script but can be extended. The script sends a GET request for each path and analyzes the HTTP status code and response body. If it finds a path that returns a 200 OK status and its content is not a typical error page (like a 404 Not Found), it reports the path as found.
The http-vhosts script is particularly clever. It attempts to identify virtual hosts configured on the web server by sending requests with different Host headers. It starts by sending a request with no Host header or a generic Host header and then tries common domain names or IP addresses as the Host header. If the server’s response changes (e.g., different content, different Server header, or a redirect), it suggests that a virtual host might be present. It doesn’t necessarily know the real domain names, but it can identify that multiple configurations are being served from the same IP.
The http-title script is straightforward: it fetches the homepage and extracts the content of the <title> tag from the HTML. This is a quick way to identify the application or website name.
If you find that http-enum is missing specific files or directories you expect, you can provide your own wordlist using the --script-args option with the http-enum.files argument. For example:
nmap -p 80 --script http-enum --script-args http-enum.files=/path/to/your/custom/filelist.txt 192.168.1.100
The --script-args can also be used to control the http-vhosts script, for example, to specify a list of potential hostnames to test:
nmap -p 80 --script http-vhosts --script-args http-vhosts.domains=example.com,test.com 192.168.1.100
Understanding the output of these scripts is crucial. For instance, if http-methods reports TRACE as a supported method, it indicates a potential Cross-Site Tracing (XST) vulnerability. This method can be used to trick a browser into sending sensitive information, like session cookies, to a malicious site. The fact that TRACE is enabled means the server is willing to echo back whatever it receives in the request body, including potentially sensitive headers.
The next step after enumerating web services is often to look for specific vulnerabilities using more advanced Nmap scripts like http-vuln-* or to analyze the identified web application more deeply with specialized tools.