Network Reconnaissance with Nmap on Kali Linux

Network reconnaissance answers three questions before you run exploit modules:

• Which hosts are alive on the network you are allowed to test
• Which ports accept connections on those hosts
• What software listens behind those open ports

Nmap is the standard mapper on Kali for that job. You start with host discovery, move to TCP and UDP port scans, then layer service version and OS fingerprinting on the addresses your engagement authorizes. On an Ubuntu workstation, install the same nmap package from Ubuntu apt before you scan—see install Kali Linux tools on Ubuntu safely (no Kali repository required).

Demos that need a public Internet target use scanme.nmap.org, which the Nmap project maintains for practice scans. Follow their usage limits:

• Run no more than about a dozen scans per day against that host
• Avoid denial-of-service traffic
• Do not run exploit scripts there

Nmap network reconnaissance quick start on Kali

Export these variables once and reuse them in every command below:

export TARGET=192.168.56.127
export LAB_NET=192.168.56.0/24
export SCAN_HOST=scanme.nmap.org
# Proxmox Group 2 lab: export TARGET=10.10.10.30

Before you run the commands below:

• Lab target — TARGET defaults to 192.168.56.127 (Metasploitable 2 on the VirtualBox host-only lab). Confirm the address in your pentest lab guide if your layout differs.
• Internet from Kali — Demos against $SCAN_HOST need outbound Internet access. That host is maintained for practice scans only; keep volume low and avoid exploit scripts there.
• Root vs non-root — SYN (-sS), UDP (-sU), and OS detection (-O) need sudo on Kali. TCP connect (-sT) works as a normal user when raw sockets are blocked.
• Missing package — Install or refresh nmap with apt in the tools section if nmap --version fails.

If you only need a fast sanity check, confirm Nmap is installed and probe one authorized target:

nmap --version

Nmap version 7.99 ( https://nmap.org )

Run a lightweight host discovery pass on Metasploitable:

nmap -sn "$TARGET"

Nmap scan report for 192.168.56.127
Host is up (0.00082s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.82 seconds

Your Metasploitable IP will differ if you changed TARGET for a non-default lab layout (for example Proxmox Group 2 at 10.10.10.30).

A positive Host is up line here means discovery probes got a response. If discovery fails but you know the VM is online, skip discovery with -Pn on the port scan instead of combining -sn with -Pn.

Most beginners first encounter Nmap as a single target argument:

nmap "$TARGET"

With no scan type specified, Nmap runs a default workflow:

• Host discovery first — probes whether the target responds
• Port scan second — checks Nmap's default set of commonly used TCP ports on hosts it considers up
• Scan technique — SYN scanning when you run Nmap as root on Linux; TCP connect scanning as an unprivileged user

The focused examples below break that default workflow into discovery, port selection, and fingerprinting steps you can tune per engagement.

What is network reconnaissance in ethical hacking?

Reconnaissance collects facts about a target environment. Active network reconnaissance sends packets from your scanner and reads the replies. Depending on the flags you choose, those probes may hit host discovery, port scans, version probes, or OS detection stacks.

Nmap phases map cleanly to PenTest+ style workflows:

• Host discovery finds addresses that respond on the segment you are allowed to test
• Port scanning lists TCP and UDP listeners that may expose services
• Service detection maps open ports to product names and version strings for vendor-advisory research
• OS fingerprinting adds a hypothesis about the kernel and platform, which you still verify manually

This is not exploitation. It feeds later steps such as banner grabbing, DNS enumeration, and targeted vulnerability checks.

Nmap target forms and install

Every command below reuses the exports from the quick-start block. Nmap accepts several target forms. Network reconnaissance often starts from a range, not a single IP you already know:

The variables above map to these patterns — $TARGET for one lab host, $LAB_NET for a subnet sweep, $SCAN_HOST for the public practice hostname.

Install or refresh the package if your image is missing it. Use apt to pull nmap from the Kali repositories:

sudo apt update
sudo apt install -y nmap

Metasploitable-specific scans run from Kali on the private lab network. Commands against scanme.nmap.org need outbound Internet access from Kali.

Discover live hosts with Nmap

Host discovery answers whether an address responds before you spend time on a full port scan. On a local Ethernet segment, Nmap can also report MAC addresses when you run it as root.

Sweep the lab subnet you are authorized to test:

nmap -sn "$LAB_NET"

Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-30 21:19 -0700
Nmap scan report for 192.168.56.1
Host is up (0.00093s latency).
MAC Address: 0A:00:27:00:00:07 (Unknown)
Nmap scan report for 192.168.56.120
Host is up (0.00074s latency).
MAC Address: 08:00:27:8E:6B:2F (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.127
Host is up (0.00098s latency).
MAC Address: 08:00:27:33:AF:98 (Oracle VirtualBox virtual NIC)
Nmap done: 256 IP addresses (3 hosts up) scanned in 3.66 seconds

On the canonical VirtualBox host-only lab with DHCP disabled, expect three live addresses: 192.168.56.1 (VirtualBox host gateway), 192.168.56.120 (Kali), and 192.168.56.127 (Metasploitable). The summary line tells you how many hosts answered on that sweep. Substitute your own LAB_NET if VirtualBox or Proxmox assigned a different range.

When ICMP echo is blocked, TCP probes to common ports can still prove a host is up. A single hping3 command SYN to one port is a lighter check before you widen the sweep. Add -sn so Nmap stops after discovery and does not port-scan:

nmap -sn -PS22,80 "$SCAN_HOST"

Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-30 21:18 -0700
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.022s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds

As root, -PS sends raw SYN discovery probes. Without root privileges, Nmap falls back to a TCP connect() attempt for the same discovery purpose.

Use -Pn when you already know the host is online but discovery probes lie about reachability:

• -Pn skips host discovery and tells Nmap to treat the target as up
• It does not prove the host responded — it only removes the discovery stage
• Port scans that follow -Pn can still show open services

Demonstrate the flag on the practice host:

nmap -Pn "$SCAN_HOST"

Common host-discovery flags:

TCP port scanning with Nmap

TCP scans reveal which ports accept connections. As root on Kali, Nmap defaults to a SYN (-sS) half-open scan. Without root privileges, it falls back to a full TCP connect (-sT) scan.

Compare the two techniques:

Understand Nmap port states

You will see these states throughout TCP and UDP output:

Run a focused SYN scan against Metasploitable on the ports you expect to be open in the training image:

sudo nmap -Pn -sS -p 22,80,445 --open "$TARGET"

Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-30 21:21 -0700
Nmap scan report for 192.168.56.127
Host is up (0.040s latency).
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
445/tcp open  microsoft-ds
Nmap done: 1 IP address (1 host up) scanned in 0.98 seconds

The --open filter hides closed ports so you can read the listening services faster.

A connect scan against the public practice host shows the same ports through the full handshake path:

nmap -sT -p 22,80 "$SCAN_HOST"

Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.034s latency).

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 1.50 seconds

Both ports were open from this Kali path on retest. SSH can still show filtered from other networks or when a firewall sits between you and the target — that is why lab work on $TARGET and spot checks on $SCAN_HOST complement each other.

UDP port scanning with Nmap

UDP services such as DNS, SNMP, and DHCP do not use TCP handshakes. A UDP scan (-sU) is slower because many ports return no response, and open|filtered is common when silence could mean either an open port or a dropped probe.

Sample the top ten UDP ports on the practice host:

sudo nmap -Pn -sU --top-ports 10 "$SCAN_HOST"

Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-30 21:18 -0700
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.052s latency).

PORT     STATE         SERVICE
53/udp   open          domain
67/udp   open|filtered dhcps
123/udp  open|filtered ntp
135/udp  open|filtered msrpc
137/udp  open|filtered netbios-ns
138/udp  open|filtered netbios-dgm
161/udp  open|filtered snmp
445/udp  open|filtered microsoft-ds
631/udp  open|filtered ipp
1434/udp open|filtered ms-sql-m

Nmap done: 1 IP address (1 host up) scanned in 3.07 seconds

Only port 53/udp returned a definitive open state here. The open|filtered lines need follow-up with a service-specific check or a narrower -p list on $TARGET in your lab. Plan extra time for UDP; retransmissions are common on busy networks.

Service and version detection with -sV

Once you know a port is open, -sV sends additional probes to fingerprint the service name and version string. Use the VERSION column as a starting point for vendor-advisory and CVE research, then confirm the detected product and version before you treat a vulnerability as applicable.

Scan common Metasploitable services:

sudo nmap -Pn -sV --version-light -p 21,22,80,139,445,5900 "$TARGET"

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 2.3.4
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
80/tcp   open  http        Apache httpd 2.2.8 ((Ubuntu) DAV/2)
139/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
5900/tcp open  vnc         VNC (protocol 3.3)

Run the same mode against the Internet practice host:

nmap -Pn -sV --version-light -p 22,80 "$SCAN_HOST"

Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.032s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.13 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Tune --version-intensity when the default probe set is not enough:

• Higher values try more service probes — useful on unusual ports, but slower and noisier
• Lower values speed up sweeps across many hosts when a rough service name is enough
• --version-light (used above) is a practical middle setting for lab demos

OS fingerprinting with -O

OS detection sends a series of TCP, UDP, and ICMP probes and compares the replies to Nmap's signature database. Treat the result as a hypothesis until you corroborate it with package versions or local access.

Fingerprint Metasploitable:

sudo nmap -Pn -O --osscan-guess -p 22,80 "$TARGET"

Nmap scan report for 192.168.56.127
Host is up (0.0019s latency).
...
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33
Network Distance: 1 hop

On minimal port lists, Nmap may warn that OS guesses are unreliable. Give it at least one open and one closed port when you need higher confidence.

Internet targets with few open ports often produce low-confidence guesses:

sudo nmap -Pn -O --osscan-guess -p 22,80 "$SCAN_HOST"

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: AT&T BGW210 voice gateway (93%), Oracle Virtualbox (92%), ...
No exact OS matches for host (test conditions non-ideal).

That warning is expected on filtered Internet paths. Rely on -sV service lines when OS detection cannot stabilize.

Nmap's -A option bundles several reconnaissance features in one profile:

• OS detection (-O)
• Version detection (-sV)
• Default NSE scripts
• Traceroute

It is convenient for a focused authorized target, but it generates substantially more probes than a staged scan, so this guide demonstrates the components separately. When you want the combined profile on Metasploitable:

sudo nmap -Pn -A "$TARGET"

Review the open ports, version strings, and script output before you widen the scan to more hosts.

Port selection, timing, and performance

By default Nmap scans the top 1000 TCP ports. Tighten or widen the list when scope demands it.

Timing templates (-T0 through -T5) trade speed against probe rate and load:

• -T3 — default balance for most lab work
• -T4 — faster on reliable local networks
• -T2 — longer delays between probes; use when scope or network policy requires a slower rate
• -T0 and -T1 — very slow; rarely needed outside specialized engagements

Compare fast mode on the practice host with -T4:

nmap -T4 -F "$SCAN_HOST"

On the test Kali host this fast scan finished in about seven seconds. The same command at -T2 took roughly ninety-four seconds because Nmap waited longer between probes.

Add -n to skip reverse DNS when you already have IP addresses and want to save time on large sweeps.

Nmap Scripting Engine for reconnaissance

The NSE extends Nmap with Lua scripts. Before you run any script category:

• The safe category is intended for scripts considered lower risk than intrusive or exploit-oriented scripts — category membership is not a substitute for reviewing the individual script and engagement scope
• Every script still sends active traffic and may be out of scope on some engagements
• Confirm authorization before you run scripts against a target

Pull the SSH banner with the banner script on the practice host:

nmap -Pn --script=banner -p 22 "$SCAN_HOST"

PORT   STATE SERVICE
22/tcp open  ssh
|_banner: SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13

Count how many NSE scripts ship with your build when you need to explore further:

ls /usr/share/nmap/scripts/*.nse | wc -l

612

Kali Rolling 2026.2 ships 612 NSE scripts in this build. Do not run exploit, intrusive, or brute-force script categories against systems outside your written scope. For category selection, --script-args, and enumeration automation, continue with Nmap NSE scripts for enumeration.

Save Nmap output for reporting

Export results when you need evidence for a client report or a course lab submission.

Write all three formats in one pass:

nmap -oA scanme-demo -Pn -p 22,80 "$SCAN_HOST"

Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.032s latency).

PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.60 seconds

Nmap also creates scanme-demo.nmap, scanme-demo.xml, and scanme-demo.gnmap in the current directory.

Zenmap GUI (optional)

Zenmap is the official graphical front end for Nmap on Kali. It runs the same scans as the CLI through built-in profiles. Install it when you want a click-through workflow instead of memorizing flags:

sudo apt install -y zenmap

Launch with zenmap from the applications menu or a terminal. Point it at scanme.nmap.org or $TARGET and pick Regular scan for a lab demo.

Troubleshooting

Summary

You walked through the core Nmap reconnaissance chain on Kali: host discovery with -sn and -sn -PS, TCP SYN and connect scans, a sampled UDP pass, service fingerprinting with -sV, and OS guesses with -O. Lab work on Metasploitable stays on your private pentest lab segment as $TARGET, while $SCAN_HOST gives you a safe Internet path for the same flags when you need outbound access — keep scan volume low on that public target.

Filtered ports and weak OS guesses are common on real networks, not tool failures. Record open ports and version strings first, then deepen with banner checks or DNS enumeration on the hosts your scope allows. Export with -oA when you need artifacts for a report.

For flag-level reminders during live engagements, keep the Nmap command cheat sheet open beside this walkthrough. When reconnaissance confirms exploitable services on Metasploitable, continue with the Metasploitable 2 exploitation walkthrough.

References

• Nmap reference guide
• Nmap host discovery
• Nmap port scanning
• Nmap service and version detection
• Nmap OS detection
• Nmap timing and performance
• Nmap output formats
• Nmap Scripting Engine
• scanme.nmap.org practice target
• Zenmap user guide