Network Reconnaissance —
What an Attacker Sees First

Lab Environment

This lab was conducted entirely within a controlled, isolated environment. A Kali Linux Docker container was used as the scanning host, connected to a host-only Docker bridge network. No external internet-facing systems were scanned. The only target was the local Docker host (the analyst's own MacBook Pro).

Objective

The goal of this exercise was to understand what an attacker performing initial reconnaissance would see when scanning a target host — specifically, which ports are open, what services are running, and what those services reveal about the target's configuration and potential attack surface.

This is the first phase of any network intrusion: reconnaissance. Before an attacker exploits anything, they enumerate. Understanding this phase from the attacker's perspective is fundamental to building effective defenses.

Secondary objective: document the methodology and findings in a format that maps to real-world security assessment reporting.

Methodology

Two Nmap scans were conducted against the target in sequence, each building on the previous.

Scan 1 — Service Version Detection (Top 1000 Ports)

The initial scan used the -sV flag to perform service version detection against Nmap's default top 1000 most commonly used ports. This is the standard first scan in a reconnaissance sequence — fast, produces actionable results, and mirrors what an attacker would run.

┌──(root㉿kali)-[/]
└─# nmap -sV 172.17.0.1

# -sV : Probe open ports to determine service/version info
# Target: 172.17.0.1 (Docker bridge gateway / host Mac)

Starting Nmap 7.98 ( https://nmap.org ) at 2026-03-15 22:49 +0000
Nmap scan report for 172.17.0.1
Host is up (0.0000080s latency).
Not shown: 999 closed tcp ports (reset)
PORT    STATE SERVICE VERSION
111/tcp open  rpcbind 2-4 (RPC #100000)
MAC Address: 22:9B:39:9B:49:7B (Unknown)

Service detection performed.
Nmap done: 1 IP address (1 host up) scanned in 6.89 seconds

Scan 2 — Full Port Scan with Default Scripts

The second scan expanded the scope to all 65,535 TCP ports (-p-) and added Nmap's default script engine (-sC). The script engine runs a curated set of safe enumeration scripts against each discovered service — exactly what a thorough attacker would do to extract maximum information about open services.

┌──(root㉿kali)-[/]
└─# nmap -sV -sC -p- 172.17.0.1

# -sV : Service version detection
# -sC : Default NSE script scan
# -p- : All 65,535 TCP ports (not just top 1000)

Starting Nmap 7.98 ( https://nmap.org ) at 2026-03-15 22:50 +0000
Nmap scan report for 172.17.0.1
Host is up (0.0000020s latency).
Not shown: 65533 closed tcp ports (reset)
PORT      STATE SERVICE VERSION
111/tcp   open  rpcbind 2-4 (RPC #100000)
| rpcinfo:
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  3,4          111/tcp6  rpcbind
|   100000  3,4          111/udp6  rpcbind
|   100024  1          57699/tcp6  status
|   100024  1          60774/udp   status
|   100024  1          63708/udp6  status
|_  100024  1          65471/tcp   status
65471/tcp open  status  1 (RPC #100024)
MAC Address: 22:9B:39:9B:49:7B (Unknown)

Service detection performed.
Nmap done: 1 IP address (1 host up) scanned in 7.22 seconds

Findings

Two open TCP ports were identified across the full 65,535-port scan. The target presents a minimal attack surface — 65,533 ports were closed. The two open ports are both related to the RPC (Remote Procedure Call) service stack, which macOS exposes for network file sharing functionality.

Finding 1 — rpcbind (Port 111)

Port 111 is the RPC portmapper — a service that maintains a registry of which RPC programs are running and on which ports they can be reached. When the Nmap script engine queried rpcbind, it returned a full directory of registered RPC services including version numbers, port assignments, and protocol support (TCP/UDP, IPv4/IPv6).

From an attacker's perspective, rpcbind is valuable because it reveals the internal RPC service map without authentication. An attacker who can reach port 111 can enumerate every RPC service running on the target — including NFS mounts, which could expose file system access.

Finding 2 — rpc.statd (Port 65471)

rpc.statd is the NFS status monitor daemon, responsible for tracking file locks across NFS connections. It was assigned to port 65471 dynamically — the port number changes each time the service starts, which is why it wasn't found in the initial top-1000 scan but appeared in the full -p- scan.

rpc.statd has a documented history of serious vulnerabilities. CVE-2000-0800 (rpc.statd format string vulnerability) was used in real-world attacks against Linux systems. While the macOS implementation differs, the presence of this service on an externally-reachable interface warrants attention.

Security Analysis

What This Tells an Attacker

A threat actor scanning this host gets a clear picture in under 10 seconds: the target is a macOS system (inferred from the RPC service stack and MAC address vendor), it has NFS-related services running suggesting file sharing is configured, and the attack surface is otherwise minimal with 65,533 closed ports.

The combination of rpcbind + rpc.statd is a fingerprint. It tells an experienced attacker this is likely a developer workstation or small office Mac with default file sharing settings — a lower-value target but potentially a pivot point into a larger network.

Defender Perspective

The minimal number of open ports (2 out of 65,535) reflects good default security hygiene. macOS Sequoia has strong firewall defaults and does not expose services unnecessarily. The rpcbind exposure is a consequence of having any network file sharing enabled — if NFS sharing is not actively being used, disabling it would eliminate both findings.

The dynamic port assignment of rpc.statd (65471) is actually a minor defense — an attacker cannot rely on a fixed port. However, because rpcbind on 111 advertises the current port, this obfuscation provides minimal real protection.

If This Were a Defense Contractor Network

In a CMMC-regulated environment, an open rpcbind port accessible from any host on the network would be a compliance finding. NIST SP 800-171 Control 3.13.6 requires organizations to deny network communications traffic by default and allow only by exception. An RPC service exposed to the network without a documented business justification would fail this control.

NIST SP 800-171 Control Mapping

The findings from this reconnaissance exercise map directly to CMMC Level 2 controls. A real assessment against a defense contractor environment would flag these findings against the following controls:

Remediation Recommendations

Lessons Learned

Technical

The difference between the initial top-1000 scan and the full -p- scan was significant — rpc.statd on port 65471 was invisible to the first scan because it fell outside the default range. This demonstrates why thorough reconnaissance uses full port scans, and why defenders should not assume that high-numbered ports are invisible to attackers.

The -sC script engine extracted the full RPC service map from port 111 without any authentication — a single open port revealed the internal service registry. This is the information asymmetry that favors attackers: one open port, fully authenticated query, complete map returned.

Process

Setting up the Docker-based Kali lab environment required understanding Docker networking, container isolation, and the relationship between container IPs and host IPs. The Docker bridge network (172.17.0.0/16) is isolated from the host's physical network — scans run inside the container cannot reach external internet targets, which is the correct security posture for a lab environment.

Connection to Portfolio Research

The reconnaissance methodology documented here is the first step in every attack chain covered in this portfolio. The Volt Typhoon campaign began with reconnaissance of target infrastructure. The Stryker breach required identifying the administrative credential endpoint. The F-35 breach exploited a service (default credentials on a network-facing interface) that would have been identified by exactly this kind of scan. Reconnaissance is not a technical exercise — it is the foundation of every security decision that follows.

Next Lab

Lab Log 002 will cover network traffic capture and analysis using tcpdump and Wireshark inside the Kali container — capturing packets on the Docker bridge interface, identifying protocol patterns, and analyzing what network traffic reveals about host behavior. This is the defensive analog to this reconnaissance exercise: where Lab 001 asked "what can I see from outside," Lab 002 asks "what does traffic look like from inside."