Home page logo
Intro Reference Guide Book Install Guide
Download Changelog Zenmap GUI Docs
Bug Reports OS Detection Propaganda Related Projects
In the Movies In the News


Nmap Network Scanning

Chapter 8. Remote OS Detection

Table of Contents

Reasons for OS Detection
Determining vulnerability of target hosts
Tailoring exploits
Network inventory and support
Detecting unauthorized and dangerous devices
Social engineering
Usage and Examples
TCP/IP Fingerprinting Methods Supported by Nmap
Probes Sent
Sequence generation (SEQ, OPS, WIN, and T1)
ICMP echo (IE)
TCP explicit congestion notification (ECN)
TCP (T2T7)
UDP (U1)
Response Tests
TCP ISN greatest common divisor (GCD)
TCP ISN counter rate (ISR)
TCP ISN sequence predictability index (SP)
IP ID sequence generation algorithm (TI, CI, II)
Shared IP ID sequence Boolean (SS)
TCP timestamp option algorithm (TS)
TCP options (O, O1–O6)
TCP initial window size (W, W1W6)
Responsiveness (R)
IP don't fragment bit (DF)
Don't fragment (ICMP) (DFI)
IP initial time-to-live (T)
IP initial time-to-live guess (TG)
Explicit congestion notification (CC)
TCP miscellaneous quirks (Q)
TCP sequence number (S)
TCP acknowledgment number (A)
TCP flags (F)
TCP RST data checksum (RD)
IP total length (IPL)
Unused port unreachable field nonzero (UN)
Returned probe IP total length value (RIPL)
Returned probe IP ID value (RID)
Integrity of returned probe IP checksum value (RIPCK)
Integrity of returned probe UDP checksum (RUCK)
Integrity of returned UDP data (RUD)
ICMP response code (CD)
IPv6 fingerprinting
Probes Sent
Sequence generation (S1S6)
ICMPv6 echo (IE1)
ICMPv6 echo (IE2)
Node Information Query (NI)
Neighbor Solicitation (NS)
UDP (U1)
TCP explicit congestion notification (TECN)
TCP (T2T7)
Feature extraction
List of all features
Differences from IPv4
Fingerprinting Methods Avoided by Nmap
Passive Fingerprinting
Exploit Chronology
Retransmission Times
IP Fragmentation
Open Port Patterns
Retired Tests
Understanding an Nmap Fingerprint
Decoding the Subject Fingerprint Format
Decoding the SCAN line of a subject fingerprint
Decoding the Reference Fingerprint Format
Free-form OS description (Fingerprint line)
Device and OS classification (Class lines)
CPE name (CPE lines)
Test expressions
IPv6 fingerprints
Device Types
OS Matching Algorithms
IPv4 matching
IPv6 matching
Dealing with Misidentified and Unidentified Hosts
When Nmap Guesses Wrong
When Nmap Fails to Find a Match and Prints a Fingerprint
Modifying the nmap-os-db Database Yourself


When exploring a network for security auditing or inventory/administration, you usually want to know more than the bare IP addresses of identified machines. Your reaction to discovering a printer may be very different than to finding a router, wireless access point, telephone PBX, game console, Windows desktop, or Unix server. Finer grained detection (such as distinguishing Mac OS X 10.4 from 10.3) is useful for determining vulnerability to specific flaws and for tailoring effective exploits for those vulnerabilities.

In part due to its value to attackers, many systems are tight-lipped about their exact nature and operating system configuration. Fortunately, Nmap includes a huge database of heuristics for identifying thousands of different systems based on how they respond to a selection of TCP/IP probes. Another system (part of version detection) interrogates open TCP or UDP ports to determine device type and OS details. Results of these two systems are reported independently so that you can identify combinations such as a Checkpoint firewall forwarding port 80 to a Windows IIS server.

While Nmap has supported OS detection since 1998, this chapter describes the 2nd generation system released in 2006.

Reasons for OS Detection

While some benefits of discovering the underlying OS and device types on a network are obvious, others are more obscure. This section lists the top reasons I hear for discovering this extra information.

Determining vulnerability of target hosts

It is sometimes very difficult to determine remotely whether an available service is susceptible or patched for a certain vulnerability. Even obtaining the application version number doesn't always help, since OS distributors often back-port security fixes without changing the version number. The surest way to verify that a vulnerability is real is to exploit it, but that risks crashing the service and can lead to wasted hours or even days of frustrating exploitation efforts if the service turns out to be patched.

OS detection can help reduce these false positives. For example, the Rwho daemon on unpatched Sun Solaris 7 through 9 may be remotely exploitable (Sun alert #57659). Remotely determining vulnerability is difficult, but you can rule it out by finding that a target system is running Solaris 10.

Taking this from the perspective of a systems administrator rather than a pen-tester, imagine you run a large Sun shop when alert #57659 comes out. Scan your whole network with OS detection to find machines which need patching before the bad guys do.

Tailoring exploits

Even after you discover a vulnerability in a target system, OS detection can be helpful in exploiting it. Buffer overflows, format-string exploits, and many other vulnerabilities often require custom-tailored shellcode with offsets and assembly payloads generated to match the target OS and hardware architecture. In some cases, you only get one try because the service crashes if you get the shellcode wrong. Use OS detection first or you may end up sending Linux shellcode to a FreeBSD server.

Network inventory and support

While it isn't as exciting as busting root through a specially crafted format string exploit, there are many administrative reasons to keep track of what is running on your network. Before you renew that IRIX support contract for another year, scan to see if anyone still uses such machines. An inventory can also be useful for IT budgeting and ensuring that all company equipment is accounted for.

Detecting unauthorized and dangerous devices

With the ubiquity of mobile devices and cheap commodity networking equipment, companies are increasingly finding that employees are extending their networks in undesirable ways. They may install a $20 wireless access point (WAP) in their cubicle without realizing (or caring) that they just opened up the protected corporate network to potential attackers in the parking lot or nearby buildings. WAPs can be so dangerous that Nmap has a special category for detecting them. Users may also cause sysadmins grief by connecting insecure and/or worm-infected laptops to the corporate network. Regular scanning can detect unauthorized devices for investigation and containment.

Social engineering

Another possible use is social engineering. Lets say that you are scanning a target company and Nmap reports a Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06. You could call up the target pretending to be Datavoice support and discuss some issues with their PRISM 3000. Tell them you are about to announce a big security hole, but are first providing the patch to valued customers. Some naive administrators might assume that only an authorized engineer from Datavoice would know so much about their CSU/DSU. Of course the patch you send them is a Trojan horse that gives you remote access to sniff and traipse through their network. Be sure to read the rest of this chapter for detection accuracy and verification advice before trying this. If you guess the target system wrong and they call the police, that will be an embarrassing story to tell your cellmates.

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]