Banner Grabbing: Reading What Services Tell You About Themselves

There is a persistent myth that reconnaissance requires exotic exploits or expensive tooling. In practice, some of the most useful information an attacker or defender can gather comes from simply asking a service who it is and writing down the answer. Many network services, by design, introduce themselves the moment you connect. A mail server greets you. A web server stamps its name and version into every response header. An SSH daemon announces its protocol and software build before you have even authenticated. Collecting and interpreting those introductions is what we call banner grabbing, and it sits at the very front of nearly every serious assessment.

What a Banner Actually Is

A banner is the metadata a service volunteers about itself during the initial handshake or in response to a basic request. It typically includes the software name, a version string, and sometimes the underlying operating system, supported options, or a configuration hint. None of this is a vulnerability on its own. The problem is that version strings are the fastest possible route from “I see a service” to “I know exactly which published CVEs apply to it.” If a banner says Apache/2.4.29, an analyst can cross-reference that against known flaws in minutes. That is why banner grabbing is valuable to attackers building a target profile and equally valuable to defenders who want to know what their own network is quietly disclosing.

Banners exist because they were originally conveniences. Version information helps clients negotiate features and helps administrators debug. The security cost of that convenience is the whole subject of this article.

Active Versus Passive Collection

There are two fundamentally different ways to obtain this information, and the distinction matters because it determines how noisy and how legally sensitive the activity is.

• Active banner grabbing means you initiate a connection directly to the target and read what it sends back. It is fast and precise, but every probe touches the target and can appear in its logs and intrusion detection systems.
• Passive banner grabbing means you observe traffic without ever contacting the target yourself. You might sniff packets on a network you already have access to, or you might query a third party that has already done the scanning for you. It is stealthier but depends on data someone else collected, which may be stale.

Search engines like Shodan and Censys occupy an interesting middle ground. From your perspective the lookup is passive, because you are querying a database rather than the target, but that database was built by someone else actively scanning the entire internet and indexing the banners they found.

Doing It by Hand

The clearest way to understand banner grabbing is to perform it with tools that do nothing clever. A raw TCP connection is often enough.

# Talk to a web server and ask for its headers
curl -I http://example.com

# The Server: line in the response is the banner
# e.g. Server: nginx/1.18.0 (Ubuntu)

For non-HTTP services, netcat lets you open a socket and read whatever the service greets you with:

# Connect to an SSH service; it announces itself immediately
nc example.com 22
# Response: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5

# Connect to SMTP; the 220 greeting names the mail software
nc mail.example.com 25
# Response: 220 mail.example.com ESMTP Postfix

If encryption is in the way, as with HTTPS or SMTPS, plain netcat will only see ciphertext. You need a TLS-aware client:

# Complete the TLS handshake first, then read the banner
openssl s_client -connect example.com:443

The point of these examples is that a banner is not extracted through any trick. The service is simply designed to say hello, and you are listening.

Doing It at Scale

Manual probing does not scale to thousands of hosts, so scanners automate it. nmap is the standard choice, and its service and version detection is essentially industrialized banner grabbing combined with a large database of response fingerprints.

# -sV enables version detection across common ports
nmap -sV 192.0.2.0/24

# Push nmap to try harder on ambiguous services
nmap -sV --version-intensity 9 example.com

# The banner script grabs raw banners without deep probing
nmap -sV --script=banner example.com

nmap goes beyond reading a literal banner. When a service does not volunteer a clean version string, it sends a series of carefully chosen probes and matches the responses against known behavioral signatures, which lets it identify software that deliberately hides its name. For internet-wide reconnaissance, mass scanners such as zmap and masscan find live services quickly, after which a tool like nmap handles detailed fingerprinting.

Where the Interesting Banners Live

Certain ports are consistently worth checking because the services behind them are talkative and widely deployed. A short mental checklist covers most of the value:

• Port 21 (FTP) and port 25 (SMTP) — both greet clients with a welcome line that names the server software and version.
• Port 22 (SSH) — sends its protocol and implementation string before authentication.
• Ports 80 and 443 (HTTP/HTTPS) — the Server header, and sometimes X-Powered-By, reveal the web server and application framework.
• Ports 110 and 143 (POP3/IMAP) — mail retrieval services that announce their software on connect.
• Port 3306 (MySQL) and port 5432 (PostgreSQL) — database engines often leak version details in their handshake.
• Port 3389 (RDP) and port 23 (Telnet) — remote access services whose exposure alone is a red flag, banner or not.

The pattern is that legacy text-based protocols tend to be the chattiest, while modern services can often be configured to say very little.

Turning the Volume Down

Because banners hand out a roadmap for free, hardening against banner grabbing is about disclosing less without breaking functionality. You cannot stop someone from connecting to a public service, but you can control what that service admits.

• Suppress or genericize version strings. Most software supports this. In Apache, setting ServerTokens Prod and ServerSignature Off reduces the Server header to just Apache with no version. nginx offers server_tokens off;. Mail and SSH daemons have equivalent options to trim or replace their greeting text.
• Do not rely on it alone. Hiding a version is security through obscurity. It slows casual reconnaissance and defeats automated CVE-matching, but a determined attacker can still fingerprint software by its behavior. Treat banner suppression as one thin layer, never the fix.
• Reduce the attack surface. The banner you never expose is the safest one. Close unused ports, put management services like RDP and SSH behind a VPN, and firewall databases so they are unreachable from the public internet.
• Watch for the scanning itself. Active banner grabbing generates connection patterns that intrusion detection systems can flag: many ports touched in quick succession, malformed probes, or connections that open and immediately drop. Monitoring for that reconnaissance is often more valuable than trying to hide from it.
• Patch as if the banner were public. Since behavioral fingerprinting can defeat obfuscation anyway, the durable defense is simply not running vulnerable versions. If the software is current, an accurate banner tells an attacker far less.

The Takeaway

Banner grabbing endures because it is cheap, reliable, and built on cooperation from the target rather than any flaw in it. A service designed decades ago to be helpful will still, today, tell a stranger its exact version number. For anyone defending a network, the practical lesson is to periodically scan yourself the way an attacker would, using the same curl, netcat, and nmap commands, and ask a blunt question of every response: does this need to be visible, and would I be comfortable if an adversary read it? The goal is not to make your services silent, which is often impossible and always insufficient, but to ensure that what they do reveal points to patched, current software rather than a shopping list of known exploits.