Network Scanning and Enumeration

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Before you can attack infrastructure, you must see it — precisely. Phase 2’s recon mapped a web application; network scanning maps the machines and services beneath it. The discipline is identical to 2.1: you cannot attack, and you cannot defend, what you have not first mapped. The attacker who scans thoroughly is halfway in; the defender who scans their own network first finds the open door before the attacker does.

Part 1: The Problem

In Phase 2 your target was an application. Now your target is infrastructure — the actual machines, and the services running on them, that an organization exposes. A web app is one door in a building that has many: an SSH service for remote administration, a database, a file-sharing service, a mail server, a remote-desktop service, and more (you met these in 0.4).

You cannot test any of those until you know they exist. Network scanning and enumeration is the systematic process of discovering: which machines are alive, which ports are open on each, what service sits behind each port, and what version that service is. It is the infrastructure equivalent of Phase 2’s reconnaissance — and just as much the foundation of everything that follows.

Part 2: The Concept — From Hosts to Services to Versions

Network mapping proceeds in a natural sequence, each step narrowing toward something attackable:

   1. HOST DISCOVERY  →  which machines are alive?
            │
            ▼
   2. PORT SCANNING   →  on each live machine, which ports are open?
            │              (recall 0.4: every open port is a door)
            ▼
   3. SERVICE DETECTION → what service sits behind each open port?
            │
            ▼
   4. VERSION DETECTION → which exact VERSION of that service?
            │
            ▼
   5. ENUMERATION      →  dig into each service for detail:
                          users, shares, config, weaknesses

Each step matters, but version detection is where it gets sharp — exactly as in Phase 2.10. “Port 22 is open” tells you SSH is there. “Port 22 runs [a specific old SSH version]” tells you which known vulnerabilities to look up. The map you build is not just “what exists” but “what exists, exactly, and therefore what is worth attacking.”

Part 3: The Concept — Ports and Their States

When you scan a port, the scanner reports a state — and the states are themselves information.

This connects straight to 0.4: scanning is how you measure a machine’s attack surface. An open port is an opportunity; a filtered port reveals a firewall; the pattern of open ports often reveals what a machine is for (a web server, a domain controller, a database host).

A note on scanning behavior: scans range from quiet and slow to loud and fast, and from light SYN scans to full connection scans. Aggressive scanning is noisy — it generates obvious traffic a defender’s monitoring (Phase 4.6) will catch — and very aggressive scanning can even disrupt fragile services. The professional tunes the scan to the engagement.

Part 4: Nmap — The Standard Tool

Nmap (Network Mapper) is the long-standing standard tool for this entire process — host discovery, port scanning, service and version detection, and more. You met it briefly in 0.4 and 0.6; here it becomes a core instrument. Add it to your Tools & Reference Cheatsheet.

What Nmap does, conceptually:

• Host discovery — find which machines in a range are alive.
• Port scanning — determine open/closed/filtered ports on a target.
• Service & version detection — identify the service and version behind each open port.
• OS detection — make an educated guess at the operating system.
• Scripted checks — Nmap includes a scripting engine with a large library of scripts that perform deeper enumeration and check for specific known issues.

You do not need to memorize every flag — you need to understand the workflow: discover hosts, scan ports, detect versions, then enumerate the interesting services. Nmap is how you do steps 1–4 of Part 2; reach for its documentation (man nmap, from the 0.2 habit) for exact options. There are other and newer scanners, some far faster for huge ranges, but Nmap remains the one to learn first and know best.

Part 5: Enumeration — Going Deeper on Each Service

Scanning tells you a service exists. Enumeration is the deeper step: actively interrogating that specific service for useful detail. It’s where a scan result becomes an attack path.

Enumeration is service-specific — each service reveals different things and is interrogated differently. You’ll go deep on the major ones in 3.2; for now, the idea:

• A web service — enumerate as in Phase 2 (pages, technologies).
• A file-sharing service (like SMB) — enumerate shared folders, sometimes user lists.
• An SSH service — note the version, sometimes the supported authentication methods.
• An FTP service — check whether anonymous access is allowed; list files.
• A database service — note the type and version; check whether it’s exposed at all.
• A directory or naming service — can reveal users, groups, and organizational structure.

A core enumeration technique is reading service banners — many services announce their name and version on connection (the “banner”). Banner grabbing is often the quickest route to a version number.

The principle: scanning finds the doors; enumeration inspects each door closely — what’s behind it, how it’s configured, whether it’s weak. Thorough enumeration is, again, the unglamorous work that distinguishes real testers from people who scan once and stop.

Part 6: This Is a Defensive Skill Too

The offense/defense mirror, exactly as in 2.1. Everything in this page, turned inward, is core defensive practice:

• Defenders scan their own networks — continuously — to know their real attack surface. You cannot protect a machine or service you didn’t know was exposed, and “shadow” systems nobody remembered are a classic breach cause.
• Discovering forgotten services before an attacker does is one of the highest-value defensive activities — the infrastructure version of 2.1’s attack surface management.
• Network monitoring (Phase 4.6) is partly the art of detecting an attacker’s scans — scanning is noisy, and noticing it is an early-warning signal.
• Firewall and segmentation design (Phase 4.4) is the discipline of shrinking what a scan can even find — fewer reachable ports, fewer doors.

So this page is simultaneously the opening move of an attack and a routine defensive health-check. Learn it as both — that dual view is what Phase 4 will build on.

📓 Key Terms

🧪 Hands-On Lab

Scan only machines you own — your own lab network from Phase 0.5 — or authorized practice platforms. Scanning networks you don’t own can be a criminal offense even with no harm done (page 1.0). This is not negotiable.

Task 1 — Confirm your lab. Start your Kali VM and your vulnerable victim VM(s) on the isolated host-only network from Phase 0.5. From Kali, confirm you can reach the victim (ip addr to find addresses, then ping).

Task 2 — Host discovery. From Kali, run a host-discovery scan across your lab’s network range. Confirm Nmap finds your victim machine(s). You’ve just mapped which machines are alive.

Task 3 — Port scan. Run a port scan against your victim VM. Record every open port. For each, note what service you’d expect there from the 0.4 port table.

Task 4 — Service and version detection. Re-scan with service/version detection enabled. Now record the exact service and version on each open port. This list is the foundation for 3.2 and 3.3.

Task 5 — Read a banner. Pick one open service and connect to it directly (e.g. with netcat or telnet to that port) to read its banner. See the version announce itself.

Task 6 — Try a scripted scan. Run one of Nmap’s scripted scans against a service on your victim VM. Observe how it enumerates deeper than a plain port scan.

Task 7 — Scan yourself, defensively. Run a service/version scan against your own Kali machine. Read the result as a defender: which of these do you actually need running? That question is attack-surface reduction (0.4) — and a preview of Phase 4.4.

Task 8 — Build the infrastructure map. In Notion, create “Infrastructure Map — [lab].” Record every host, every open port, every service and version. This is the infrastructure equivalent of your Phase 2 recon report, and you’ll use it through all of Phase 3.

⚠️ Common Mistakes

• Scanning networks you don’t own. A port scan is an interaction with a target and can be a criminal offense regardless of harm. Your lab and authorized targets only.
• Skipping version detection. “Port open” is weak; “port open running [exact version]” is a lead. Versions drive everything in 3.2 and 3.3.
• Skimping on enumeration. Scanning finds doors; enumeration inspects them. Stopping at the scan means missing the actual attack paths.
• Scanning aggressively without thinking. Aggressive scans are loud (a defender’s monitoring catches them) and can disrupt fragile services. Tune the scan to the situation.
• Mapping only the obvious machine. Enumerate the whole lab network — the forgotten host is often the soft target, exactly as the forgotten subdomain was in 2.1.

✅ Recap & What’s Next

• Network scanning maps infrastructure in sequence: host discovery → port scanning → service detection → version detection → enumeration.
• Port states (open / closed / filtered) and versions are themselves information; Nmap is the standard tool, and enumeration is the deeper interrogation that turns a scan result into an attack path.
• Pointed inward, this is core defensive practice — scanning your own network to find forgotten services before an attacker does.

Next (3.2): You’ve mapped the services. Now we examine the most commonly misconfigured ones — SMB, FTP, SSH, databases — and how attackers turn a weak service into a foothold.