Passive OS Fingerprinting

Fingerprint picture 1 by glennji

Network traffic from a computer can be analyzed to detect what operating system it is running. This is to a large extent due to differences in how the TCP/IP stack is implemented in various operating systems. We will in this blog post explain the different methods that can be used to identify what operating a computer is running by analyzing the packets it generates on the network.

Active approaches

The popular port scanner Nmap can identify the operating system (OS) of a remote computer by sending six packets with specially crafted option combinations in the TCP layer (for example window scale, NOP and EOL options). Nmap then watches how the scanned host responds to these odd packets. Fyodor (author of Nmap) gives a good overview of these techniques in issue 54 of phrack magazine from way back in 1998.

Passive OS identification

Active measures, like those employed by Nmap, are unfortunately not available when doing passive analysis of live traffic or when analyzing previously captured network traffic. Passive analysis requires much more subtle variations in the network traffic to be observed, in order to identify a computer's OS. A simple but effective passive method is to inspect the initial Time To Live (TTL) in the IP header and the TCP window size (the size of the receive window) of the first packet in a TCP session, i.e. the SYN or SYN+ACK packet.

Below are some typical initial TTL values and window sizes of common operating systems:

Operating System (OS)IP
Initial TTL
TCP
window size
Linux (kernel 2.4 and 2.6)645840
Google's customized Linux645720
FreeBSD6465535
Windows XP12865535
Windows 7, Vista and Server 20081288192
Cisco Router (IOS 12.4)2554128

One reason for why the TTL and window size values varies between different OS's is because the RFC's for TCP and IP do not require implementations to use any particular default value for these fields. There is, however, a recommendation in RFC 1700 saying:

The current recommended default time to live (TTL) for the Internet Protocol (IP) is 64
This recommendation is obviously not followed in many IP implementations.

The initial TTL value is often a bit tricky to analyze since the TTL value of a sniffed packet will vary depending on where you sniff it from. The sending host will set the TTL value to the OS's default TTL value, but this value will then be decremented by one for every router the packet passes on its way to the destination IP address. An observed IP packet with a TTL value of 57 can therefore be expected to be a packet with an initial TTL of 64 that has done 7 router hops before it was sniffed.

The TTL and window size table above can be used in order to do manual OS fingerprinting of network traffic. Here is an example showing how to display relevant fields of the first few packets from the publicly available pcap file for the 2009-M57-Patents scenario with tshark:

$ tshark -r day12-1.dmp -R "tcp.flags.syn eq 1" -T fields -e ip.src -e ip.ttl -e tcp.window_size -c 16 | sort -u
192.168.1.105  128  8192
192.168.1.106  128  65535
74.125.19.139  54   5720
87.106.12.47   45   5840
87.106.12.77   45   5840
87.106.13.61   45   5840
87.106.13.62   45   5840
87.106.1.47    45   5840
87.106.1.89    45   5840
87.106.66.233  45   5840

The first column here is the IP address (ip.src), the second is the TTL (ip.ttl) and the third the TCP window size (tcp.window_size). Note that the TTL value is only at the initial value for the hosts on the local network (192.168.1.0/24), while the packets from the other hosts seem to have performed 10 or 19 router hops. We can, just by matching the TTL and window sizes of these hosts with the table above, easily determine that 192.168.1.106 is running Windows XP (TTL=128, window_size=65535) and 192.168.1.105 is running some more modern flavor of Windows (TTL=128, window_size=8192). The google machine (with IP 74.125.19.139) can also easily be singled out due to its characteristic window size of 5720. The other machines (87.106.x.x) all seem to be running Linux.

Do you feel manual OS classification would take too much time? There are, luckily, multiple tools like ettercap, p0f, Satori and NetworkMiner which all automate the OS identification task. Just feed these tools with some live network traffic or a pcap file and they'll fingerprint the OS's for you.

DHCP Fingerprinting

An alternative to fingerprinting the TCP/IP stack implementation of an OS is to look at its DHCP implementation. Eric Kollmann (the creator of Satori) has written a great paper on DHCP fingerprinting titled Chatter on the Wire: A look at DHCP traffic. Eric's DHCP fingerprinting database is used in his tool Satori as well as in NetworkMiner.

There is also a project titled Fingerbank, which maintains another DHCP fingerprinting database.

Application Layer

Even more info about the operating system of a host can be extracted by inspecting the application layer data in traffic, such as server banners in HTTP, SSH and FTP as well as HTTP client User-Agent strings. All these layer 7 banner types are displayed in NetworkMiner's Hosts tab under the “Host Details” node.

NetworkMiner with OS identification results

A User-Agent string showing “Windows NT 5.1” (like in the screen shot above) means that the client is running Windows XP. Microsoft provides an article titled Understanding User-Agent Strings, which provides this mapping between User-Agent strings and operating system:

Platform tokenDescription
Windows NT 6.1Windows 7
Windows NT 6.0Windows Vista
Windows NT 5.2Windows Server 2003; Windows XP x64 Edition
Windows NT 5.1Windows XP

Happy fingerprinting!

Posted by Erik Hjelmvik on Saturday, 05 November 2011 14:45:00 (UTC/GMT)

Tags: #Satori#NetworkMiner

Short URL: https://netresec.com/?b=11B99BD

X / twitter

NETRESEC on X / Twitter: @netresec

Mastodon

NETRESEC on Mastodon: @netresec@infosec.exchange