Nmap Cheatsheet
OS Detection
Use this Nmap reference while you build software engineering projects, review code, or refresh the syntax you reach for most.
How -O works
-O sends a fixed battery of probes and compares the responses against
nmap-os-db. It fingerprints the TCP/IP stack, not the software you can see,
so it reads a kernel rather than a banner.
sudo nmap -O 10.0.0.5 sudo nmap -O --osscan-guess 10.0.0.5 sudo nmap -A 10.0.0.5 # includes -O
Device type: general purpose Running: Linux 5.X|6.X OS CPE: cpe:/o:linux:linux_kernel:5 cpe:/o:linux:linux_kernel:6 OS details: Linux 5.0 - 6.2 Network Distance: 12 hops
OS detection needs root, and it needs at least one open and one closed port to have a full set of responses to compare. A host that is entirely filtered cannot be fingerprinted this way.
What the probes measure
The fingerprint is built from stack behaviours that vary between implementations and are not configurable by an administrator.
| Signal | What varies between stacks |
|---|---|
| TCP ISN sequence | how the initial sequence number is generated |
| IP ID sequence | incremental, random, or zero, per host or per destination |
| TCP options | which options, in what order, with what values |
| Window size | initial receive window advertised |
| TTL | initial hop limit, 64 on Linux, 128 on Windows, 255 on many appliances |
| Explicit congestion | how the stack answers ECN negotiation |
| Malformed probe handling | responses to odd flag combinations |
| ICMP echo replies | code, TOS, and payload echoing quirks |
The TTL signal is the one you can read by eye. A syn-ack ttl 64 in
--reason output suggests Linux or BSD, and ttl 128 suggests Windows, before
-O ever runs.
Options and accuracy
| Option | Effect |
|---|---|
-O | enable OS detection |
--osscan-limit | only fingerprint hosts with one open and one closed port, saves time on sweeps |
--osscan-guess / --fuzzy | print near matches instead of giving up |
--max-os-tries <n> | retry limit, default 5, lower it for speed |
sudo nmap -O --osscan-limit 10.0.0.0/24 # skip hopeless hosts sudo nmap -O --osscan-guess --max-os-tries 1 10.0.0.5 sudo nmap -O -v 10.0.0.5 # shows the aggressiveness detail
Accuracy degrades in predictable ways:
| Situation | Effect on the result |
|---|---|
| Only filtered ports | no closed port to compare, detection fails |
| Behind a NAT or load balancer | you fingerprint the middlebox, not the host |
| Behind a proxy or WAF | same, the answer describes the edge |
| Virtualized or container host | reports the host kernel, which is often correct but unexpected |
| Network appliance | frequently matches many candidates at low confidence |
| Only one hop of data available | nmap prints a guess percentage, treat it as a hint |
Reading confidence honestly
Nmap tells you how sure it is, and that qualifier is the important part.
Aggressive OS guesses: Linux 5.0 - 6.2 (95%), Linux 4.15 - 5.19 (92%) No exact OS matches for host (test conditions non-ideal).
| Output | Interpretation |
|---|---|
OS details: a single line | a confident exact match |
Aggressive OS guesses with percentages | no exact match, ranked candidates |
No exact OS matches plus a fingerprint block | unknown stack, submit it upstream |
Too many fingerprints match | the probes were not discriminating, usually filtering |
Never report an OS version as fact from -O alone. It is stack-level inference,
and a percentage below 100 means nmap is choosing between candidates. Corroborate
with -sV banners, smb-os-discovery, or an HTTP Server header.
Corroborating with NSE
Service-level evidence is often more precise than stack fingerprinting, because services frequently announce their platform outright.
sudo nmap -O -sV 10.0.0.5 # both layers at once sudo nmap -p 445 --script smb-os-discovery 10.0.0.5 # Windows version and domain sudo nmap -p 80,443 --script http-server-header 10.0.0.5 sudo nmap -p 22 --script ssh2-enum-algos 10.0.0.5 # distro hints from algorithms sudo nmap -sV --script banner -p- --open 10.0.0.5
smb-os-discovery on a Windows host typically returns the exact OS string, the
NetBIOS name, the domain, and the system time, which is far more actionable than
a stack guess.
IP ID sequence and why it appears here
-O reports the IP ID generation class as a side effect, and that line is what
tells you whether a host can serve as an idle-scan zombie.
sudo nmap -O -v 10.0.0.99 | grep -i 'IP ID'
IP ID Sequence Generation: Incremental
| Class | Meaning | Usable as an -sI zombie |
|---|---|---|
Incremental | one global counter, increments per packet | yes |
Broken little-endian incremental | counter with byte-order quirks | yes |
Randomized | per-destination or random | no |
All zeros | never set | no |
Modern Linux and Windows randomize per destination, so Incremental shows up
mainly on printers, embedded devices, and older appliances. That scarcity is why
the idle scan is a niche technique rather than a default.