Service and Version Detection Scans

You've mapped the network, pinged every live host, and even enumerated open ports on your targets. But there's a gap in your reconnaissance: a port can be open, yet the service running behind it might be a completely different application than expected — or worse, an outdated version riddled with known exploits. Running service and version detection scans is the reconnaissance step that transforms a bare port list into a detailed inventory of what your target is actually running, and it's the difference between blindly probing and knowing exactly which attack vector is worth pursuing.

In this lesson, you'll move beyond simple port discovery. You'll learn how to run service and version detection scans with Nmap and a few complementary tools, interpret the results, and handle edge cases like services behind proxies or firewalls. By the end, you'll have the skills to produce a precise target profile that feeds directly into vulnerability research and exploitation planning.

The Problem This Lesson Solves

Think about a typical Nmap port scan result:

PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
3306/tcp open  mysql

This tells you what port is open, but not what's really running. Is port 443 serving Apache, Nginx, or a custom Java app? Is port 3306 actually MySQL, or is it a MariaDB, or even a honeypot? Ports are just numbers; the same port can host dozens of different services. Without version detection, you're working with assumptions, and assumptions are dangerous in security.

The core problem: service identification based on port numbers alone is unreliable and insufficient for vulnerability assessment. A port might be open for a service that is misconfigured, outdated, or completely unexpected. For example, port 8080 might be a web proxy, not a web server. When you later search for exploits, you need to know the exact software and version — OpenSSH 7.2 has very different vulnerabilities than OpenSSH 8.9. If you scan with -p only, you'll never know the difference.

Version detection scans close this gap by actively probing the service to extract its banner, which usually includes the application name, version, and sometimes the OS. This is the first step toward targeted exploitation or hardening.

Core Concept / Mental Model

Imagine you're a security guard checking every room in a building. Port scanning tells you which doors are open. Service and version detection is like knocking on each door, asking "Who's there?" and receiving a name tag with the occupant's position and tenure.

The service fingerprinting process is a probe-and-response loop: the scanner sends a series of crafted network packets to the open port, each designed to trigger a characteristic response. The scanner compares that response against a database of known service signatures. This is similar to how antivirus software identifies malware — matches are scored and the highest-scoring candidate is reported.

Key definitions: - Service detection (often -sV): identifies the application listening on a port (e.g., http, ssh, smtp). - Version detection (also -sV): extracts the specific version string (e.g., OpenSSH 7.2p2 Ubuntu 4ubuntu2.10). - Banner grabbing: manually connecting and reading the initial welcome message sent by a service. It's the simplest form of version detection. - Fingerprinting: using multiple probes to determine the service type even when the service doesn't openly announce itself.

The mental model: treat every open port as an unknown service until proven otherwise. Your job is to ask the port enough questions (probes) to get a confident answer. The more probes you send, the higher the confidence, but the noisier the scan.

Nmap's version detection uses a database (nmap-service-probes) with hundreds of probe strings and matching rules. Each probe is a specific packet (e.g., an HTTP GET request, an SSH greeting, a TLS ClientHello). The response is matched against regex patterns to extract the software and version.

Let's visualize the process:

[Open port] -> [Send probe: 'HTTP GET /'] -> [Response: 'HTTP/1.1 200 OK\nServer: Apache/2.4.41'] -> [Match against signature DB] -> [Report: Apache 2.4.41]

This model explains why version detection is more resource-intensive than a simple ping or port scan — every probe consumes bandwidth and may trigger IDS alerts.

How It Works Step by Step

Service and version detection in Nmap follows a precise sequence that you should understand to interpret results and debug issues:

1. Port discovery (pre-scan): First, Nmap identifies open ports using a fast SYN or connect scan (-sS or -sT). Version detection is only performed on ports that are marked open — it won't probe filtered or closed ports.

2. Probe selection: For each open port, Nmap consults its service database (nmap-service-probes) to choose the most likely probes. This selection is based on the default service name for the port (e.g., port 80 uses HTTP probes, port 22 uses SSH probes).

3. Probe sending: Nmap sends each probe in sequence — starting with the most specific, like an HTTP request — and waits for a response. The default is to send up to 6 probes per port, but this is adjustable with --version-intensity 0-9 (default is 7).

4. Response analysis: The response is compared against the regex patterns in the database. A match extracts the service name, version, and other details. Each probe has a weighted score; the most probable match is selected.

5. Fallback probes: If no match is found, Nmap sends a broader set of 'null' probes (just a bare connection) and tries to read any banner the service sends unsolicited. This often catches services like SSH, which announce their version upon connection.

6. Result reporting: The final output includes the software name, version, and sometimes extra info like the OS or SSL/TLS library. You can control verbosity with -v to see each probe's result.

This six-step loop happens for every open port. The entire process is coordinated by Nmap, but you can also replicate it manually with tools like ncat or telnet for a specific port to confirm the version string.

A quick tip: always check the SERVICE/VERSION column in Nmap output — not just the SERVICE column from a plain port scan. The version string is the key that unlocks vulnerability research.

Hands-On Walkthrough

Let's put this into practice with a lab environment. Fire up a target VM or use a test server, and follow along.

1. Basic Service and Version Scan

Run a version detection scan against a target on ports 22, 80, and 443:

nmap -sV -p 22,80,443 192.168.1.10

Expected output (example):

Starting Nmap 7.94 ( https://nmap.org )
Nmap scan report for 192.168.1.10
Host is up (0.0011s latency).

PORT    STATE SERVICE VERSION
22/tcp  open  ssh     OpenSSH 7.2p2 Ubuntu 4ubuntu2.10 (Ubuntu Linux; protocol 2.0)
80/tcp  open  http    Apache httpd 2.4.18 ((Ubuntu))
443/tcp open  ssl/http Apache httpd 2.4.18 ((Ubuntu) OpenSSL/1.0.2g)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 12.45 seconds

Notice that for port 443, Nmap determined it's ssl/http — a web server using SSL. The version info includes the OpenSSL library version, which is critical for vulnerability checks.

2. Increase Probe Intensity

If Nmap's default probes don't yield a confident match, you can increase the intensity:

nmap -sV --version-intensity 9 -p 80 192.168.1.10

A higher intensity (0-9) sends more probes, improving accuracy but lengthening the scan. Use intensity 9 on stubborn ports, but be mindful of the traffic noise.

3. Manual Banner Grabbing

To confirm Nmap's result or to probe a service that Nmap misses, connect manually:

nc -nv 192.168.1.10 22

Expected output:

Connection to 192.168.1.10 22 port [tcp/*] succeeded!
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10

This confirms the SSH version. You can do the same for HTTP (send GET / HTTP/1.0 with nc) or for SMTP (send EHLO test.com). Manual banner grabbing is invaluable when Nmap's probes are filtered by firewalls or when the service uses a non-standard port.

4. Use NSE for Advanced Service Discovery

The banner NSE script performs a more thorough banner grab across many protocols:

nmap -sV --script banner -p 21,22,80 192.168.1.10

This adds a | banner: section for each port, showing the exact banner text, which might include more details like OS versions or server software.

5. Sweep Multiple Hosts

For a whole subnet, you can combine version detection with a fast port scan:

nmap -sV -T4 -p 80,443 --open 192.168.1.0/24

This scans the /24 subnet for web servers, runs version detection on any open 80/443, and only prints hosts with open ports, giving you a clean inventory.

Compare Options / When to Choose What

Not every scan needs full version detection. Here's a comparison to guide your choices:

General rule: Start with a fast port scan to find open ports, then run -sV on those specific ports to pull versions. Use aggressive intensity only on critical targets, and always follow up with manual banner grabbing for final confirmation.

Troubleshooting & Edge Cases

1. Nmap Shows 'unrecognized' or 'unknown'

If Nmap can't identify the service, it prints unrecognized. This often happens when the service is custom, proxied, or uses non-standard protocols. Fix: Try running nmap -sV --version-intensity 9 on that port, or use the NSE script banner and whois-domain to probe deeper. You can also manually connect with ncat to see if the service sends a banner.

2. Version Detection on Filtered Ports Fails

If a port is filtered by a firewall, Nmap can't perform version detection because the probes are dropped. Fix: Use a timing template like -T4 or -T5 to increase speed, but understand that filtered ports may remain invisible. Consider scanning from a different network segment or using an idle scan (-sI) as a workaround.

3. Service Behind a Proxy or Load Balancer

The version reported may be that of the proxy, not the backend service. For example, a load balancer might respond to HTTP probes with its own banner. Fix: Look for discrepancies in the output — like a Server header that mentions a reverse proxy. Cross-check by connecting directly to the backend IP if possible, or use curl -I to inspect headers.

4. Version String Too Short or Ambiguous

Sometimes a service only returns a minimal banner like 220 or 400. Fix: Increase probe intensity or use protocol-specific NSE scripts (e.g., http-title, smtp-commands) to extract more details.

5. False Positives in Service Matching

Nmap occasionally misidentifies a service — e.g., labeling a mod_wsgi Python app as Apache. Fix: Always double-check with a manual banner grab and search online for the exact version string to confirm.

6. Permission Issues

Running -sV using SYN scan (-sS) requires root privileges. If you get an error like Insufficient privileges for this scan type, use -sT (connect scan) or run with sudo.

Pro tip: Always run version detection scans against systems you own or have explicit permission to test. Unauthorized scanning is illegal in many jurisdictions and is a violation of ethical hacking principles.

What You Learned & What's Next

You've just transformed from a port scanner into a service investigator. Let's recap what you achieved:

• You can run service and version detection scans using nmap -sV, understanding that this is distinct from port scans.
• You can interpret the results — recognizing the software name, version number, and associated libraries like OpenSSL.
• You learned to apply version detection in practical scenarios, including intensity tuning and manual banner grabbing.
• You can troubleshoot common pitfalls like unfiltered ports, proxies, and ambiguous versions.
• You connected version detection to the bigger picture: knowing the exact version allows you to search for known vulnerabilities (e.g., in CVE databases) and plan exploitation or hardening.

This skill is a cornerstone of the Scanning & Enumeration phase of ethical hacking. In the next lesson, we'll explore vulnerability scanners like Nessus or OpenVAS, which automate the process of comparing version data against vulnerability databases — turning your service inventory into a prioritized risk list. You'll learn how these tools extend the version detection you've just mastered into automated vulnerability assessment.

Keep practicing: fire up your lab, scan a few diverse services (web, SSH, FTP, database), and challenge yourself to identify the version of each one manually. This practice will make service detection second nature — a skill you'll rely on in every engagement.