OS Fingerprinting with Xprobe2

You've mapped the network, discovered live hosts, and scanned open ports — but there's one giant question left: what operating system is running on that target? Knowing whether you're facing a Windows Server, a Linux distribution, or a network appliance changes everything about your reconnaissance. Blindly probing for vulnerabilities without OS identification is like trying to pick a lock without knowing the lock's brand. In this lesson, you'll learn to perform OS fingerprinting with Xprobe2, a specialized tool that uses ICMP-based probes to identify the remote operating system with surprising accuracy — and you'll do it in a safe, hands-on way.

The problem this lesson solves

Port scanning tells you which services are open, but services can be misleading. A web server on port 443 could be running on Linux, Windows, or a hardened router. Your exploit selection, your default credentials list, and even your social engineering pretext all depend on knowing the OS.

Guessing incorrectly wastes time and can trigger needless alerts. You might try a Linux-specific command injection and realize too late that your target is actually Windows Server 2019. OS fingerprinting eliminates that guesswork.

Tools like Nmap can perform fingerprinting, but they rely heavily on TCP behavior, which can be blocked by stateful firewalls. Xprobe2 takes a different route: it uses ICMP-based active OS fingerprinting, sending crafted ICMP packets and analyzing the responses (or lack thereof). This lesson addresses the specific gap that Xprobe2 fills and teaches you to use it as part of your reconnaissance toolkit.

Pro tip: OS fingerprinting is a passive-aggressive technique. It's active because you send packets, but the probes are often less intrusive than a full port scan, making them useful when you want to keep a low profile.

Core concept / mental model

Think of OS fingerprinting like a detective examining a suspect's sneeze. Different operating systems have different "sneezes" — small variations in how their TCP/IP stack responds to unusual or malformed packets.

Xprobe2 is a tool that canonically implements this idea. It sends a series of ICMP probes, each designed to trigger a specific behavior in the target's network stack. By measuring:

• Whether the target replies at all
• The time-to-live (TTL) value in the reply
• The IP ID generation pattern
• The ICMP error message type returned

...Xprobe2 builds a fingerprint and compares it against a database of known OS signatures.

A key mental model: Xprobe2 doesn't send one perfect probe; it sends a matrix of probes and analyzes the aggregate response. Each probe is a piece of evidence. Alone, a single probe might be ambiguous, but together they form a strong case.

Here's the rough workflow in words:

Target IP → Xprobe2 sends ICMP probes → Target responds (or doesn't) → Xprobe2 scores each match → Most likely OS(s)

How it works step by step

The process of performing OS fingerprinting with Xprobe2 can be broken down into these logical steps:

1. Identify a live target — Use ping or a prior Nmap scan to confirm the host is up and reachable.
2. Choose the appropriate interface — Xprobe2 needs to send raw packets, so you need root privileges and the correct network interface (e.g., eth0).
3. Launch Xprobe2 with the target IP — The tool will automatically run a set of default modules.
4. Interpret the output — The tool returns a ranked list of possible OSes with probabilities (via guess assignments).
5. Correlate with other information — Combine the result with Nmap's -O output and service banners to confirm your guess.

Xprobe2 uses a scoring system: each probe that matches a particular OS signature gives points to that OS. The output typically shows an average score and confidence. The higher the confidence, the more reliable the guess.

Pro tip: Xprobe2 is often used in conjunction with Nmap. Nmap gives a broad picture; Xprobe2 helps verify or challenge that picture, especially when ICMP is allowed but TCP port scans are filtered.

Hands-on walkthrough

Let's put theory into practice. Our lab environment will be a Kali Linux machine (attacker) targeting a Metasploitable 2 host at 192.168.1.105. You'll follow the same pattern for any authorized target.

1. Confirm the host is up

First, verify the target is live with a simple ICMP echo request:

ping -c 4 192.168.1.105

Expected output (abbreviated):

PING 192.168.1.105 (192.168.1.105) 56(84) bytes of data.
64 bytes from 192.168.1.105: icmp_seq=1 ttl=64 time=0.756 ms
...

If you get a reply, the target is alive and replies to ICMP — perfect for Xprobe2.

2. Run Xprobe2 with default modules

Now the main event. Run Xprobe2 with root privileges (it needs raw socket access). Specify the target IP directly:

sudo xprobe2 192.168.1.105

The output will look something like this (shortened for clarity):

[+] Target 192.168.1.105
[+] Starting Xprobe2 v0.3
[+] Loading modules.
[+] Load 135 signatures.
[+] Load 40 modules.
[+] Initializing scan engine.
[+] Running scan engine.
[+] Host 192.168.1.105:
[+] Final results:
[+] OS guess: Linux Kernel 2.6.24 - 2.6.28
[+] Score: 5/9 (55%)

Here we see Xprobe2 confidently reports the target as a Linux kernel 2.6.x — matching the Metasploitable 2 default (Ubuntu 8.04 with kernel 2.6.24).

3. Customizing the probe set

You can refine the fingerprint by specifying which modules to run. For example, to only use ICMP echo and timestamp probes, you would manually check the module list and use the -m flag:

sudo xprobe2 -m icmp_echo -m icmp_tstamp 192.168.1.105

But for most cases, the default run is effective and convenient.

4. Combining with Nmap for confirmation

To cross-verify, run Nmap's OS detection on the same target:

sudo nmap -O 192.168.1.105

Nmap output will provide its own guess (e.g., Linux 2.6.9 - 2.6.28), which corroborates Xprobe2's finding. When two independent methods agree, you can be confident in your OS identification.

Compare options / when to choose what

Xprobe2 is not the only player in the game. Here's how it stacks up against the most common alternatives:

When should you choose Xprobe2?

• When you want a dedicated ICMP-based check.
• When target firewalls drop TCP SYN packets but allow ICMP.
• When you need a second opinion after Nmap.

When should you skip it?

• If ICMP is blocked (you'll get no responses — see troubleshooting section).
• If you need service-level OS detection (use Nmap script -sV).
• If you're in a fully passive scenario (use p0f).

Troubleshooting & edge cases

Even with a solid tool, things can go wrong. Here's how to handle the most common issues.

1. "Permission denied" when starting Xprobe2

Xprobe2 needs root privileges to craft raw packets. Fix:

sudo xprobe2 192.168.1.105

2. No output or "Target seems down"

This usually means the target is not responding to ICMP. Check:

• Is the host really up? Use ping.
• Does a firewall block ICMP? Try Nmap's -P0 -sT to see if the host is alive on TCP.
• If ICMP is blocked, Xprobe2 will fail. Consider using Nmap's -O with -f or -S to spoof, but remember that those also need TCP.

3. Incorrect or ambiguous OS guess

Xprobe2 is not perfect. You might get Unknown or a low confidence score. This is common when:

• The target's OS is patched or tweaked (e.g., custom kernel, hardened TCP stack).
• Network appliances (routers/load balancers) often hide the real OS.

Fix: Run Nmap's OS detection, and if still ambiguous, consider banner grabbing on an open service (e.g., nc 192.168.1.105 22 to grab the SSH banner).

4. The tool is not installed

On Kali, Xprobe2 is often pre-installed. If not:

sudo apt update && sudo apt install -y xprobe2

5. My results differ from Nmap.

That's normal. Each tool uses different probes and heuristics. The correct approach is to treat multiple sources as evidence and look for convergence. If they disagree, dig deeper: inspect TTL values manually with ping, look at the initial TTL (e.g., 64 for Linux, 128 for Windows).

What you learned & what's next

This lesson walked you through the critical reconnaissance skill of performing OS fingerprinting with Xprobe2. You now understand:

• The role of ICMP-based active fingerprinting in the attack lifecycle.
• How Xprobe2 works: multiple probes, scoring, and comparison to a signature database.
• How to run Xprobe2 hands-on, confirm results with Nmap, and interpret the output.
• When to choose Xprobe2 over alternatives like Nmap, p0f, or banner grabbing.
• How to troubleshoot common pitfalls like permission errors, ICMP blocking, and ambiguous results.

With a target's operating system identified, you're ready to move to the next phase: service and vulnerability enumeration. In the next lesson, you'll take the OS information and map it to specific CVEs and exploits — turning your reconnaissance into a concrete attack plan. Armed with OS + open ports + services, you'll be able to select the right tool for the job.

Final pro tip: Always practice OS fingerprinting only on systems you own or have explicit permission to test, and combine your findings into a clear report — ethical hacking is as much about documentation as it is about exploitation.

Now go ahead and fire up your lab — pin down that OS, and you'll be one step closer to mastering the entire ethical hacking methodology.