6.1 OS Fingerprinting, Service Discovery, and Host Discovery
Key Takeaways
- PT0-003 objective 2.2 is enumeration: after reconnaissance shows something exists, you inventory what exactly is on the host or service.
- Host discovery asks which in-scope addresses are alive, using ICMP, ARP, or limited TCP/UDP probes — not a full version scan of the CIDR.
- Service discovery inventories open ports and products, such as SMB on TCP 445 and RDP on TCP 3389.
- OS fingerprinting infers the guest OS from TTL, TCP window size, and TCP option stacks; an open SMB port is not an OS fingerprint because Samba runs on Linux.
- Protocol enumeration records how a discovered service is configured, such as SMB dialects and whether signing is required.
Enumeration on CompTIA PenTest+ PT0-003 starts after reconnaissance has shown that something exists. Objective 2.2 — Given a scenario, apply enumeration techniques — sits in Domain 2 (Reconnaissance and Enumeration, 21 percent of the exam). Objective 2.1 is information gathering: open-source intelligence, DNS lookups, sniffing, and banner grabbing. Objective 2.2 is the inventory of what exactly is on this host or service. Exam writers mix four techniques that are not synonyms: host discovery, service discovery, operating system (OS) fingerprinting, and protocol enumeration. If you pick an OS guess when the stem only asked which addresses are alive, you missed the item.
Host discovery: which addresses are alive?
Host discovery answers a binary question for each in-scope address: is anything there? Typical probes include Internet Control Message Protocol (ICMP) echo requests, Address Resolution Protocol (ARP) on a local Ethernet or Wi-Fi segment, Transmission Control Protocol (TCP) SYN or ACK packets to a short list of common ports, and User Datagram Protocol (UDP) probes to ports that usually elicit a response. A host that replies, sends a TCP reset, or otherwise proves presence is live. A host that stays silent is not proven absent. Host-based firewalls, ICMP filters, cloud security groups, and network address translation can hide a system that still serves a single allowed port.
Exam trap: treating a full version scan of every address in a Classless Inter-Domain Routing (CIDR) block as "discovery." Version detection is service discovery — and often OS fingerprinting — at warehouse scale. Another trap: believing an ICMP-only "down" result authorizes you to skip the host. Rules of engagement may require a TCP host-discovery pass when ICMP is filtered, especially on Internet-facing cloud ranges.
On an internal virtual LAN, ARP is often more honest than ICMP because you see Layer-2 replies even when ICMP is dropped. On the public Internet, ICMP is frequently blocked, so testers use TCP probes to ports such as 80, 443, 22, or 445 as the discovery channel. Record which method produced the live set. Later Domain 3 items on scan completeness will ask whether you missed hosts because discovery was too timid.
Service discovery: which ports and products?
Service discovery starts after you have a live host, or when the statement of work already named one. It inventories open ports and the listening products: TCP 445 with Server Message Block (SMB), TCP 3389 with Remote Desktop Protocol (RDP), TCP 22 with Secure Shell (SSH), UDP 161 with Simple Network Management Protocol (SNMP), TCP 389 or 636 with Lightweight Directory Access Protocol (LDAP). Banners, handshake bytes, and default ports are clues, not conclusions. A listener on 8443 might be a web administration console, a reverse proxy, or a development application programming interface (API).
Service discovery is still inventory. You are listing what is exposed. You are not yet walking shares, dumping users, or exploiting a banner version. Conceptually this is the Nmap port-scan and service-detection stage; objective 2.4 is where you pick Nmap Scripting Engine (NSE) scripts by name. On the exam, "which ports are open?" is service discovery even if the same screenshot also prints an OS guess.
OS fingerprinting: which guest operating system?
OS fingerprinting infers the guest operating system from how the TCP/IP stack behaves. Active fingerprinting sends crafted probes and compares time-to-live (TTL) values, TCP window sizes, TCP option order, Don't Fragment bits, and ICMP error formats to a signature database. Passive fingerprinting watches traffic you are already allowed to see — useful when the rules of engagement limit noisy probes. A result such as "Windows Server 2019" or "Linux 5.x" is a hypothesis. Virtualization, stack hardening, load balancers, and intentional OS-spoof settings produce confident-looking wrong answers.
Exam trap: a port is not an OS
A TTL "near 128" is not proof you may skip Linux-only checks. An open SMB port is not OS fingerprinting by itself: Samba on Linux speaks SMB. RDP on 3389 usually indicates a Windows-family host, but it can be a jump box, a virtual desktop gateway, or a third-party RDP service. Treat the OS label as a pointer to which protocol details to enumerate next, not as a finding you would ship without corroboration.
Protocol enumeration: how does this instance speak?
Protocol enumeration is the 2.2 bullet exam writers hide inside "what should the tester do next?" After you know SMB is on 445, you enumerate dialects, whether signing is required, whether guest or null sessions are accepted, and which SMB features are advertised. After HTTP is confirmed on 443, you enumerate methods, security headers, Transport Layer Security (TLS) versions, and authentication schemes. After SNMP is confirmed, you enumerate community strings and management information base (MIB) access if the RoE allows. Protocol enumeration is not host discovery (you already have the host) and not merely service discovery (you already know the port). It is the configuration and feature set of that protocol on that host.
Worked example: 445 and 3389
Host discovery marks 10.4.12.8 live. Service discovery shows TCP 445 and TCP 3389 open. OS fingerprinting reports Windows Server 2019. Protocol enumeration against SMB shows signing is not required. Those four facts are four different objective 2.2 techniques, not one "Nmap result." Together they start an attack path you will keep mapping in the rest of this chapter: a Windows file server that still talks unsigned SMB and also offers RDP. Do not jump to exploitation. Write the inventory first.
| Technique | Question it answers | Typical evidence | Not the same as |
|---|---|---|---|
| Host discovery | Which addresses are alive? | ICMP, ARP, or limited TCP replies from 10.4.12.8 | A version scan of every port on the CIDR |
| Service discovery | Which ports and products? | 445/tcp SMB, 3389/tcp RDP | Guessing Windows from a TTL alone |
| OS fingerprinting | Which OS family and version? | TTL, window, TCP options → Server 2019 | Listing SMB shares |
| Protocol enumeration | How is this service configured? | SMB dialects; signing not required | Proving the host is up |
Sequence on the exam: discover the host, discover the services, fingerprint the OS, then enumerate protocol details. Skipping ahead looks like efficiency and is usually the distractor.
A tester is authorized against 10.4.0.0/16 and wants to know which addresses are alive before spending time on version detection or OS signatures. Which action is host discovery?
Host discovery shows 10.4.12.8 is alive, and service discovery shows 445/tcp and 3389/tcp open. The tester next wants the guest operating system. Which activity is OS fingerprinting?
Nmap-style service discovery already showed 445/tcp open on a live host. The tester records supported SMB dialects and that signing is not required. Which 2.2 technique is that?