TCP/IP Fingerprinting

Passive OS detection using fingerprinting technique TCP/IP protocols. Detection of OS has been the starting step for any cyber security service and it can be done either by passive finger printing or active fingerprinting.There are in built tools  like Nmap ,Zenmap,Ettercap,pOf in Kali Linux which can be used to detect the OS and much more info of the system.In this project we have implemented only passive OS finger printing technique 

TCP/IP stack signature methodology — from the SYN packet alone, we can reliably identify the client OS (Linux, Android, iOS, or Windows) based on TCP/IP header fields and option patterns. We have developed a python code(AI) that analyzes SYN packets from .pcap files or live captures to identify the client operating system and device type based on trained TCP/IP fingerprint models. By examining key fields such as TTL, window size, TCP options (MSS, WS, SACK, TSopt), and option ordering, the script passively predicts the OS with high accuracy. While tools like Wireshark, p0f, Satori, Ettercap, and Nmap also support fingerprinting, our approach simplifies OS detection using a reference table of SYN signatures, making it easy to visually identify whether a client is running Windows, Linux, Android, or other systems just by inspecting TCP/IP stack patterns. 

What Are TCP Options?

TCP Options extend the capabilities of the protocol—allowing for fine-tuned performance, congestion control, and timestamping.

They appear primarily in SYN and SYN-ACK packets, where both peers exchange their TCP stack capabilities.

Common TCP Options

Option Name	Kind	Description	Example Value
MSS (Maximum Segment Size)	2	Max data per TCP segment (based on MTU - 40)	1460
Window Scale (WS)	3	Multiplies TCP window size for high-speed networks	7 (×128)
SACK Permitted	4	Enables Selective Acknowledgment	N/A
Timestamp (TSval/TSecr)	8	Measures RTT, detects packet reordering	TSval=123456, TSecr=0
NOP (No Operation)	1	Padding between options for alignment	—
End of Options List (EOL)	0	Marks the end of TCP options	—

TCP Options in Action: The SYN Packet

When a TCP connection is established, the SYN packet carries TCP options that announce the sender’s capabilities.

Example (Wireshark-style):

Notes on option ordering & fingerprinting

·       The order of options (e.g., MSS,SACK,TS,WS) and precise values (MSS, WS shift, TS presence) are signature features — different OSes often send different orders and defaults (useful for passive fingerprinting).

·       The order of TCP options is the most reliable fingerprint attribute — OS TCP stacks almost never change their default order.

·       Default TTL, Window Size, and WS value combinations further narrow the match.

·       Combining these yields high-confidence passive OS identification even from a single SYN.

Where TCP Options Appear

Packet Type	Are TCP Options Present?	Typical Options Seen
SYN	Yes (almost always)	MSS, SACK Permitted, Timestamp, Window Scale, NOP
SYN-ACK	Yes	MSS, SACK Permitted, Timestamp, Window Scale, NOP
ACK (non-SYN)	Sometimes (rare)	Timestamp (TSval/TSecr), SACK Blocks
Data Packets	Sometimes	Timestamp, SACK
FIN / RST	Usually No	(TCP options rarely used here)

SYN and SYN-ACK packets

·       These are part of the TCP three-way handshake.

·       This is where both peers negotiate capabilities — MSS, Window Scale, SACK, Timestamp support, etc.

·       So most TCP options appear only here and are remembered for later use in the connection.

After the handshake

·       Only certain options continue to appear in subsequent packets:

o   Timestamps (TSval, TSecr) → appear in every data/ACK packet if negotiated.

o   SACK blocks → appear in ACKs only when selective ACKs are used to report missing segments.

·       Other options (like MSS, WS) do not reappear after the handshake — they were already negotiated.

FIN, RST packets

·       These packets usually have no options, because they only signal connection termination.

TCP Fingerprints vs TCP Options

Concept	What it is	Relationship
TCP Options	Extra metadata added in the TCP header (beyond the standard 20 bytes) to provide extended capabilities like scaling, timestamps, MSS, etc.	These are fields within TCP packets, particularly in the SYN phase.
TCP Fingerprint	A pattern or signature derived from how a specific OS or device sets its TCP header fields and TCP options.	TCP fingerprints are built from analyzing TCP options and other header fields.

So — TCP options are the raw data. TCP fingerprint is the unique pattern you extract from them.

TCP/IP Fingerprinting — The OS Signature

Each operating system implements TCP differently:

·       Linux may set MSS=1460, WS=7, SACK=Permitted, TS=Enabled

·       Windows might set MSS=1460, WS=8, TS=Enabled, SACK=Permitted, NOP padding

·       Android and iOS use slightly different timestamp increments and window scaling.

By analyzing:

·       TTL value

·       Initial window size

·       TCP option ordering

·       TCP timestamp increments

·       SYN packet size and alignment

We can create a unique TCP/IP fingerprint.

Example Comparison

OS	TTL	Window Size	WS	MSS	SACK	TS	Option Order	Typical Fingerprint
Windows 10	128	64240	8	1460	✔	✔	MSS, WS, SACK, TS, NOP, EOL	128:64240:8:1460:1:1
Linux 5.x	64	29200	7	1460	✔	✔	MSS, SACK, TS, WS, EOL	64:29200:7:1460:1:1
Android 13	64	65535	6	1460	✔	✔	MSS, WS, SACK, TS	64:65535:6:1460:1:1
iOS 17	64	65535	7	1460	✔	✔	MSS, WS, TS, SACK	64:65535:7:1460:1:1

Even if two devices share the same user-agent (e.g., both Chrome browsers), their TCP/IP stacks often differ—allowing passive OS detection without packet payloads.

 AI-Powered Fingerprint Analysis

  We’ve developed a Python-based AI model that:

• Parses SYN packets from .pcap or live network capture
• Extracts TCP header fields and options
• Compares against a trained reference table of known fingerprints
• Predicts OS and device type (Linux, Android, iOS, Windows, etc.)

This approach blends traditional fingerprint tables with machine learning, improving reliability even when middleboxes (e.g., NAT or proxies) modify packets slightly. 

Why TCP Fingerprinting Matters

• TCP options define how a host communicates — MSS, WS, TS, and SACK are key indicators. 
• TCP/IP fingerprinting uses these patterns to identify OS and device types without active probing.
• AI-driven analysis enhances reliability across NATed or proxied environments.
• Together, they form a powerful passive detection tool for network forensics, analytics, and security monitoring. 

Use Case	Benefit
Network Security	Identify unauthorized or spoofed clients
Threat Intelligence	Profile botnets and IoT devices
Incident Response	Match attack patterns to OS fingerprints
Performance Optimization	Tune congestion control per OS behavior
Passive Analytics	Detect device diversity in large networks

 TCP/IP Stack Fingerprint — SYN Packet Option Comparison

 

Python code to run zardaxt util to match with passive finger prints database :

import json
from zardaxt_utils import make_os_guess

# Step 1: Construct your fingerprint manually
test_fp = {
  "cap_len": 72,
  "dst_ip": "172.22.75.45",
  "dst_port": 443,
  "header_len": 72,
  "ip_checksum": 0,
  "ip_df": 0,
  "ip_hdr_length": 32,
  "ip_id": 0,
  "ip_mf": 0,
  "ip_off": 0,
  "ip_protocol": 6,
  "ip_tos": 0,
  "ip_total_length": 0,
  "ip_ttl": 0,
  "ip_version": 4,
  "src_ip": "192.168.8.3",
  "src_port": 42223,
  "tcp_ack": 0,
  "tcp_checksum": 28249,
  "tcp_flags": 2,
  "tcp_header_length": 32,
  "tcp_mss": 1360,
  "tcp_off": 8,
  "tcp_options": "M1360,N,N,N,W6,S,",
  "tcp_options_ordered": "MNNNWS",
  "tcp_seq": 1378243640,
  "tcp_timestamp": "",
  "tcp_timestamp_echo_reply": "",
  "tcp_urp": 0,
  "tcp_window_scaling": 6,
  "tcp_window_size": 62500
}

result = make_os_guess(test_fp)

# Step 2: Call Zardaxt's internal OS matcher
# Pretty-print full output
print("\n📌 Full TCP/IP Fingerprint Classification Result:\n")
print(json.dumps(result, indent=2, sort_keys=True)) 

 

Originating from Windows-based systems with a complete and healthy TCP option set, including M1380,N,W8,N,N,S :

✅ MSS
✅ Window Scale
✅ SACK Permitted
✅ Alignment NOPs
 

This confirms that the POS systems running Windows 10 are functioning as expected and using a modern TCP/IP stack consistent:

 

Passive fingerprinting from TCP/IP stack signatures for all incoming SYN packets in 3-way handshake :

 

 

Windows :

 

Linux : 

 

IOS/Android: 

  

TTL (# Hops Estimate Formula):

TTL=1. This behavior strongly resembles synthetic traffic (such as internal monitoring, TTL probing, or automated reachability tests). A TTL of 1 means the packet will expire after just one hop, so this is likely diagnostic or probing traffic.

However, TTL=1 is not normal for legitimate TCP traffic:

1. Linux: TTL ~64
2. Windows: TTL ~128
3. macOS: TTL ~64
4. Routers/Firewalls: TTL ~255

 

Synthetic monitoring tools like ThousandEyes, Pingdom, Nagios, or TCP-level health checks

Key Traits of the Negative Connections:

1. Window Size: tcp.window_size = 65330

1. (with WS=7, resulting in a scaled window of 8,357,440 bytes)
2. That’s a very large receive window, typically seen in modern kernels optimized for high-bandwidth or long-latency paths.
3. A base window size of 65330 with WS=7 is most likely generated by:

1. Linux 5.x kernels
2. Debian 12
3. Rocky Linux 9.3+
4. (Possibly Ubuntu 20.04+/RHEL 8+ if tuned)

2. MSS = 1380: Matches high-performance Ethernet/TCP/TLS configuration
3. TTL = 60: Indicates Linux OS
4. tcp.completeness == 23:

1. Only the 3-way handshake is observed — SYN → SYN-ACK → ACK — after which the client sends FIN,ACK almost immediately.

5. No TLS Client Hello or application payload is ever sent.

Most Likely Scenarios :

1. Synthetic monitoring tools like ThousandEyes, Pingdom, Nagios, or TCP-level health checks
2. Load balancer probes with no intent to exchange application data

Example 2 :

 Observation:

1. TTL = 126: Suggests Windows OS
2. Window Size = 8192
3. Window Scale = 8 (resulting in an effective receive window of 2,097,152 bytes)
4. MSS = 1338
5. tcp.completeness == 23:

1. All 1528 connections (initiated every hour) follow the 3-way handshake — SYN → SYN-ACK → ACK — but then terminate immediately with a FIN,ACK without exchanging any application data or TLS handshake.

Example 3 :

Client attempts SSL connection at regular intervals (e.g., every 1 second) and do not appear to be part of legitimate application traffic. Five bytes 0a 0a 0a 0a 0a = five ASCII line feeds (\n\n\n\n\n). This is application-level data of five LF characters, not a valid TLS record header — so it’s almost certainly an application probe/heartbeat or a tiny payload from a non-standard/misconfigured scanner/client rather than part of a normal TLS handshake. 

 

TTL = 254: Suggests Routers / Network Appliances - BSD derivatives (FreeBSD, NetBSD, OpenBSD), Solaris, HP-UX, or AIX, Cisco or Embedded router, Middleboxes, Firewalls

Window Size = 4128

Window Scale = No

MSS = 536 , TCP Options: Only 4 bytes observed - Minimal (only MSS), no SACK Permitted, no Timestamps

Summary : These connection attempts occur at regular intervals (e.g., every 1 second) and do not appear to be part of legitimate application traffic.

• Repeated small TCP sessions to 172.22.75.44:443 from 192.168.75.36 with 5 bytes of payload: 0a0a0a0a0a (ASCII LFs).
• 
• This payload is not a TLS handshake or valid application request — likely a probe/scanner/heartbeat or misconfigured client.
• 0x0A = ASCII LF (line feed, \n). Five repeats is just \n\n\n\n\n.
• Not a TLS/SSL handshake header (TLS record types start with bytes like 0x16, 0x14, 0x17, etc.).
• Not a normal HTTP request or response, nor a valid TLS ClientHello.
• Correlated fingerprints: TTL=254, MSS=536, Window=4128, minimal TCP options — indicates legacy/embedded or router/middlebox origin.
• TLS label but only 5 LFs means an attempt to contact port 443 without performing a proper TLS handshake — common for probes/scanners.