Scanning & Enumeration

Penetration Testing Methodology

Chapter 5 · Scanning & Enumeration

pentest1-4 produced a candidate list of assets — IP ranges, subdomains, hints about technology in use. This phase confirms which of those candidates are actually alive, what ports are actually open on them, and what's actually running behind each one — turning a speculative list into hard, verified evidence.

Host Discovery

Before scanning individual ports, a real engagement first confirms which hosts in a range are actually reachable — most simply, via a ping sweep, extending net1-10's own diagnostic-tooling chapter directly. But this needs an important caveat: many firewalls block ICMP by default, so a host that doesn't respond to a ping isn't necessarily down — it may simply be filtering the exact protocol being used to check.

Port Scanning

A port scan sends probes across a range of ports and observes the response to classify each one as open, closed, or filtered — filtered meaning no response was returned at all, which is itself ambiguous (it could mean a firewall is silently dropping the probe, or that nothing is listening and the host simply doesn't reply).

Scan type	Mechanism	Handshake completed?	Trade-off
TCP Connect Scan	Completes a full connection via the OS's own networking stack	Yes — full three-way handshake	Reliable, but easily logged — a completed connection is the most visible kind of event
SYN Scan (half-open)	Sends SYN, reads the SYN-ACK response, then sends RST instead of completing with ACK	No — deliberately incomplete	Faster and stealthier — many logging systems only record fully-established connections

SYN scanning is net1-7's own three-way handshake, deliberately interrupted

net1-7 covered TCP's three-way handshake — SYN, SYN-ACK, ACK — in full. A SYN scan uses exactly that same exchange, but stops after step two: it sends the SYN, reads whether a SYN-ACK comes back (which alone reveals whether the port is open), and then sends an RST instead of the final ACK, rather than ever completing the handshake and establishing a real connection. This is precisely why it's called "half-open," and precisely why it tends to leave less of a trace than a full TCP Connect scan.

Service & Version Detection, Banner Grabbing

Confirming a port is open only answers "is something listening here" — the next question is what. Many services announce their own software name and version on connection — an SSH server, for instance, commonly announces a banner like OpenSSH_8.9 before any authentication happens at all. Tools like nmap automate this with dedicated version-detection modes (-sV), sending protocol-specific probes and comparing the responses against a database of known service signatures.

A specific, identified version is directly useful — it immediately narrows down which known vulnerabilities are even worth considering in pentest1-6, rather than starting from a generic "this port is open" with no further information.

Building a Real Attack Surface Map

Combining every piece from this phase — pentest1-4's discovered candidate assets, confirmed-alive hosts, confirmed-open ports, and identified service versions — produces a genuine, evidence-based map of the target's actual attack surface, replacing pentest1-4's own broader, more speculative candidate list. This map is the direct, concrete input pentest1-6's vulnerability analysis phase works from.

Aggressive scanning can cause real disruption, not just noise

A fast, aggressive scan isn't just "loud" in a logging sense — against fragile or legacy systems (older embedded devices, industrial control systems, some IoT hardware), an aggressive scan has genuinely crashed real production equipment in documented real-world cases. This is exactly why scan intensity and timing sometimes need to be addressed explicitly in the written scope agreement from pentest1-2 — not just which hosts are in bounds, but how hard and how fast they can safely be probed.

Hands-On Exercises

Exercise 1

Explain the difference between a TCP Connect scan and a SYN scan, tying your answer explicitly to net1-7's own three-way handshake material. Why is a SYN scan considered "stealthier"?

📄 View solution

Exercise 2

A ping sweep against a target's IP range gets no response from a specific address. Explain why this doesn't necessarily mean the host is down, and what the more careful conclusion is.

📄 View solution

Exercise 3

Using this chapter's own warn-box, explain why scan intensity and timing might need to be explicitly addressed in the written scope agreement from pentest1-2, with a concrete example of what could go wrong without that.

📄 View solution

Chapter 5 Quick Reference

Host discovery builds directly on net1-10's diagnostic tools — but a lack of ping response ≠ confirmed down (ICMP is often filtered)
Port states: open / closed / filtered — filtered is ambiguous (could be a firewall, could be nothing listening)
TCP Connect scan — full handshake, reliable, easily logged · SYN scan — stops after SYN-ACK, deliberately never completes net1-7's own three-way handshake, faster/stealthier
Version detection/banner grabbing narrows the field for pentest1-6's vulnerability analysis directly
Recon (pentest1-4) + confirmed hosts/ports/versions (this chapter) = the real attack surface map
Aggressive scanning can cause real disruption on fragile systems — scan intensity/timing belongs in written scope, per pentest1-2
Next chapter: Vulnerability Analysis — the site's own existing xss1/csrf1/sqli1/bc1/dbsec1/owasp1 "toolkit," formally named