Host discovery & port scanning¶

MITRE ATT&CK: T1018 Remote System Discovery · T1046 Network Service Discovery · Tactic: Discovery · Last updated: 2026-10-13

Summary

Find which hosts are alive (-sn), then which ports answer (-sS, -sT, -sU). The skill is reading the state Nmap assigns and knowing what each state says about the network in between.

Host discovery¶

sudo nmap 10.129.2.0/24 -sn -oA tnet | grep for | cut -d" " -f5
sudo nmap 10.129.2.18 -sn -PE --packet-trace --reason

Flag	Meaning
`-sn`	Host discovery only, skip the port scan
`-PE`	Use ICMP Echo requests
`-PS`/`-PA`/`-PU`	TCP SYN / TCP ACK / UDP discovery probes
`-Pn`	Skip discovery, treat every host as up (use when ICMP is blocked)
`-n`	No DNS resolution (faster, quieter in DNS logs)
`--disable-arp-ping`	On a local segment Nmap uses ARP by default; this forces ICMP
`--packet-trace`	Show each packet
`--reason`	Show why a state was assigned (e.g. `arp-response`, `syn-ack`)

On the same Layer-2 segment Nmap prefers ARP, which cannot be filtered by host firewalls. reason: arp-response in the output tells you that is what answered. Across routers it falls back to ICMP echo, so a host that drops ICMP looks dead; rerun with -Pn.

TTL is a rough OS hint: ~64 is typically Linux/Unix, ~128 Windows, ~255 network gear.

Port states¶

State	Meaning
`open`	A service accepted the connection (SYN-ACK)
`closed`	Host replied RST — reachable but nothing listening
`filtered`	No reply, or an ICMP error — a firewall is hiding the answer
`unfiltered`	Reachable, but can't tell open vs closed (ACK scan only)
`open\\|filtered`	No response; open or dropped (UDP, FIN/NULL/Xmas)
`closed\\|filtered`	Can't tell closed from filtered (idle scan only)

DROP vs REJECT¶

A firewall that DROPs silently gives Nmap nothing back, so the port shows filtered after retries (slow). A firewall that REJECTs sends an ICMP error such as type 3 code 3 (port unreachable) or an RST, which is fast and also shows filtered/closed. With --packet-trace --reason you can tell them apart: no-response means DROP, port-unreach or reset means REJECT. That tells you where the filtering sits and how fast the target can be scanned.

Scan types¶

Scan	Flag	What happens	Notes
SYN ("half-open")	`-sS`	SYN → SYN-ACK → RST	Default as root. Never completes the handshake
TCP Connect	`-sT`	Full 3-way handshake	Default without root; ends up in application logs
ACK	`-sA`	ACK only	Maps firewall rules (`filtered` vs `unfiltered`), cannot find open ports
UDP	`-sU`	Empty or protocol-specific datagram	ICMP type 3 code 3 = closed; reply = open; silence = `open\\|filtered`. Slow

$ sudo nmap 10.129.2.28 -p 80 -sS --packet-trace -Pn -n --disable-arp-ping
SENT (0.0429s) TCP 10.10.14.2:63090 > 10.129.2.28:80 S ttl=56 ...
RCVD (0.0573s) TCP 10.129.2.28:80 > 10.10.14.2:63090 SA ttl=64 ...
PORT   STATE SERVICE
80/tcp open  http

S is the SYN we sent, SA is SYN-ACK so the port is open. An RA reply would mean closed.

UDP needs patience: -sU --top-ports 100 first, then target specific ports with -sV, because a version probe is often the only way to get a UDP service to answer.

Pentester view¶

Full TCP first (-p-), top UDP ports second, run in the background.
On a lab, --min-rate 1000 is fine. On a client production network stay conservative and agree on a rate.
A port that stays filtered isn't "closed": note it and retry from another source host or path if scope allows.

Defender view¶

SYN scan leaves S0/REJ in Zeek conn_state and never reaches the application log, so firewall and network sensors catch it where host logs do not.
Connect scan (-sT) shows up in service logs (e.g. SSH "connection closed by ... [preauth]", web access logs).
A flood of ICMP type 3 from one host is often the target answering a UDP scan.