An Nmap NSE HTTP scan: eight probes, four device checks, no hits

This Nmap HTTP scan PCAP holds eight HTTP requests in under a quarter of a second, half of them signed "Nmap Scripting Engine" in the user agent. They ask a lab web server whether it is a VMware host, a Trane building controller or an HNAP router, and get a 404 every time. Where a port scan asks "what is listening", the Nmap Scripting Engine asks "what is it, and is it vulnerable". A-Packets rebuilds all eight requests with their responses, so the deliberate, path-by-path pattern of a scripted scan reads clearly against what an ordinary browser would do.

The NSE is what turns Nmap from a port scanner into a lightweight vulnerability scanner, and HTTP is one of its richest targets. Recognising its probes in a capture tells a defender not just that someone scanned, but what they were checking for, which is a sharper piece of intelligence than a port sweep gives.

Eight requests in the Nmap NSE HTTP scan

The requests do not browse; they interrogate. A-Packets lists each with its path, method and response, and read in order they are a checklist of HTTP scripts rather than a person clicking links.

Open the HTTP view →

Each path is a specific discovery check. GET / fetches the root so the scanner can read the server header and default page. A request for a long random path such as /nmaplowercheck… is deliberate: it is a path intended not to exist, sent so the script can learn how the server answers a missing page, which it then uses to tell real pages from not-found pages. POST /sdk probes for a VMware management interface, GET /evox/about for a Trane building-automation controller, and GET /HNAP1 for the HNAP device-management protocol that has carried router vulnerabilities. All four root requests received 200; /sdk, the random-path check, /evox/about and /HNAP1 each received 404. None of the device probes found its device.

The sizes make that plain. Every 200 is the same 45-byte root page and every 404 the same 196-byte error, so the four successes are one resource answered four times, not four products found. The random-path baseline matters here: some servers return their home page with status 200 for any path, a soft 404, and a script has to rule that out before trusting a hit. This server answers the baseline with a conventional 404, so the 404s on the device paths are genuine negatives. POST /sdk also carries a 441-byte body, the VMware API question itself, which an access log that records only the path would lose.

The user agent identifies itself as Nmap on the requests that carry one: Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html), naming the engine outright. The four root fetches carry no user agent at all, so a filter on that header catches half the activity; the behaviour, a burst of requests to fixed, unusual paths that no human would type, in a fraction of a second, catches all of it. The answers also arrive out of order, the responses to the third, fourth and fifth requests in frames 6, 8 and 7, which is why A-Packets pairs each request and response by its TCP stream rather than by position in the packet list.

What the probes were looking for

The paths cover VMware-style services, Trane controllers and HNAP devices. Nmap's discovery scripts try several device families against any HTTP server they meet, so the mix describes the script selection rather than a target the operator picked. The hnap-info and http-trane-info documentation describe information retrieval: these checks read what a management interface volunteers about itself, model, firmware and serial numbers, without exploiting a flaw, bypassing authentication or running commands.

That is still useful to an attacker, because a confirmed device model narrows the search for a working exploit to a page of advisories. This capture comes from the A-Packets lab, so the scan is authorized; in production, check an unknown source against the organisation's scan schedule before escalating, and record which endpoints were queried and what each one disclosed, since that is what the operator now knows.

How much further NSE can go

The probes in this capture query a small set of paths and read the responses: service discovery. But the Scripting Engine is a general tool, and its HTTP library backs scripts across the whole risk spectrum. The http-enum script walks a large list of common paths to inventory an application; http-title and http-headers fingerprint the server; http-sql-injection and http-stored-xss actively test for vulnerabilities; and the vulnerability-check category includes scripts that probe for specific CVEs. The same engine that sent these eight benign requests can, with a different script selection, launch something far more intrusive, and the traffic would look similar, a burst of scripted requests to chosen paths. That is why an NSE scan against a production service, even a discovery one, is worth treating as the reconnaissance stage of a potential attack rather than as harmless noise.

Reading paths, methods, bodies and responses together places a scan on that spectrum. A set of device-management paths like the ones here is enumeration; a set of injection payloads against a form parameter is active exploitation. The capture distinguishes them, because the paths and the request bodies are different, and a defender who reads them can describe exactly what was attempted and pick the right follow-up.

Detecting the scan and reducing what it learns

A single HTTP script scan is reconnaissance rather than a breach, but it is worth recognising and logging because it so often precedes something larger. The signals are the ones this capture shows: the Nmap user agent when present, and the burst of requests to unusual fixed paths in a time no human produces. In Wireshark, http.user_agent contains "Nmap" catches the labelled probes, and reviewing the full set of requested paths in a short window reveals the scripted pattern even when the user agent is changed. Repeated scans from one source deserve rate limiting or a block at the web server or a web application firewall.

The durable mitigation is to give the scan less to find. Make sure the server does not volunteer version banners, that management interfaces like the ones these probes seek are not reachable from untrusted networks, and that any embedded devices on the segment are patched and protected by proper authentication; renaming a default path is not an access control. A server that returns a terse 404 to the device-specific probes and sends no version header gives these scripts nothing to fingerprint. In MITRE ATT&CK terms this is T1595.002, Active Scanning by vulnerability scanning, usually leading to T1190 if a probe finds something exploitable.

This scan pairs with the SYN port scan and the ACK scan as the three faces of Nmap in a capture: find the open ports, map the firewall, then probe the service. For the investigator's view of reconnaissance in traffic, see using PCAP analysis for network forensics, or upload a capture of your own.