ExamFinch.com My Study

Study guide

6.5 Passive OS & Service Fingerprinting

Practice this exam

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

6.5 Passive OS & Service Fingerprinting

Key Takeaways Explain This Topic AI

Default initial TTL values are 64 for most Linux and BSD, 128 for Microsoft Windows and 255 for Cisco IOS and legacy Solaris.

Passive fingerprinting infers the OS from the initial TTL, TCP window size, MSS, Don't Fragment bit and the order of TCP options, none of which requires sending a packet.

p0f is the reference passive fingerprinting tool and classifies both endpoints of every observed TCP handshake.

TLS client fingerprints such as JA3 and JA4 hash the ClientHello's version, cipher list, extension list and curve list into a single identifier.

NAT, load balancers, proxies and normalising firewalls rewrite the very fields passive fingerprinting relies on, so results describe the nearest device, not necessarily the real host.

Last updated: September 2026

6.5 Passive OS & Service Fingerprinting

Section 6.3 covered active fingerprinting: Nmap's -O sends crafted probes and compares responses against nmap-os-db . Syllabus item B8 names "active and passive techniques" , and the passive half is a distinct discipline with different tooling, different accuracy characteristics and — crucially — a completely different detection profile.

Passive fingerprinting sends nothing. The assessor observes traffic the target is already generating, from a network tap, a SPAN/mirror port, a compromised host on the segment or a captured PCAP, and derives identity from implementation details that every TCP/IP stack leaks by design.

1. Why Stacks Leak Their Identity

RFC 793 and RFC 1122 specify what TCP must do, but leave a great deal to the implementer: the initial TTL to stamp on outbound packets, the default receive window, whether to offer window scaling, the order in which options are placed in the header. Each vendor chose differently, kept those choices for backwards compatibility, and thereby created a durable signature.

The Primary Passive Signals

  • Signal Where it lives Why it discriminates
  • Initial TTL IPv4 header TTL / IPv6 Hop Limit Vendors picked different starting values
  • TCP window size TCP header Window field of the SYN Default receive buffer differs per stack and per link MTU
  • Maximum Segment Size (MSS) TCP option in the SYN Derived from the interface MTU; tunnels and PPPoE change it
  • Don't Fragment (DF) bit IPv4 flags Modern stacks set it for PMTUD; some legacy stacks do not

TCP options and their order TCP header options field e.g. MSS, SACK, Timestamp, NOP, WScale vs MSS, NOP, WScale, NOP, NOP, SACK

Window scale factor WScale option value Differs by stack and by autotuning policy

TCP timestamps TSval / TSecr Presence, and the clock tick rate, differ per OS; the value also reveals system uptime

IP ID generation IPv4 Identification field Sequential, randomised, or per-flow — the same property the idle scan exploits

Reading the TTL

Because each router hop decrements the TTL by one, the value you observe is the initial TTL minus the hop count . Round the observed value up to the nearest common initial value: Observed TTL 54 -> initial 64, ~10 hops away -> Linux / *BSD / macOS

  • Observed TTL 116 -> initial 128, ~12 hops away -> Microsoft Windows
  • Observed TTL 249 -> initial 255, ~6 hops away -> Cisco IOS / legacy Solaris
  • Initial TTL Typical systems
  • 64 Linux (all modern kernels), FreeBSD, OpenBSD, macOS, Android, most appliances
  • 128 Microsoft Windows (all supported versions)
  • 255 Cisco IOS, Juniper, legacy Solaris, many network appliances
  • 32 Very old Windows 95/98 and some embedded stacks

This single heuristic is remarkably robust and is worth knowing cold for the exam.

Combining Signals

TTL alone cannot separate Linux from FreeBSD. Combining fields does: SYN observed: TTL=64 Window=65535 MSS=1460 DF=1 Opts=[MSS,NOP,WScale,NOP,NOP,TS,SACK-OK]

  • | | | |
  • | | | +-- PMTUD in use (modern stack)
  • | | +---------- 1500-byte Ethernet MTU, no tunnel
  • | +----------------------- large default receive buffer
  • +--------------------------------- Unix-like family
  • => consistent with a recent FreeBSD or macOS host on plain Ethernet

Note what the MSS tells you independently of the OS: an MSS of 1460 implies a 1500-byte MTU (plain Ethernet); 1380 or 1360 implies a VPN or IPsec tunnel; 1452 implies PPPoE. That is topology intelligence, gathered passively.

2. Tooling

p0f — the reference implementation. It reads live traffic or a PCAP and classifies both ends of each TCP handshake against a signature database, reporting OS, distance in hops, uptime, link type and NAT suspicion. p0f -i eth0 -o /tmp/p0f.log # live capture

  • p0f -r capture.pcap # offline analysis of a PCAP .-[ 10.20.31.117/54122 -> 10.20.30.52/445 (syn) ]-
  • | client = 10.20.31.117/54122
  • | os = Windows 10 or Windows 11
  • | dist = 0
  • | params = none
  • | raw_sig = 4:128+0:0:1460:mss*44,8:mss,nop,ws,nop,nop,sok:df,id+:0
  • `----

Zeek (formerly Bro) — a network security monitor that logs software versions, TLS parameters and service banners it observes, producing software.log , ssl.log and conn.log for later mining.

NetworkMiner — a GUI forensic tool that reconstructs hosts, sessions, files and credentials from a PCAP and applies its own OS fingerprinting.

Satori — passive fingerprinting extended beyond TCP to DHCP, HTTP, CDP, SMB and more.

Wireshark — no automatic OS classification, but every field above is directly readable, and the display filters ip.ttl , tcp.window_size_value and tcp.options make manual analysis quick.

3. Passive Application and Service Fingerprinting

The same logic applies above the transport layer, and often yields more precise answers.

HTTP : Server: , X-Powered-By: and the order of response headers identify the server and framework. On the client side, the User-Agent: names the browser and platform, and the Accept-Language: header can indicate the user's locale.

DHCP fingerprinting : the Option 55 Parameter Request List — the specific set of options a client asks for, in the specific order it asks for them — is essentially a device signature. It is how NAC products distinguish a Windows laptop from an iPhone from a printer without any agent.

TLS fingerprinting (JA3 / JA4) : a client's ClientHello declares its supported TLS version, its cipher suite list, its extension list, its supported elliptic curves and its point formats. JA3 concatenates those five fields and takes an MD5 hash; JA4 is the modern successor with a more readable, more resistant format. Because the list contents and ordering come from the TLS library rather than from user configuration, a JA3/JA4 hash identifies the client stack — and therefore distinguishes a real browser from a Python requests script or a known malware family, even over encrypted traffic. The server-side equivalents are JA3S and JARM.

SMB, SNMP, CDP/LLDP and mDNS broadcasts: on a local segment these advertise hostnames, OS versions, switch models and device roles with no probing at all.

4. Active vs Passive: Choosing the Right Technique

  • Active ( nmap -O , -sV ) Passive ( p0f , Zeek, PCAP review)
  • Packets sent to target Many, some deliberately malformed None
  • Detection risk High — IDS signatures exist for OS probes Effectively zero from the target's perspective
  • Speed Seconds per host Requires waiting for the host to transmit
  • Coverage Any reachable host, including silent ones Only hosts that generate observable traffic
  • Accuracy High when an open and a closed port are available Good, but degraded by intermediaries
  • Prerequisite Network reachability to the target A capture point on the traffic path
  • Risk to target Small but real — malformed probes can crash fragile stacks None

Passive fingerprinting is the technique of choice in three situations the CPSA syllabus cares about: fragile environments (SCADA, medical devices, legacy mainframes) where probing risks an outage; stealth-constrained engagements where the Rules of Engagement require avoiding detection; and post-compromise work, where you have a foothold on a segment and want to map neighbours without generating scan traffic that would draw attention.

5. Limitations and How to Report Them

Passive fingerprinting describes the last device that wrote the fields you observed , which is not always the host you care about:

NAT rewrites addresses but usually preserves TTL and TCP options, so a p0f result showing several different operating systems behind a single IP address is strong evidence of NAT — which p0f explicitly reports.

Reverse proxies and load balancers terminate the client's TCP connection entirely. Fingerprinting the "web server" then fingerprints the load balancer, not the back-end. A mismatch between the passive result and an active -sV banner is itself a useful finding: it tells you there is an intermediary.

Normalising firewalls (OpenBSD pf scrub , many next-generation firewalls) deliberately rewrite TTL, clear the IP ID and reorder or strip TCP options specifically to defeat fingerprinting.

Containers and virtual machines share the host kernel's stack in some configurations, so every container on a Linux host fingerprints identically.

The signature databases age. A result of "Linux 3.11 and newer" means the observed signature has not changed since that kernel, not that the host runs a decade-old kernel.

For these reasons, record passive results as corroborating evidence with a stated confidence , never as the sole basis for a vulnerability claim. Where a finding depends on the operating system or version, confirm it with an active check, a service banner, or authenticated access, and say in the report which method established the fact.