Post cover image
TCP Three-Way Handshake & Scan Variations

June 11, 2026

Every Nmap Flag Has a Why — Part 1

Host Discovery, Port Scanning, and Why Every Scan Type Exists

Mohan Sai Krishna G M

17 min read

Host Discovery, Port Scanning, and Why Every Scan Type Exists

Because memorising flags isn't the same as understanding networks.

There are two kinds of people who use Nmap.

The first kind memorises flags. They know that -sS is a SYN scan, -sU is UDP, -A does everything at once. When something doesn't work, they search for another flag. When the output looks strange, they move on. When the tool is replaced by something newer, they start over.

The second kind understands why those flags exist. They know what problem each scan type was invented to solve. They know what's happening at the packet level. When something fails, they can reason about it. When a new tool appears, they already understand the logic it's built on.

This series is for people who want to be the second kind.

Flags are included throughout — not to memorise, but to anchor concepts to reality. When you see -sS, the thought should be: half-open SYN scan, bypasses application logging, requires root. Not just: that's the default.

The mental model is the point. Let's start with the network, before the scanner.

Section 1: The Network Before the Scanner

Before Nmap sends a single packet, the network has already decided what it will and won't reveal. Understanding those rules changes how you read every result.

The building analogy

Think of a target as a large office building. The building has one street address that's the IP address. Inside, there are hundreds of rooms, each numbered, those are ports. Different services occupy different rooms: the web server is in room 80, the encrypted web server in 443, the database in 3306, the remote access service in 22.

To reach a specific service, you need both the building address and the room number. The IP gets you to the building. The port gets you to the right room.

Some rooms have someone inside, waiting for visitors — that's a listening service. Some rooms are empty — closed port. Some have a guard who stops you silently, without explanation — filtered port.

Everything Nmap does is an attempt to figure out which rooms are occupied, which are empty, and which have a guard without ever having access to the building directory.

Three possible answers to every knock

When Nmap probes a port, only three responses are possible:

Response What it means Nmap calls it "Yes, come in" (SYN-ACK) A service is listening Open "Nobody here" (RST) Port reachable, nothing listening Closed Silence A firewall dropped the packet Filtered

Every scan type in Nmap's arsenal is a different way of asking the same question. The answer always comes back as one of these three.

TCP: the protocol Nmap exploits most

TCP is connection-oriented. Before two machines exchange data, they perform a handshake:

You ──── SYN ──────────────────► Server   "I want to connect"
You ◄─── SYN/ACK ──────────────  Server   "OK, I'm here"
You ──── ACK ──────────────────► Server   "Great, let's talk"

This three-way handshake is the foundation of every TCP connection. Data flows only after all three steps complete.

Why does this matter for scanning? Because Nmap exploits each step differently, depending on what it needs to know. Some scan types complete the handshake. Some stop deliberately at step two. Some skip the handshake entirely and send something the protocol never expected.

Each variation reveals different information. That's the entire logic of TCP-based scanning.

UDP: the protocol that makes scanning hard

UDP has no handshake. No acknowledgment. No state. You send a packet, and you either get something back or you don't — and silence could mean the port is open or it could mean the packet was dropped. UDP makes scanning genuinely difficult, which is why UDP scans take far longer and produce less reliable results. More on that in Section 3.

The key insight: Nmap reads behaviour, not truth

Nmap cannot see your target's source code. It cannot inspect the process list or read configuration files. It has no access to the server's logs.

All it can observe is how the network responds to specific inputs.

Everything Nmap tells you is an inference from network behaviour — a reconstruction, not a direct observation. The same kind of reconstruction a forensic investigator performs: arrive after the event, read the evidence, reason backwards. As discussed in the previous article, this is why experienced practitioners treat scan results as hypotheses, not facts. The evidence can be misleading. The behaviour can be faked.

Keep that in mind throughout.

None

Section 2: Host Discovery — Finding Who's Home

Before Nmap scans ports, it needs to know which IP addresses have a live host behind them. Scanning all 65,535 ports against thousands of empty IP addresses wastes hours. Host discovery is the quick "is anyone home?" check before the detailed work begins.

But the way you ask "is anyone home?" determines whether you get an honest answer.

Method 1: ARP Discovery (-PR)

ARP (Address Resolution Protocol) is how devices on a local network map IP addresses to hardware MAC addresses. When Nmap sends an ARP request, it's asking: "Who has this IP? Tell me your hardware address." Any device with that IP must respond — because ARP operates below the firewall layer.

Firewalls operate at Layer 3 (IP) and above. ARP lives at Layer 2 (hardware). It goes underneath the filtering. A Windows host blocking all ICMP and TCP probes will still respond to ARP.

Scanner ──── ARP "Who has 192.168.1.50?" ────► Network
Target  ──── "I do, my MAC is AA:BB:CC..."  ─► Scanner
Result: Host is alive

Use -PR when: You're on the same local network segment. Internal assessments, lab environments.

Don't use it for: Scanning across routers. ARP doesn't cross router boundaries — by design. On external assessments, it's irrelevant.

Method 2: ICMP Discovery (-PE, -PP, -PM)

ICMP echo — the classic ping — sends a request and waits for a reply. Simple. Reliable. And in enterprise environments, almost always blocked.

Decades of "block ping for security" guidance means a live, healthy Windows server will silently ignore your echo request. Nmap offers alternatives for exactly this reason:

  • -PE — ICMP echo request (most common, most filtered)
  • -PP — ICMP timestamp request (sometimes passes when echo is blocked)
  • -PM — ICMP netmask request (another variant worth trying)
Scanner ──── ICMP Echo ────────────► Target
[No response — ICMP blocked at firewall]
Nmap concludes: host is down   ← Potentially wrong

The lesson: A non-response to ICMP tells you almost nothing about whether a host is alive. In enterprise environments, it tells you nothing at all.

Method 3: TCP SYN Discovery (-PS[ports])

Instead of knocking on the front door, you try a window you know is usually open. Almost every internet-facing server has port 80 or 443 accessible. A TCP SYN probe to those ports gets a response — even a RST (nobody listening here) still confirms the host exists.

Scanner ──── SYN → port 443 ──────► Target
Target  ──── SYN/ACK ─────────────► Scanner   (port open)
   OR
Target  ──── RST ─────────────────► Scanner   (port closed)
Either way: host is alive

Use -PS when: ICMP is unreliable and you need TCP-based confirmation. This is almost always more reliable than ICMP for internet-facing targets.

Method 4: TCP ACK Discovery (-PA[ports])

This is the subtler version. Instead of a SYN — which firewalls actively watch for — Nmap sends an ACK packet that looks like the middle of an already-established connection.

Stateful firewalls that don't track existing connections may pass the ACK through to the host. The host, receiving an ACK it has no record of, sends back a RST. That RST arrives from behind the firewall — and tells you the host is alive.

Scanner ──── ACK → port 80 ───────► Firewall ──► Host
Host    ──── RST ─────────────────────────────► Scanner
Result: host is alive (RST came from behind the firewall)

Use -PA when: Paired with -PS for better coverage, or when SYN packets are being blocked but ACK packets aren't.

Method 5: UDP Discovery (-PU[ports])

Sends a UDP packet to an unlikely port. If the port is closed, the target responds with ICMP port unreachable — confirming the host exists. Used as a backup when TCP methods are filtered entirely.

Method 6: DNS Reverse Lookup

Before sending a probe, Nmap can query DNS to get the hostname for an IP address. This isn't about confirming liveness — it's free intelligence.

An IP that resolves to prod-db-01.corp.internal is already telling you something about its role, its environment, and its likely importance. DNS gives you context before you've knocked on a single door.

DNS records are sometimes stale. A decommissioned server may still have an entry pointing at an IP now reassigned to something else. Always treat DNS as a starting point, not ground truth.

The -Pn flag: when you skip discovery entirely

-Pn tells Nmap: don't check if hosts are alive — assume they all are and scan everything.

Most documentation stops there. That's technically accurate and practically useless without context.

Here's the real reason you'd use it: Windows. By default, Windows Firewall blocks ICMP echo. A fully operational Windows Server — running Active Directory, RDP, SMB — will appear completely dead to ICMP-based discovery. Without -Pn, Nmap skips it. You miss everything.

The same applies to cloud environments (security groups commonly block discovery probes), VPN tunnels, and any network with custom perimeter filtering.

The tradeoff: -Pn doesn't make scans more accurate. It removes a time-saving shortcut. On a /16 of mostly empty IPs, using -Pn means Nmap attempts full port scans against tens of thousands of addresses — most of which have nothing running. The scan completes. It just takes much longer.

Think of -Pn as a declaration: I've already answered the "is this host alive" question through other means — DNS, asset inventory, prior intelligence — and I want to skip to "what's running on it."

Use -Pn when: You know a host exists but discovery probes aren't getting through. Windows environments, cloud environments, hosts confirmed through other intelligence. Avoid when: Scanning large unknown ranges where most IPs may be empty.

None

Quick Reference: Host Discovery Methods

Method Flag Best For Limitation ARP -PR Local network segments Doesn't cross routers ICMP Echo -PE Simple networks Blocked in most enterprises ICMP Timestamp -PP When echo is blocked Often also blocked TCP SYN -PS[ports] Internet-facing targets Needs accessible TCP port TCP ACK -PA[ports] Behind certain firewalls May be logged UDP -PU[ports] When TCP is filtered Slow, unreliable Skip discovery -Pn Known hosts, cloud, Windows Much slower on large ranges

Section 3: Port Scanning — Different Questions, Different Packets

Every scan type in Nmap exists because someone hit a wall with existing techniques and needed a different way to ask the question. Understanding each scan type means understanding what wall they hit — and what they built to get around it.

Here's the complete reference:

Scan Type Flag Root Required? What It's Really Asking SYN Scan -sS Yes Is this port open? (quietly) Connect Scan -sT No Is this port open? (loudly) ACK Scan -sA Yes Is there stateful filtering here? Window Scan -sW Yes Can window size reveal port state? FIN Scan -sF Yes Can non-SYN packets bypass filters? NULL Scan -sN Yes Same (no flags at all) Xmas Scan -sX Yes Same (FIN+PSH+URG flags) Maimon Scan -sM Yes Historical FIN/ACK variant (legacy BSD) UDP Scan -sU Yes What UDP services are running? SCTP INIT -sY Yes Are there SCTP services? (telecom) Idle Scan -sI <zombie> Yes Can I scan without revealing my IP? IP Protocol -sO Yes Which IP protocols does this host support?

The SYN Scan (-sS) — The Standard

The problem it solved: Early scanners completed full TCP connections to check every port. A full connection is slow, allocates resources on both ends, and gets logged by every service. When you're checking thousands of ports, that overhead matters.

The insight: You don't need to complete the handshake to know if a port is listening. The SYN-ACK response at step two already tells you everything. The application never needs to see it.

Scanner ──── SYN ────────────────► Target
Port OPEN:    Target sends SYN/ACK
              Scanner immediately sends RST — never completes
              Application layer never logs it
Port CLOSED:  Target sends RST directly
              No connection to abort
Port FILTERED: Silence
              Firewall dropped the packet

Knock on a door and run the moment you hear footsteps. You confirmed someone was home without ever having a conversation.

Use -sS when: Almost always — it's the default for a reason. Fast, reasonably quiet, accurate.

Requires:_ Root or administrator privileges. Raw socket access is needed to craft half-open packets._

Note:_ High-volume SYN scanning is still visible to IDS systems watching for half-open connection patterns._

The Connect Scan (-sT) — The Unprivileged Alternative

SYN scanning requires raw socket access — root or administrator privileges. What if you're running Nmap inside a container, on a shared system, or under restricted permissions?

The connect scan uses the operating system's normal connection API instead of raw packets. The OS handles the full handshake. No special privileges needed.

Scanner ──── SYN ──────────────► Target
Target  ◄─── SYN/ACK ──────────  Target
Scanner ──── ACK ──────────────► Target   ← connection fully established
Scanner ──── RST/FIN ──────────► Target   ← then immediately torn down

The target sees a completed connection. This will appear in application logs. Every open port you probe leaves a footprint.

Use -sT when: No root access. Or when a service only sends its banner after a full connection — the SYN scan won't trigger it.

Avoid when:_ Stealth matters._

The ACK Scan (-sA) — Not What You Think It Is

This is the scan that confuses more people than any other. Most practitioners try to use it for port discovery, walk away frustrated when it won't show "open" or "closed," and move on.

The ACK scan was never designed to find open ports. It was designed to map firewall behaviour.

An ACK packet looks like the middle of an established connection. Stateful firewalls — which track whether a connection was established — will drop an ACK that has no matching connection record. A host that receives the ACK without a firewall in the way responds with RST, because it also has no record of this connection.

No firewall in path:
Scanner ──── ACK ──────────────────────────────► Host
Host    ◄─── RST ──────────────────────────────  Host
Result: UNFILTERED (traffic is reaching the host)
Stateful firewall in path:
Scanner ──── ACK ──────────────► Firewall
Firewall drops it (no connection record)
Result: FILTERED (stateful blocking in place)

The right use: run an ACK scan before other scan types to understand the firewall landscape. Which ports are being statefully filtered? Which ports are reaching the host directly? That shapes everything else.

Use -sA when: You want to map firewall architecture — what's being filtered, not what's listening.

Don't use it when:_ You want to find open services. It can't tell you that._

The Window Scan (-sW) — A Signal in the Noise

While researchers were studying RST responses from ACK probes, someone noticed something almost invisible: on certain operating systems, the RST packet sent in response to an ACK probe at an open port had a non-zero TCP window size. RST packets for closed ports had a window size of zero.

A one-bit behavioural difference in a field most engineers never look at. But it was consistent enough to — theoretically — distinguish open from closed ports using ACK-style packets that SYN filters might not catch.

In practice, this is OS-dependent and unreliable. Cross-validate; never trust window scan results alone.

But notice what this represents: a researcher, looking at a field nobody was paying attention to, found it contained information. That instinct — this field contains more information than anyone realises — is worth cultivating.

Use -sW when: Supplemental confirmation on specific OS types. Never as a primary scan.

FIN, NULL, and Xmas Scans (-sF, -sN, -sX) — The RFC Loophole

The most important thing first: these three scans are useless against Windows targets. Windows ignores the RFC behaviour that makes them work. If you're targeting Windows, stop here.

For Linux and BSD targets, here's the story.

The problem: Early packet filters blocked SYN packets. No SYN, no port scanning. Problem solved — or so they thought.

The insight: The TCP RFC specifies what hosts should do when they receive a packet with no SYN flag at a closed port: respond with RST. At an open port: drop it silently. An observable difference, created by a rule nobody intended as a security mechanism.

  • FIN scan (-sF): sends only a FIN flag — "I'm done talking" — to a port you haven't talked to
  • NULL scan (-sN): sends a packet with no flags — technically invalid by the spec
  • Xmas scan (-sX): sends FIN + PSH + URG together (lit up like a Christmas tree)
Any of these probes sent to a Linux/BSD host:
Port OPEN     → Silence   (RFC: drop unexpected packets at open ports)
Port CLOSED   → RST       (RFC: reset unexpected packets at closed ports)
Port FILTERED → Silence   (firewall dropped it — looks identical to open)

The catch: "open" and "filtered" both produce silence. You can identify closed ports clearly, but you can't reliably distinguish open from filtered.

Use these when:_ Linux/BSD targets, SYN filtering suspected, non-SYN packets might get through._

Never against:_ Windows targets. The results are meaningless._

The Maimon Scan (-sM) — The Historical Curiosity

Named after researcher Uriel Maimon, who documented it in the late 1990s. A FIN/ACK probe instead of an isolated FIN — which caused open ports to drop the packet on certain older BSD variants, while closed ports responded with RST.

Mostly obsolete against modern systems. Worth knowing because it illustrates something important: researchers didn't study only the obvious flag combinations. They tested systematically, exhaustively, experimentally — and found exploitable behaviour in corners of the protocol that nobody was watching. The Maimon scan is a reminder that the network behaviour space is larger and stranger than any single document covers.

Use -sM when: Rarely, if ever, in modern engagements. Historically interesting; occasionally relevant on very old BSD-based legacy systems.

The UDP Scan (-sU) — The Necessary Pain

UDP scanning is slow. Often frustratingly slow. This isn't a bug — it's the physics of how UDP works.

Critical services run over UDP. DNS (53), SNMP (161), NTP (123), TFTP (69), DHCP (67/68). Skip UDP and you miss entire categories of services.

The fundamental problem: UDP has no handshake. Sending a packet to a UDP port gets you one of three things:

Port CLOSED:
Scanner ──── UDP packet ──────────► Target
Target  ──── ICMP unreachable ────► Scanner   ← definitive: closed
Port OPEN but silent:
Scanner ──── UDP packet ──────────► Target
[nothing returns]                             ← open? filtered? unclear
Port OPEN and responsive:
Scanner ──── UDP packet ──────────► Target
Target  ──── UDP response ────────► Scanner   ← definitive: open

An additional complication: many systems rate-limit ICMP unreachable messages to prevent being used in attacks. Even for closed UDP ports, the ICMP response might not arrive — making them appear open. The silence problem compounds itself.

Use -sU when: Checking for specific UDP services on infrastructure devices. DNS, SNMP, NTP.

Practical tip: Don't blanket-scan all 65,535 UDP ports. Target the ones that matter. Pair with -sV — a service-specific probe gets a real response where an empty UDP packet gets nothing.

Be patient:_ UDP scanning a large range takes hours. That's normal._

None

SCTP Scans (-sY, -sZ) — The Telecom Blind Spot

Imagine you're assessing a telecommunications company. TCP and UDP scans return clean results. Almost nothing found. It feels wrong.

Then someone mentions the infrastructure runs SS7 signalling and DIAMETER protocols. The empty results suddenly make sense. You've been scanning with the wrong transport protocol.

SCTP (Stream Control Transmission Protocol) was built for telecom signalling. It doesn't appear in enterprise IT, but shows up heavily in carrier-grade networks and signalling gateways.

Nmap's -sY (SCTP INIT scan) is the SCTP equivalent of -sS. If you're assessing telecom infrastructure and haven't checked for SCTP, you have a categorical coverage gap — not a minor one.

Use -sY when: Assessing telecom environments, carrier networks, or any infrastructure that might run SCTP-based services.

The Idle Scan (-sI <zombie host>) — The Invisible Scan

The idle scan is, conceptually, the most elegant technique in Nmap's repertoire. It lets you scan a target without that target ever seeing your real IP address — by using a third machine as an unwitting measurement instrument.

How it exploits a tiny protocol detail:

Some operating systems increment a counter in every IP packet they send — the IP ID field — in a predictable, sequential way. If you find a "zombie" host that has this predictable pattern and is quiet (not sending much traffic of its own), you can use it to take measurements.

Step 1: Check zombie's current IP ID counter
Scanner ──── probe ──────────────────────────► Zombie
Zombie  ──── response (IP ID = 100) ──────────► Scanner
Step 2: Send a spoofed SYN to target, pretending to be the zombie
Scanner ──── SYN (from: Zombie's IP) ────────► Target
   If target port is OPEN:
   Target  ──── SYN/ACK ────────────────────► Zombie
   Zombie (confused) ──── RST ──────────────► Target
   [Zombie's IP ID increments: now 101]
   If target port is CLOSED:
   Target  ──── RST ────────────────────────► Zombie
   Zombie ignores it
   [Zombie's IP ID stays at 100]
Step 3: Check zombie's IP ID again
Scanner ──── probe ──────────────────────────► Zombie
Zombie  ──── response ────────────────────────► Scanner
ID jumped by 2 → target port was OPEN
ID stayed at 101 → target port was CLOSED

Your real IP never appears in the target's logs. The target only ever sees the zombie's address.

The modern limitation: most operating systems now randomise IP IDs rather than using sequential counters — specifically because of this technique. Finding a suitable zombie today is difficult. But this remains one of the finest examples in networking of how indirect, observable side effects can be weaponised for intelligence gathering.

Use -sI when: Anonymity from a specific target matters and you can locate a suitable zombie.

Idle Scan Three-Party Interaction

Section 4: Port Selection Strategy

Knowing which scan to run matters. Knowing which ports to scan matters equally.

The top-ports logic

Nmap's default scans the 1,000 most commonly open ports. This isn't arbitrary — it's backed by internet-wide scanning data measuring how frequently each port appears open across millions of real hosts.

Scope Flag Use Case Top 100 (fastest) --top-ports 100 Quick reconnaissance, large ranges Top 1,000 (default) (default) Standard assessments Top 10,000 --top-ports 10000 Thorough external scan All 65,535 ports -p- Maximum coverage, time-consuming Specific ports -p 22,80,443,8080 Targeted checks Port ranges -p 1-1024 Legacy well-known port range

When full port scans matter: custom and internal applications often run on non-standard ports — sometimes deliberately (to reduce noise), sometimes by convention, sometimes by accident. A top-1000 scan misses a custom admin panel on 8834 or a database on 27017. When thoroughness matters, -p- is the answer, even if it takes longer.

Sequential vs. randomised order

By default, Nmap randomises the order it scans ports. Sequential scanning is more efficient, but it's also more obviously a scan in any log. Randomised order disperses the traffic pattern. For anything other than a lab, randomisation is standard.

Section 5: The Bigger Picture

Port scanning tells you what's open. That's a starting point, not an answer.

The moment you know port 8080 is open, the real question begins: what is running on it? Is it a web application? A custom protocol? A management interface? A debugging endpoint left open by mistake?

Service detection (-sV) takes open ports and sends application-layer probes to find out what's actually there. That mechanism — how Nmap determines what service is running, and specifically why it's sometimes wrong — was covered in detail in the previous article in this series. The core principle carries forward: an open port plus a service name is still a hypothesis. Validation makes it a fact.

What to Take Away

The mental model that matters here isn't a list of flags. It's this:

Every scan type is the answer to a specific problem someone faced.

SYN scanning was invented because full connections were too slow and too visible. ACK scanning was invented because someone needed to understand firewalls, not just find services. FIN/NULL/Xmas scans were invented because SYN filtering left a gap that RFC behaviour accidentally filled. The idle scan was invented because someone asked whether IP ID counters could be read by a third party — and the answer turned out to be yes.

When you encounter an unfamiliar scan type — in Nmap or in any other tool — ask: what problem was this designed to solve, and what network behaviour makes it possible?

That question will take you further than any flag reference.

Finding hosts and open ports is the easy part.

The harder question is what those observations actually mean — and how much of what you think you're seeing is inference rather than certainty.

The next article moves beyond discovery into operating system fingerprinting, the Nmap Scripting Engine, timing, evasion, and the way experienced practitioners reason through real assessments. The focus, as always, isn't the flags themselves. It's the network behaviour that makes those flags possible.

Because every capability in Nmap exists for the same reason every scan type does: someone needed to answer a question the network wasn't volunteering.

New articles every Thursday.

The tools will change. The interfaces will change. The commands will change. The mental model stays.

Connect with me: LinkedIn · GitHub

Tags:

nmap tutorial, nmap explained, port scanning concepts, nmap syn scan, tcp three way handshake, network reconnaissance, host discovery nmap, nmap for beginners, penetration testing fundamentals, nmap scan types explained, cybersecurity fundamentals, offensive security, tcp ip scanning, nmap mental model, red team reconnaissance