Service Fingerprinting

What Service Fingerprinting Reveals

Service fingerprinting is the process of identifying the exact software, version, and configuration of services running on open ports. This information is critical because it transforms a generic "port 80 is open" into "Apache 2.4.41 with PHP 7.4 on Ubuntu" -- which directly maps to known vulnerabilities.

Banner Grabbing

Many services voluntarily announce their identity when you connect. This is called the banner. Banner grabbing reads this initial response to extract product name and version.

Netcat banner grabbing:

# Connect to an HTTP server and read the banner
nc -v target.example.com 80
HEAD / HTTP/1.0

# Response reveals:
# Server: Apache/2.4.41 (Ubuntu)

Telnet banner grabbing:

# Connect to any service
telnet target.example.com 22
# SSH responds: SSH-2.0-OpenSSH_8.0

Nmap banner grabbing:

# Nmap grabs banners during version detection
nmap -sV --script banner 192.168.1.1

HTTP Header Analysis

HTTP responses contain rich fingerprinting information in headers:

HTTP/1.1 200 OK
Server: nginx/1.18.0
X-Powered-By: PHP/7.4.3
X-AspNet-Version: 4.0.30319
Set-Cookie: JSESSIONID=...; Path=/; HttpOnly

Key headers for fingerprinting:

• Server -- Web server software and version
• X-Powered-By -- Backend language/framework
• X-AspNet-Version -- ASP.NET version
• Set-Cookie -- Session cookie name reveals framework (JSESSIONID = Java, PHPSESSID = PHP, ASP.NET_SessionId = ASP.NET)
• X-Generator -- CMS version (e.g., Drupal 8.9.1)

Analyzing Banner Information

Once you have a banner, extract the key details:

Server: Apache/2.4.41 (Ubuntu)

• Product: Apache
• Version: 2.4.41
• OS: Ubuntu

Cross-reference with vulnerability databases:

# Search for known vulnerabilities
searchsploit Apache 2.4.41

# Check CVE details
curl -s "https://cve.circl.lu/api/search/apache" | jq '.[] | select(.id | contains("2.4.41"))'

When Banners Are Hidden

Some administrators disable or modify banners to hide version information. When banners are unavailable, use:

• Behavioral analysis -- Different versions respond differently to malformed requests
• Error page analysis -- Error messages often reveal the technology stack
• File path analysis -- Default file paths differ between versions
• Response timing -- Different versions have different performance characteristics

When Version Strings Are Hidden

Modern security practices often strip version strings from banners and headers. When this happens, you need behavioral fingerprinting -- analyzing how the service responds to specific inputs to determine its version.

HTTP Behavioral Fingerprinting

Different web servers handle malformed requests differently:

# Test 1: Invalid HTTP method
curl -X INVALIDMETHOD http://target.example.com/
# Apache returns: 400 Bad Request
# nginx returns: 400 Bad Request (different body)
# IIS returns: 405 Method Not Allowed

# Test 2: Long URL
curl http://target.example.com/$(python3 -c "print('A'*10000)")
# Apache returns: 414 Request-URI Too Long
# nginx returns: 414 Request-URI Too Long (different body)

# Test 3: Invalid header
curl -H "X-Test: \x00\x01\x02" http://target.example.com/
# Different servers handle invalid characters differently

Error Page Fingerprinting

Trigger an error and analyze the response:

# Request a non-existent page
curl http://target.example.com/nonexistent-page-12345

# Analyze the 404 page for:
# - Server signature in footer
# - CSS/JS file paths (e.g., /wp-content/ = WordPress)
# - Technology-specific error messages

File Path Fingerprinting

Different technologies have characteristic file paths:

# WordPress
curl -s http://target.example.com/wp-login.php | grep "WordPress"

# phpMyAdmin
curl -s http://target.example.com/phpmyadmin/ | grep "phpMyAdmin"

# Jenkins
curl -s http://target.example.com:8080/ | grep "Jenkins"

# Apache Tomcat
curl -s http://target.example.com:8080/manager/html | grep "Tomcat"

TLS/SSL Fingerprinting

The TLS handshake reveals information about the server software:

# Analyze TLS certificate and handshake
openssl s_client -connect target.example.com:443 -servername target.example.com

# Check certificate for:
# - Issuer (Let's Encrypt, DigiCert, etc.)
# - Subject alternative names (reveals other domains)
# - TLS version and cipher suites (reveals server configuration)

Automated Fingerprinting Tools

WhatWeb -- Identifies web technologies:

whatweb -a 3 target.example.com
# Output: Apache 2.4.41, PHP 7.4.3, jQuery 3.5.1, WordPress 5.5.2

Wappalyzer -- Browser extension and CLI tool for technology detection:

wappalyzer https://target.example.com

BuiltWith -- Online service that profiles website technology:

curl -s "https://api.builtwith.com/v19/api.json?KEY=API_KEY&LOOKUP=target.example.com" | jq '.results[].result.paths[].technology'

Practical Example: Fingerprinting a Hidden Server

You scan a target and find port 443 open. The Server header is stripped. You:

1. Analyze TLS certificate -- Issued by Let's Encrypt, SAN includes target.example.com and api.target.example.com
2. Request non-existent page -- 404 page contains /assets/css/main.css (Rails convention)
3. Test HTTP methods -- OPTIONS returns Allow: GET, POST, PUT, DELETE, PATCH (REST API pattern)
4. Check for framework headers -- X-Runtime: 0.023456 (Ruby on Rails)
5. Conclusion -- Ruby on Rails application, likely using Puma or Unicorn as application server

This behavioral analysis gives you the technology stack even without version strings.

The Fingerprint-to-Exploit Pipeline

Service fingerprinting is not an end in itself -- it feeds directly into vulnerability assessment. The pipeline is:

Fingerprint -> Version Identification -> CVE Lookup -> Exploit Research -> Testing

Cross-Referencing with Vulnerability Databases

Once you have a product and version, search for known vulnerabilities:

Searchsploit -- Local exploit database:

searchsploit Apache 2.4.41
searchsploit OpenSSH 8.0
searchsploit "Microsoft IIS 10.0"

NVD (National Vulnerability Database) -- Comprehensive CVE database:

# Search NVD API
curl -s "https://services.nvd.nist.gov/rest/json/cves/1.0?keywordSearch=Apache+2.4.41" | jq '.result.CVE_Items[].cve.CVE_data_meta.ID'

Exploit-DB -- Public exploit repository:

# Search Exploit-DB
curl -s "https://www.exploit-db.com/search?q=Apache+2.4.41" | grep -oP 'exploit-db.com/exploits/\d+'

Vulnerability Scanners -- Automated tools that fingerprint and check for CVEs:

# Using Nmap NSE scripts
nmap -sV --script vuln 192.168.1.1

# Using Nikto for web servers
nikto -h target.example.com

Prioritizing by Exploitability

Not all vulnerabilities are equal. Prioritize based on:

1. Remote Code Execution (RCE) -- Highest priority; direct system compromise
2. Authentication Bypass -- High priority; grants access without credentials
3. SQL Injection -- High priority; data exfiltration and potential RCE
4. Information Disclosure -- Medium priority; aids further attacks
5. Denial of Service -- Lower priority; disruptive but not directly exploitable for access

Practical Example: Fingerprinting to Exploit

You fingerprint a target and find:

Product: OpenSSH
Version: 7.4

You search for vulnerabilities:

searchsploit OpenSSH 7.4

Results show:

• CVE-2017-15906 -- OpenSSH 7.4 username enumeration
• CVE-2018-15473 -- OpenSSH 7.4 user enumeration

You test CVE-2018-15473:

# Use Nmap NSE script to test
nmap -p 22 --script ssh-users-enum --script-args userdb=users.txt target.example.com

The script confirms the vulnerability and enumerates valid usernames. You now have a list of usernames for brute-force attacks.

Documenting Fingerprinting Results

For each discovered service, record:

Service: HTTP (port 80)
Product: Apache
Version: 2.4.41
OS: Ubuntu 20.04
Headers: Server: Apache/2.4.41, X-Powered-By: PHP/7.4.3
Known CVEs: CVE-2021-41773 (path traversal), CVE-2021-42013 (RCE)
Exploit Available: Yes (Metasploit module: multi/http/apache_normalize_path_rce)
Priority: High

This documentation becomes the foundation of your exploitation phase.