Master every Nmap scan type — SYN, TCP connect, UDP, and NULL/FIN/Xmas stealth scans — understand the TCP handshake mechanics that make each one work, use the Nmap Scripting Engine for automated vulnerability detection, and recognise what each scan type looks like from the defender's perspective.
Nmap — Network Mapper
Nmap (Network Mapper) is the industry-standard tool for network discovery and security auditing. Written by Gordon "Fyodor" Lyon and first released in 1997, it has grown from a simple port scanner into a comprehensive platform for host discovery, service enumeration, OS fingerprinting, and automated vulnerability detection through its scripting engine.
Every penetration test starts with Nmap. Before you can exploit anything, you need to know what's there — which hosts are alive, which ports are open, what software is listening, and which version of that software is running. Nmap answers all of these questions, and the CEH exam tests each capability area in detail. Understanding not just the flags but the underlying protocols they interact with separates a practitioner who can use the tool from one who understands what it's actually doing on the wire.
The TCP Three-Way Handshake — Why It Matters for Scanning
Every Nmap scan type is fundamentally a variation on how it interacts with the TCP three-way handshake. Understanding the handshake explains why different scan types have different stealth profiles, privilege requirements, and detection signatures — knowledge that the CEH tests directly.
A normal TCP connection works in three steps: the client sends a SYN packet to indicate it wants to connect. The server responds with SYN-ACK if the port is open (acknowledging the request and sending its own synchronise). The client sends ACK to complete the handshake. Only after all three packets are exchanged does data flow. This completed connection is logged by most operating systems.
TCP is like making a phone call. You dial the number (SYN — initiating contact). The person picks up and says "Hello?" (SYN-ACK — acknowledging you and indicating they're there). You say "Hi, it's me" (ACK — confirming you heard them). Now you're connected and can talk. If nobody picks up, the call goes to voicemail or rings out — equivalent to a filtered or closed port. If the number doesn't exist, you get a fast busy signal — equivalent to an RST response from a closed port. Each Nmap scan type interacts with this process differently, either completing the call, hanging up mid-ring, or using different signals entirely.
Scan Types — Every Option Explained
-sS SYN scan Half-open, requires root, stealthiest TCP scan ← default -sT TCP connect Full handshake, no root needed, logged by target -sU UDP scan Finds DNS/SNMP/TFTP, slow, requires root -sN NULL scan No flags set — evades some stateless firewalls -sF FIN scan FIN flag only — same evasion technique as NULL -sX Xmas scan FIN+PSH+URG set — named for "lit up like a tree" -sA ACK scan Maps firewall rules — not for finding open ports -sI Idle/Zombie Completely blind scan using a zombie host's IP ID -sn Ping scan Host discovery only, no port scanning -sV Version detect Probes open ports for software name and version -O OS fingerprint Analyses TCP/IP stack quirks to identify OS -A Aggressive OS + version + default scripts + traceroute
SYN Scan (-sS) — The Default and Why
The SYN scan sends a SYN packet and waits for the response. An open port replies SYN-ACK; a closed port replies RST. Crucially, Nmap then sends RST rather than completing the handshake — the connection is never fully established. This "half-open" technique is considered stealthy because many older IDS systems and some application logs only record fully completed connections. The half-open SYN scan never appears in application-level connection logs on the target.
SYN scanning requires root (or Administrator on Windows) because sending raw TCP packets — rather than using the OS's socket API — requires raw socket privileges. This is the trade-off: root = can craft raw packets = can send half-open SYN; non-root = must use OS sockets = full TCP connect that completes the handshake.
NULL, FIN, and Xmas Scans — Exploiting RFC Ambiguity
The NULL (-sN), FIN (-sF), and Xmas (-sX) scans exploit an ambiguity in RFC 793 (the TCP specification). When a packet arrives at a closed port with unexpected flags, the RFC says the port should respond with RST. But when it arrives at an open port, the RFC says the packet should simply be ignored — no response. Nmap uses this asymmetry: no response = open (or filtered); RST = closed.
These scans can bypass simple packet-filter firewalls that only block SYN packets (a common misconfiguration), because the initial packet carries no SYN flag. However, they do not work against Windows systems, which violate RFC 793 by sending RST for all unexpected packets regardless of port state. The CEH tests this Windows exception directly.
Port States — What Every Response Means
| State | What Nmap Received | What It Means | Action |
|---|---|---|---|
| Open | SYN-ACK (for SYN scan) or application data (UDP) | A service is actively listening and accepting connections on this port | Investigate service and version — primary attack surface |
| Closed | RST packet | No service listening, but the host is reachable and the port is accessible | Confirms host is alive; note for firewall rule comparison |
| Filtered | No response or ICMP unreachable | A firewall, filter, or ACL is blocking access — Nmap cannot determine if a service is present | Try different scan types or timing; may be worth probing manually |
| Open|Filtered | No response (for NULL/FIN/Xmas/UDP) | Cannot distinguish open from filtered — both produce silence in these scan types | Follow up with a SYN or connect scan to resolve ambiguity |
| Unfiltered | RST (ACK scan only) | Port is accessible but Nmap cannot determine open vs closed from ACK scan alone | Use ACK scan to map firewall rules, not to find services |
Nmap in Action
Start with a SYN scan of the most common 1,000 ports. Fast and stealthy — the default Nmap scan when run as root.
nmap 192.168.1.100 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 3306/tcp open mysql # MySQL on 3306 reachable from anywhere — likely misconfiguration # Should only be accessible from application servers, not the network
Add -sV to probe open ports and determine what software is running and its version. This is the bridge between "port is open" and "specific CVE is exploitable."
nmap -sV 192.168.1.100 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 80/tcp open http Apache httpd 2.4.52 # Search NVD/CVE databases: site:nvd.nist.gov "Apache 2.4.52" # Version precision enables targeted exploit research
The default scan checks only the top 1,000 most common ports. Administrators frequently run services on non-standard ports assuming obscurity provides security. Scanning all 65,535 ports eliminates this hiding place.
nmap -p- 192.168.1.100 # Faster with rate control: nmap -p- --min-rate 5000 192.168.1.100 PORT STATE SERVICE 22/tcp open ssh 8080/tcp open http-alt <-- hidden service not in top 1000! 31337/tcp open unknown <-- non-standard port, investigate manually
NSE scripts can detect known vulnerabilities automatically, turning port scan data into actionable vulnerability findings in a single command.
nmap --script vuln 192.168.1.100 | http-csrf: | CSRF vulnerability found at /admin/login nmap --script smb-vuln-ms17-010 192.168.1.100 | smb-vuln-ms17-010: | VULNERABLE: Remote Code Execution (EternalBlue)
What You Need to Know
OS Fingerprinting — How Nmap Identifies Operating Systems
OS fingerprinting works by exploiting the fact that different operating systems implement the TCP/IP stack slightly differently — in ways that are consistent within each OS family but distinguishable between them. Nmap sends a series of precisely crafted probe packets and analyses the responses across multiple dimensions to build a "fingerprint" that it matches against its OS database.
The signals Nmap analyses include: initial TCP window size (Linux typically uses 5840, Windows uses 65535); IP TTL values (Linux defaults to 64, Windows to 128, Cisco routers to 255); TCP options ordering in SYN packets; responses to malformed packets (FIN probes, NULL probes); ICMP error message handling; and sequence number predictability.
OS detection narrows down exploit selection, privilege escalation paths, and tool choices — a Windows target needs entirely different post-exploitation than a Linux one.
nmap -O 192.168.1.100 OS details: Linux 5.4 - 5.15 Network Distance: 2 hops nmap -O 192.168.1.50 OS details: Microsoft Windows Server 2019 OS CPE: cpe:/o:microsoft:windows_server_2019 # Windows Server 2019 → check MS17-010, BlueKeep (CVE-2019-0708), # PrintNightmare (CVE-2021-34527) — all Windows-specific vulnerabilities
Imagine trying to identify the make of a car by watching how it drives past you without seeing the badge. A sports car accelerates differently than a lorry. A diesel sounds different from a petrol engine. An automatic shifts without a clutch. Each manufacturer has slightly different suspension tuning that produces a characteristic ride quality. You cannot identify the exact model with certainty, but you can narrow it down significantly — and that narrows your next questions. OS fingerprinting is exactly this: not reading a label, but analysing characteristic behaviour patterns in the TCP/IP responses to narrow down which operating system produced them.
NSE — Nmap Scripting Engine in Depth
The Nmap Scripting Engine transforms Nmap from a port scanner into a networked intelligence platform. Scripts are written in Lua and execute within Nmap's scanning framework — they can interact with discovered services, probe for specific vulnerabilities, extract information from protocols, and even perform limited exploitation for proof-of-concept purposes.
Scripts are organised into categories. Understanding which category to use — and the risk profile of each — is important both for professional engagements and for the CEH exam:
- safe: Won't crash services or consume excessive resources. Always appropriate to run.
- default: A curated set of safe scripts providing high-value information. Run automatically with
-A. - discovery: Active information gathering about the network and services.
- auth: Tests authentication mechanisms — credential checking, bypass attempts.
- brute: Password brute-force against services. Noisy — use with authorisation only.
- vuln: Checks for known vulnerabilities. May be flagged by IDS. Should be authorised.
- exploit: Actively exploits vulnerabilities. Rarely used in Nmap — Metasploit is more appropriate for this.
- intrusive: May crash services or consume significant resources. Use with caution.
Rather than running all vulnerability scripts against all ports (slow and noisy), target specific scripts at specific services based on what the initial scan discovered. This is more efficient and less likely to trigger IDS rate-based alerting.
# HTTP-specific enumeration on web ports: nmap --script http-title,http-methods,http-auth-finder -p 80,443,8080 192.168.1.100 80/tcp: Title: "Corp Intranet Login" Methods: GET POST PUT DELETE OPTIONS <-- DELETE enabled! dangerous Auth: Basic at /admin/ (credentials required) # SMB enumeration (critical for Windows networks): nmap --script smb-enum-shares,smb-enum-users,smb-security-mode -p 445 192.168.1.0/24 | smb-enum-shares: ADMIN$ C$ D$ IPC$ SharedDocs | smb-security-mode: message_signing: disabled <-- NTLM relay attacks possible! # SSL/TLS certificate and cipher analysis: nmap --script ssl-cert,ssl-enum-ciphers -p 443 192.168.1.100 | ssl-cert: Subject: CN=*.example-corp.com | Not valid before: 2024-01-15 Not valid after: 2025-01-15 | ssl-enum-ciphers: | TLSv1.0 (deprecated) supported <-- PCI-DSS violation # DNS zone transfer test: nmap --script dns-zone-transfer --script-args dns-zone-transfer.domain=example-corp.com -p 53 192.168.1.1
Timing, Evasion, and IDS Avoidance
A scanner that immediately triggers every IDS rule is less useful than one that gathers the same information without alerting the target. Nmap provides several mechanisms to reduce scan visibility, each with specific trade-offs between speed, accuracy, and stealth.
# Timing templates (T0=paranoid, T3=normal, T5=insane): -T0 Paranoid 5 min between probes — evades most rate-based IDS -T1 Sneaky 15 sec between probes — slow but hard to detect -T2 Polite 0.4 sec — reduces bandwidth, still detectable -T3 Normal Default — parallel probing, full speed -T4 Aggressive Assumes fast, reliable network — faster results -T5 Insane May miss results — sacrifices accuracy for speed # Decoy scanning — hides real source among decoys: nmap -D RND:10 192.168.1.100 # Generates 10 random decoy IPs alongside real scan # Target sees 11 sources — hard to identify which is real # Packet fragmentation — splits probes across small packets: nmap -f 192.168.1.100 # 8-byte fragments — may evade IDS that doesn't reassemble streams # Source port spoofing — makes scan look like common traffic: nmap --source-port 53 192.168.1.100 # Some firewalls allow all traffic from port 53 (DNS) # Sending scans from port 53 can bypass these poorly configured rules
The idle scan (-sI) is Nmap's most advanced evasion technique — it uses a "zombie" host with predictable IP ID sequences to perform a port scan without sending a single packet from the attacker's real IP address. The target only ever sees packets from the zombie host.
# Find a suitable zombie (needs predictable/incremental IP ID): # The zombie must be idle (not sending other traffic) for accuracy nmap -O --script ipidseq 192.168.1.50 IP ID Sequence Generation: Incremental ← suitable zombie! # Perform idle scan using zombie — attacker's IP never appears at target: nmap -sI 192.168.1.50 192.168.1.100 PORT STATE SERVICE 22/tcp open ssh # 192.168.1.100 only saw packets from 192.168.1.50 (the zombie) # The attacker's real IP never appeared in the target's logs # Also reveals firewall trust relationships: zombie may access ports attacker cannot
Scanning Strategy — From Discovery to Exploitation Input
Professional scanning is not running a single Nmap command against a target — it is a multi-stage methodology that builds progressively more detailed knowledge while managing noise and scan time. The CEH outlines a specific scanning order that maximises information while minimising unnecessary exposure.
- Host discovery first:
nmap -sn 192.168.1.0/24— identify which hosts are alive before port scanning any of them. Scanning closed IP addresses wastes time and generates unnecessary traffic. - Quick top-port scan:
nmap -sS --top-ports 1000against live hosts — fast initial triage to identify the most accessible services across the entire scope. - Full port scan on interesting hosts:
nmap -p- --min-rate 3000against the specific hosts that look most promising — finds non-standard ports the initial scan missed. - Service and version detection:
nmap -sV -sC -p [open_ports]against confirmed open ports — extract the specific software versions needed for CVE lookup. - Targeted NSE scripts: Run service-specific scripts based on what version detection revealed — SMB scripts for Windows, HTTP scripts for web servers, SSL scripts for HTTPS services.
A small organisation's sysadmin has moved their SSH server from the standard port 22 to port 22345, reasoning that attackers won't find it if it's not on the expected port. They disable the firewall rule for port 22 and consider the server secured.
An Nmap full port scan (nmap -p- --min-rate 5000) takes approximately 90 seconds and finds SSH running on port 22345. The version detection reveals OpenSSH 7.4 — a version with several known vulnerabilities. The sysadmin's obscurity measure provided approximately 90 additional seconds of protection, at the cost of operational inconvenience for legitimate users who had to remember the non-standard port.
This scenario illustrates a fundamental security principle that the CEH tests explicitly: security through obscurity is not a security control. It may slow down casual automated scanning but provides no protection against deliberate targeted scanning. Real security requires authentication, authorisation, and patching — not hidden port numbers.
Detecting Nmap Scans — Defender's Perspective
Port scans produce distinctive network patterns that IDS/IPS systems and network monitoring tools are specifically designed to detect. Understanding these signatures helps defenders tune their detection capabilities and helps practitioners understand what footprint their scanning leaves behind.
Multiple SYN packets to different ports in rapid succession from a single source. Half-open connections that never complete the handshake. A ratio of SYN to SYN-ACK that is far lower than legitimate traffic (legitimate connections complete; scans do not).
Snort rule: alert tcp any any -> $HOME_NET any (flags:S; threshold: type threshold, track by_src, count 20, seconds 60; msg:"Port Scan Detected";)
Service version detection sends slightly unusual probe payloads to elicit informative responses. These probes often don't match the expected first packet for the service protocol — an SMTP server receiving a generic banner-grab probe sees a connection that opens and sends nothing, then disconnects. Service-aware IDS systems flag these anomalous probe patterns.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Nmap Port Scanning→← Return to all labs