Banner Grabbing and Service Fingerprinting

A port tells you that something is listening. A banner often tells you exactly what. In this lesson you will learn how services introduce themselves, how to read those introductions carefully, and why trusting them blindly is a common beginner mistake.

This lesson closes the reconnaissance chapter by refining what the port scan told you, turning a vague "port 80 is open" into "this is probably this kind of web server, running roughly this version", a hypothesis you will carry into vulnerability analysis in the next chapter.

What a banner is

Many network services announce themselves when a connection is made, as a form of politeness inherited from early internet protocols. This announcement, the "banner", can include the software name, its version, the operating system, and sometimes extra configuration details. SSH, mail servers and many web servers are famous for sending such banners.

Grabbing a banner manually

You do not always need a specialised tool. A simple way to see a banner is to connect to a port and send a minimal request by hand, using a generic network client. On an SSH port, simply connecting is often enough to see the banner:

nc 192.168.56.21 22

For a web server, sending a minimal request shows the response headers, which often include a "Server" header naming the software:

printf 'HEAD / HTTP/1.0\r\n\r\n' | nc 192.168.56.21 80

These two commands use nc (netcat), a generic tool for reading and writing data over network connections, which makes it perfect for this kind of manual exploration.

Letting Nmap do the work

You already met the -sV flag in the previous lesson, which automates exactly this kind of probing across many ports at once, and adds a confidence level to its guesses. Nmap also has a scripting engine with scripts dedicated to extracting more detail from specific services, for example:

nmap -sV --script=banner 192.168.56.21

This script explicitly tries to collect and display the banner of each detected service, which is a convenient complement to the general -sV detection.

Why banners can mislead you

A banner is simply text sent by the service, and like any text, it can be wrong, outdated, or deliberately altered.

• Outdated information: an administrator may update the software but forget to update a custom welcome message.
• Deliberate hardening: some organisations configure their services to hide or change their banners precisely to slow down reconnaissance. A missing or generic banner is not proof of anything by itself.
• Honeypots: some organisations deploy decoy services designed to look like a juicy target and log every interaction with them. A banner that looks unusually inviting deserves a moment of suspicion, especially during a black box test of an unfamiliar target.

The professional habit is to treat every banner as a clue, not a conclusion, exactly as the brief for this course insists for any version information: speak of "likely running a recent version of X", never of a specific number you have not independently confirmed through at least one more method.

Cross-checking with behaviour

Beyond the banner itself, the way a service behaves can confirm or contradict it. For example, if a banner claims to be a very old mail server but it supports modern encrypted connections cleanly, something does not add up, and that inconsistency itself is worth a note. Comparing several independent signals is a core skill of the whole methodology, not just this lesson.

Documenting findings cleanly

By the end of reconnaissance, your notes for each host should read like a small table, which becomes the direct input to vulnerability analysis in the next chapter:

Host	Port	Likely service	Banner / evidence	Confidence
192.168.56.21	22	SSH server	Banner string observed, consistent across two methods	High
192.168.56.21	80	Web server	"Server" header present, generic value	Medium
192.168.56.22	3306	Database service (guessed from port only)	No banner captured, port filtered	Low

The "confidence" column matters: it tells the next phase, and later the client reading your report, exactly how much weight to put on each line. Confusing a low-confidence guess with a confirmed fact is a common and avoidable mistake.

Your fil rouge: fingerprinting Lighthouse Labs

For each open port found on your lab targets in the previous lesson, grab a banner manually with nc or automatically with Nmap's banner script, and fill in a table like the one above in your journal. Flag any banner that looks unusually detailed, unusually generic, or suspicious in any way, and write one sentence explaining your reasoning. This table is what you will hand to yourself, as the "next phase", at the start of chapter 3.

Your turn: evaluate two banners

Two scans of two unrelated lab machines return these results:

1. Machine A, port 21: banner reads exactly "FTP server ready", no version, no product name.
2. Machine B, port 21: banner reads a detailed string naming a specific FTP server product and an exact version number.

For each, say what you can and cannot conclude, and what you would do next.

See a solution

Machine A gives almost no information: you cannot identify the product, so the next step is to probe the service's actual behaviour (which commands it accepts, how it responds to certain requests) to build hypotheses some other way, since the banner alone is a dead end. Machine B looks more useful, but a precise version number is exactly the kind of detail to treat cautiously: it could be accurate, outdated, or a lure. The next step in both cases is the same discipline: cross-check with at least one other observation before writing anything as a confirmed fact in the vulnerability analysis phase.

Chapter 2 is complete: you now have a mapped, fingerprinted picture of Lighthouse Labs. Chapter 3 turns these clues into a prioritised list of likely vulnerabilities.