Nmap Version Detection Rocks

Nmap's New Version Detection Feature

For years Nmap has been the go‑to tool for network reconnaissance, mapping ports and determining service types from simple banner grabs. Until version 3.45, the scanner could say a port was open and guess the common service that normally uses that port. That was useful, but many environments have evolved to hide services behind non‑standard ports or to use protocols in unconventional ways. The 3.45 release added the ability to probe an open port, query the service, and compare the response against a vast fingerprint database. The result is a precise identification of the protocol, product, and even sub‑version details whenever possible.

The new functionality is invoked with the -sV switch. For users who want a more aggressive scan that includes OS detection, traceroute, and version scanning, the -A option bundles everything. The scanner’s engine runs multiple probes in parallel, reducing the time required to fingerprint hundreds of ports. Each probe is designed to match the response pattern of a known service. When a match is found, Nmap stops testing that port further, thereby conserving bandwidth and avoiding unnecessary delays.

Behind the scenes, Nmap builds a fingerprint library from thousands of real service signatures. Each fingerprint records the exact strings that appear in banners, the timing of responses, and even subtle quirks like line endings. When the scanner contacts a host, it captures the first few packets and runs a scoring algorithm against the database. The highest‑scoring fingerprint is returned as the best match. If the response is ambiguous or does not match any known pattern, Nmap still reports the most probable service based on the port number, but it flags the result with a question mark to indicate uncertainty.

The feature was added after months of community feedback. Many security professionals needed a reliable way to verify that a host running an unexpected service was not an attacker’s foothold. Others wanted to confirm that their own non‑standard setups were correctly configured. Version detection has quickly become a standard part of both penetration tests and routine network inventory tasks.

To try it out, download the latest Nmap from the official site, run a scan against a target, and add -sV. Observe how the output now includes not just the port state but also the service and version string. For example:

These lines give a clear snapshot of what is running, allowing immediate action. If the service appears to be something you did not expect - say an SSH server on port 80 - security teams can investigate potential misconfigurations or rogue services.

Version detection also interacts gracefully with SSL/TLS. When the initial probe detects that a port responds to a TLS handshake, Nmap restarts the fingerprinting process inside the encrypted channel. That means it can reveal an HTTPS service running on a non‑standard port or a POP3 server wrapped in SSL on a port that normally carries another protocol.

Because the scanner opens real TCP connections to each target, version detection does not work in stealth mode. If a network has intrusion detection systems that flag SYN packets, the scanner’s three‑way handshake will trigger alerts. For low‑profile operations, use -sV in conjunction with -Pn (skip host discovery) and -T5 (aggressive timing), but be aware that the scan will be more visible.

As you run version scans, you may encounter fingerprints that the database does not yet recognize. Nmap encourages community contribution: if you discover a new service or a variant that the scanner fails to match, submit the fingerprint to the official repository. This collaborative approach keeps the database current and expands the tool’s reach across ever‑changing software landscapes.

The Practical Value of Discovering Non‑Standard Services

Many organizations intentionally move services away from their default ports. The most common reason is to reduce the surface area that automated scanners target. An SSH server on port 22 is a known target; placing it on 27011 can keep it out of a basic scan. However, this approach is not foolproof. Attackers can scan the entire TCP space, and security teams rely on comprehensive tools like Nmap to verify that all ports are accounted for. Version detection bridges this gap by telling you exactly what is listening on a given port, regardless of its number.

Firewall evasion is another use case. Some corporate networks restrict outbound traffic to specific ports to prevent data exfiltration. By running a service that accepts the allowed protocol on a different port, administrators can keep the functionality while staying within policy constraints. For example, an internal SMTP server that needs to connect to external mail providers might be placed on port 80, which is commonly allowed through firewalls, rather than port 25. Nmap’s ability to fingerprint services lets you confirm that such workarounds are correctly implemented and that the service is truly running as intended.

The value extends to incident response. When an unexpected service appears on a host, investigators need to know whether it is a legitimate application or a foothold for malicious activity. With version detection, you can immediately see whether a pop3 server on port 8888 is an open‑source solution or a custom backdoor. This clarity speeds up triage and reduces the risk of misdiagnosis.

Moreover, some services deliberately masquerade as others to evade detection. A web server might present itself with an HTTP banner even though it is actually an application server. Nmap’s fingerprinting process goes beyond the banner, checking response patterns, HTTP headers, and even the presence of certain SSL extensions. That level of depth makes it hard for a malicious actor to fool the scanner without being noticed.

Version detection also assists in compliance audits. Many standards require that software be kept up to date and that vulnerabilities be mitigated promptly. By automating the collection of service versions, auditors can quickly identify out‑of‑date or unsupported software on the network. Instead of manually logging into each host, a single Nmap run can generate a comprehensive report that can be cross‑referenced against a vulnerability database.

In environments that host a mixture of legacy and modern systems, version detection becomes essential for risk prioritization. A server running an obsolete FTP daemon is a higher risk than one with the latest HTTP stack. Nmap’s output lets you see the exact product and version, so you can apply patches where they matter most.

Because the process is fast and scalable, it can be integrated into continuous monitoring pipelines. A nightly Nmap run that includes -sV can produce a version inventory that is then fed into a SIEM or ticketing system. Any changes in software versions trigger alerts, ensuring that newly installed or upgraded services are immediately verified.

How Nmap Probes Services and Builds Fingerprints

Nmap’s version detection engine is built around a set of probes that target different layers of the TCP stack. The first probe is a simple SYN handshake that captures the initial SYN/ACK response. Many services reveal themselves through the timing of this packet or the presence of specific flags. For example, an SSH server will respond quickly with a standard banner, while a MySQL service may return a slightly delayed response.

Once the handshake is successful, Nmap sends a suite of payloads designed to elicit distinctive responses. For HTTP, it sends a GET / request and records the status line and headers. For SMTP, it sends EHLO and examines the multi‑line banner. For proprietary protocols, the probes include version requests or other standard commands that the protocol defines. The responses are captured verbatim, including line endings and whitespace.

The fingerprint database contains a vast collection of these captured responses, each labeled with the protocol, product, and version. When a new response is compared against the database, the engine assigns a score based on how many fields match. If a unique fingerprint exists, Nmap reports it directly. If the response is a close match, it may return a probable product but flag the result as less certain.

To keep the database current, contributors submit new fingerprints using an online form. Each submission includes the raw response data, a description of the service, and a test environment. The maintainers validate the entry by running the same probes against a fresh instance and verifying that the fingerprint consistently matches. This process has grown the database to cover over ten thousand distinct service signatures.

SSL support is integrated seamlessly. When the initial SYN/ACK indicates that the port is expecting a TLS handshake - usually through the presence of a ClientHello packet - Nmap automatically initiates a TLS session. Inside the encrypted channel, it runs the same series of probes as it would for a cleartext service. The resulting fingerprint can include SSL/TLS extensions, cipher suites, and certificate details. That means you can identify a secure HTTPS service on port 80 or a POP3S server on a non‑standard port without having to manually test for SSL.

Because Nmap can handle multiple protocols on the same port, the scanner is not limited to a single service per port. For instance, a server may present an HTTP banner first and then switch to a WebSocket protocol. Nmap will detect the primary protocol and then check for additional layers if the initial fingerprint matches certain criteria. This layered approach reduces false positives and provides a more accurate depiction of what is actually running.

In terms of performance, the engine employs parallelism at two levels. First, it scans multiple hosts simultaneously, limited by the -T timing template. Second, within each host, it runs probes for all open ports concurrently. This two‑tier parallelism allows a scan of 100 hosts with 200 open ports each to finish in under ten minutes, even when version detection is enabled.

For security analysts, understanding this process helps in interpreting scan results. A service that reports an older version may still be vulnerable, but the scanner might be using a fallback test that only retrieves a partial banner. In such cases, cross‑checking with a dedicated client or a different scanner can confirm the true version. Nevertheless, Nmap’s default fingerprinting is reliable for the vast majority of cases.

Reading and Acting on Version Scan Results

When you run nmap -sV -A target, the output is organized in a table with columns for port, state, service, and version. Each row is a distinct endpoint on the target machine. The “state” column indicates whether the port is open, closed, or filtered. The “service” column is either a known protocol name or the default port name with a question mark if the service could not be definitively identified.

For example, a line that reads:

means that Nmap could not confirm that an FTP server is running on port 21. The question mark indicates uncertainty. You might still have an FTP service, but the banner was ambiguous or absent. In that case, you can run a targeted scan against the port, such as:

to probe further.

When the version string is complete, like:

you immediately know the exact product and patch level. That information is crucial for vulnerability assessment. A quick lookup in the National Vulnerability Database (NVD) will reveal known CVEs affecting OpenSSH 8.4p1. If the host is running a vulnerable version, you can prioritize patching.

Some entries will show additional modules or extensions. For instance:

Here Nmap reports not only the main server but also the SSL and gzip modules. Those details help security teams understand the server’s capabilities and potential attack surfaces.

When Nmap reports an SSL wrapper without identifying the underlying service, like:

you can use the --script ssl-enum-ciphers script to explore the cipher suites, and a simple openssl s_client -connect target:8888 command to manually retrieve the server’s certificate and banner. If the server is running a simple echo service over SSL, as in the example where the service was a stunnel wrapper, the banner might read:

Those insights allow you to identify the true nature of the service, even if Nmap’s default database cannot match it yet.

Because the database is community‑driven, you may encounter fingerprints that have not yet been submitted. In that scenario, you can create a new fingerprint entry. The Nmap website provides a submission form where you paste the raw banner and describe the product. Once approved, the new fingerprint will be available for future scans, improving the tool’s accuracy for everyone.

Version detection is also useful when verifying that security controls are in place. Suppose you have configured a firewall to block all outbound SMTP traffic except through port 443. If an internal server mistakenly opens an SMTP service on port 25, a version scan will reveal it, allowing you to fix the configuration before an attacker can exploit it.

Finally, remember that the scan itself creates a TCP handshake on every port it tests. That handshake can be detected by IDS/IPS systems, so plan your scans accordingly. If you need stealth, run a limited port scan first to discover open ports, then perform a targeted version scan on those ports only. This two‑step approach reduces the number of connections and keeps the scan low profile while still gathering critical version data.