Service & Version Enumeration · Offensive Security

From "a port is open" to "exactly what is running"

Port scanning answers a narrow question: is anything listening here? A result of "tcp/443 open" tells you a service is alive, but it does not tell you whether that service is a current, fully patched web server or a years-old build riddled with public exploits. Those two situations look identical at the port level and could not be more different to an attacker.

Version enumeration closes that gap. It moves you from "port 443 is open" to "this is Apache httpd 2.4.49" — from a fact about connectivity to a fact about software. And that second fact is the one that matters, because the version is what turns into a vulnerability lookup. A software name plus a precise version number is a search query you can run against a CVE database to learn exactly which published weaknesses apply.

This is the payoff of the phase. Everything before it — host discovery, port scanning — exists to deliver you to this point. The open ports are a list of doors; the service and version are the make and model of each lock. Identifying that make and model is the most valuable output the entire scanning and enumeration phase generates.

Lesson

02.03

Phase

Scanning & Enum

Primary tool

Nmap · NSE

Banner grabbing: read what the service announces

The simplest form of version enumeration is to ask the service directly and read what it tells you. Many services greet a new connection with a banner — a line or two of text that frequently includes the software name and version. You do not need a specialized tool to see it: connect with nc (netcat) or telnet, wait for the greeting, and read the response.

SSH answers with its protocol and software string the instant you connect — something like SSH-2.0-OpenSSH_7.2.
SMTP mail servers open with a 220 greeting that often names the mail software and host.
FTP servers print a 220 banner that commonly identifies the daemon and version.
HTTP does not greet you, but it answers a request with response headers — the Server: header regularly announces the web server software and version.

Banner grabbing is fast, requires almost nothing, and is often the quickest way to a first answer. But it is crude: not every service offers a banner, the banner may be incomplete, and — importantly — banners are trivially spoofed. An administrator can change the announced string to anything, so a banner that says "nginx" might be hiding something else entirely. Treat a banner as a lead, not a verdict.

Nmap version detection

Where banner grabbing reads whatever is offered, Nmap version detection goes looking. The -sV flag tells Nmap to open each discovered port and run a structured series of probes against it — sending specific bytes and watching how the service replies — then match those replies against a large fingerprint database. This identifies the service and version even when the banner is missing or lying, because the way software responds to probes is far harder to fake than a banner string.

You can tune how hard Nmap works at this. The --version-intensity option takes a value from 0 to 9: a low intensity sends only the most common, lightweight probes and finishes quickly; a high intensity sends rarer probes that catch unusual services at the cost of more traffic and time. Higher intensity means better coverage but a louder, slower scan.

Nmap can also reach below the application layer. OS fingerprinting with -O infers the target's operating system from subtle quirks in how its TCP/IP stack constructs packets — default window sizes, option ordering, and timing behaviors that differ between operating systems and even between versions of the same one. It is an inference, not a banner, so Nmap reports a confidence level rather than a certainty.

The aggressive shortcut. Typing every option gets tedious, so Nmap bundles the common enumeration set under -A: it runs version detection (-sV), OS fingerprinting (-O), the default scripts, and a traceroute in a single pass. It is the fast way to a rich picture of a host — and correspondingly noisy, so reserve it for targets where stealth is not the goal.

The Nmap Scripting Engine (NSE)

Version detection tells you what is running; the Nmap Scripting Engine tells you far more about it. NSE runs small programs — written in the Lua language and stored as .nse files under /usr/share/nmap/scripts — that go beyond identification to interrogate a service: pulling configuration details, enumerating shares and users, checking for specific weaknesses. Scripts are grouped into categories, and you choose which to run.

Category	Flag / example	What it does
Default	-sC / --script default	Runs the curated set of safe, broadly useful scripts. A sensible baseline that gathers common details on most services without being intrusive.
Discovery	--script smb-os-discovery	Reaches into a service to learn about the host and network around it — here, querying SMB to reveal the operating system, computer name, and domain.
Version / enumeration	--script http-enum	Enumerates specifics of an identified service — http-enum probes a web server for known directories, files, and applications worth a closer look.
Safe	--script safe	Scripts judged unlikely to crash a service, consume heavy resources, or be seen as an attack. The category to lean on when you must tread lightly.
Intrusive	--script intrusive	Scripts that may disrupt the target, generate significant traffic, or trip defenses. Powerful, but only inside an authorized scope.
Vuln	--script vuln	Actively checks a service against known vulnerabilities — for example, probing TLS endpoints for weak ciphers and known SSL flaws — and reports any matches it confirms.

The flexibility is the point: you can run one named script, an entire category, or a Boolean combination of them. But power cuts both ways. Several categories — intrusive and parts of vuln especially — actively poke at a target and can destabilize a fragile service or set off alarms. Mind your scope. A script that is fair game on an authorized target can be damaging and out of bounds anywhere else.

Why this is the pivot point

Here is where enumeration stops being a survey and becomes a lead. When a scan returns a line like Apache httpd 2.4.49 or OpenSSH 7.2, you are no longer holding a vague observation — you are holding a precise software-and-version pair. That pair is a direct query: you take that exact version to a vulnerability database and look up the known weaknesses published against it.

This is the moment the whole phase has been building toward. A specific version maps to specific, catalogued vulnerabilities — each with a CVE identifier and a severity score that tells you how serious it is and how easy it is to exploit. To read those identifiers and scores fluently, see CVE identifiers & CVSS scoring. Enumeration hands you the version; CVE and CVSS turn that version into a ranked list of opportunities.

The output feeds the next phase directly. Service and version enumeration is the bridge from "mapping the target" to "finding the way in." The version strings you collect here become the inputs to vulnerability analysis — the work of matching software to published flaws and deciding which are worth pursuing. Done well, this step writes most of the next phase's to-do list for you.

The best way to make this concrete is to build the scans yourself — choose the flags, set the intensity, pick the scripts, and watch how each choice changes what comes back. Practice that in the Nmap Scan Builder, then carry your version strings forward into vulnerability analysis.