Introduction

Network enumeration is the phase where you discover what is reachable, what is listening, and how a system responds to probes. This is where you build a map of the target and decide which services are worth deeper testing. A clean approach saves time, reduces noise, and prevents the test from stalling later. The goal is not just to find open ports, but to understand how each service behaves and what it reveals.

This post combines Nmap theory with hands-on commands so you can move from discovery to evidence quickly. You will see how to plan scans, interpret port states, and use scripting safely. You will also see how firewalls and IDS or IPS affect scan results and how to adapt. The same workflow works for small lab targets and larger internal ranges.

Enumeration Mindset

Enumeration is often described as the key, but the real challenge is understanding what the service expects and what is relevant. Tools are not the missing piece in most failures, knowledge of interaction is. When you know the protocol and the expected responses, even a small scan can produce high value. This is the difference between a noisy scan and a productive one.

Two focus areas keep enumeration efficient and accurate:

• Functions or resources that allow you to interact with the target or reveal extra details.
• Information that leads to additional access paths, such as versions, banners, or anonymous logins.

Host and Port Discovery

Host discovery tells you what is alive, and port discovery tells you what is reachable. Nmap is the core tool for both tasks, while RustScan is a fast pre-scanner when full port scans are slow. A common workflow is to identify live hosts, sweep ports quickly, and then run deeper scans on the ports that matter. Always align your speed and aggressiveness with the rules of engagement.

Use these commands to find live hosts and then focus on the ports that appear open:

# Host discovery for a subnet
sudo nmap 10.129.2.0/24 -sn -oA tnet | grep for | cut -d" " -f5

# Host discovery from a list
sudo nmap -sn -oA tnet -iL hosts.lst | grep for | cut -d" " -f5

# Fast port discovery with RustScan, then Nmap on hits
rustscan -a 10.129.136.187 --ulimit 5000
nmap -sC -sV -p 20-25,80,443,8000-8100 10.129.136.187

Port states explain how the target responds to probes. These states help you decide if a port is truly open, blocked by a firewall, or simply not answering. They also help you detect filtering and decide whether to change your scan type. Use the table below as a quick reference for Nmap results.

A solid baseline scan uses version detection and default scripts, and you can extend it with OS detection or UDP if needed. Keep in mind that UDP is slower and often silent, so be careful with expectations. If a service looks interesting, run a targeted scan on that port with scripts or banners. This keeps your work focused and avoids drowning in data.

# Full TCP scan with service and script detection
nmap -p- --min-rate 1000 -sV -sC 10.129.42.253

# Top ports only, useful on large ranges
nmap --top-ports 100 -sV -sC 10.129.2.28

# UDP example, slower but sometimes critical
nmap -sU --top-ports 20 10.129.2.28

Nmap Scripting and Categories

Nmap scripts extend scans from simple discovery to deeper enumeration. The scripts are grouped into categories so you can choose safe, default, or intrusive behavior. This is useful when you need to limit risk or when you want to run a focused set of checks on a service. Always confirm the rules before using intrusive or exploit scripts.

Here are the core script categories and what they are meant to do:

Use categories when you want structured coverage, and use specific scripts when you need a single answer. Default scripts are usually safe for labs, but always consider production impact. If you detect anonymous access in a service like FTP, capture that quickly and decide whether to explore it further. This keeps you aligned with the goal of finding real access paths.

# Default scripts
nmap -sC -sV 10.129.2.28

# Category scan
nmap --script vuln -p 80,443 10.129.2.28

# Specific script example
nmap --script smb-os-discovery.nse -p 445 10.129.2.28

Interpreting Results and Saving Output

Nmap output can show more than just open ports, including banners, protocols, and script results. Pay attention to details like anonymous logins or unexpected versions, because those clues often lead to real findings. You can also use packet traces to understand why a port is marked closed or filtered. Knowing how to read the output makes your next steps far more precise.

Saving results in multiple formats makes collaboration and reporting easier. The -oA option creates normal, grepable, and XML outputs at once, which is perfect for parsing later. When you need to understand a specific packet flow, enable packet tracing and review the SENT and RCVD fields. This is especially useful when a firewall or IPS is modifying behavior.

# Save in all formats
nmap -sV -sC -oA scan-all 10.129.2.28

# Packet trace example
nmap 10.129.2.28 -p 21 --packet-trace -Pn -n --disable-arp-ping

A simple guide to the most common packet trace fields helps you read output quickly:

Firewall, IDS, and IPS Considerations

Firewalls filter or block traffic based on rules, while IDS and IPS look for patterns that indicate scanning or attacks. A firewall often blocks inbound SYN probes, which is why SYN and connect scans are easy to detect or block. ACK scans are harder to filter because they look like responses to existing connections, so they can reveal filtering behavior. Understanding how these systems respond lets you choose scans that are both accurate and quiet.

IDS systems monitor traffic and alert administrators, while IPS systems can actively block your source address. When an IPS triggers, your IP may be blocked and further scans will fail, which can waste time. One method to detect this is to scan from multiple VPS addresses and compare behavior. If a host blocks one source but not others, you likely triggered automated defenses.

Use timing, decoys, and source controls to adjust your scan profile without losing coverage. Do not overuse aggressive settings when a quiet profile is required, and do not assume a filtered result means a port is closed. Always verify with alternate scan types or a targeted probe. This is the part of enumeration where patience often wins.

# ACK scan to detect filtering
nmap -sA -p 80,443 10.129.2.28

# Decoys and source adjustments
nmap -D RND:5 -S 10.129.2.200 -e tun0 --source-port 53 10.129.2.28

# Timing and retry controls
nmap --max-retries 0 --min-rate 300 --initial-rtt-timeout 50ms --max-rtt-timeout 100ms 10.129.2.28

Supporting Tools: Netcat and Tcpdump

Netcat is useful for quick service checks, banner grabs, and simple TCP interactions. It is a practical way to validate what Nmap reports and to confirm whether a service accepts input. Use it when you want to see raw service responses or test basic authentication prompts. A single connection can reveal protocol details that Nmap scripts might miss.

nc -nv 10.129.2.28 25

Tcpdump is the fastest way to see what is actually happening on the wire. It helps you confirm packet flow, identify resets, and validate that your scans are leaving your host. This is helpful when results are inconsistent or when you suspect a firewall is modifying traffic. Pair it with Netcat or Nmap to see both the request and the response.

tcpdump -i eth0 host 10.10.14.2 and 10.129.2.28

Reference

This article is based on my personal study notes from the Information Security Foundations track.

Full repository: https://github.com/lameiro0x/pentesting-path-htb