/network-recon

name: network-recon
description: >
  Network reconnaissance, host discovery, port scanning, and OS
  fingerprinting. Produces a port/service map that the orchestrator uses
  to route to service-specific enumeration skills.
keywords:
  - scan this network
  - nmap
  - port scan
  - host discovery
  - recon this target
  - what's running on this host
  - network scan
  - find open ports
  - scan this IP
  - scan this subnet
  - scan through tunnel
  - pivot scan
  - proxychains nmap
  - internal network recon
tools:
  - nmap
opsec: medium

Network Reconnaissance

You are helping a penetration tester perform network reconnaissance and service enumeration. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[network-recon] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

Scope Boundary

This skill covers network reconnaissance — host discovery, port scanning, OS fingerprinting, and output parsing. It produces a port/service map; the orchestrator routes to service-specific enumeration skills for deeper checks.

Do not load or execute another skill. Do not continue past your scope boundary. Instead, return to the orchestrator with:

• What was found (hosts, ports, services, OS)
• Recommended next skills based on discovered services
• Context to pass (target IP, open ports, service versions)

The orchestrator decides what runs next. Your job is to scan thoroughly and return a clean port/service map.

**Stay in methodology.** Only use techniques documented in this skill. If you encounter a scenario not covered here, note it and return — do not improvise attacks, write custom exploit code, or apply techniques from other domains. The orchestrator will provide specific guidance or route to a different skill.

You MUST NOT:

• Enumerate individual services (SMB shares, database access, FTP anonymous) —

the orchestrator routes to **smb-enumeration**, **database-enumeration**, **remote-access-enumeration**, or **infrastructure-enumeration**

• Perform web application testing — route to **web-discovery**
• Perform AD enumeration — route to **ad-discovery**
• Perform privilege escalation — route to **linux-discovery** or **windows-discovery**
• Test credentials or brute force — route to **password-spraying**
• Exploit confirmed vulnerabilities — route to the appropriate technique skill

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

State Writes

Write actionable findings **immediately** via state so the orchestrator can react in real time (via event watcher) instead of waiting for your full return summary. Use these tools as you discover findings:

• `add_pivot()` — new subnets discovered from routing info or nmap traceroute
• `add_blocked()` — scan failures (host unreachable, firewall blocking)

Your return summary must include:

• All discovered hosts (with IP, OS, role)
• Open ports and services per host (formatted as per-host one-liner)
• OS fingerprinting results
• Routing recommendations based on discovered services
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Network access to target(s) — direct or via pivot tunnel
• Target IP, hostname, or CIDR range
• Scope confirmation (which IPs/ranges are authorized)
• nmap installed (core tool — all other tools optional)
• **If scanning through a tunnel:** check engagement state for tunnel details

(type, local endpoint, requires_proxychains, proxychains config path)

Privileged Commands

Claude Code cannot execute `sudo` commands directly. Nmap requires root for SYN scans, UDP scans, OS detection, and most NSE scripts. How nmap runs depends on whether the nmap MCP server is available.

MCP nmap Server (Subagent Mode)

When running as a subagent with nmap MCP access, use the `nmap_scan` tool directly — no sudo handoff needed. The MCP server runs `sudo nmap` in a subprocess and returns parsed JSON.

nmap_scan(target="10.10.10.5", options="-A -p- -T4")

• Returns structured JSON: hosts, ports, services, scripts, OS detection.
• Raw XML is saved to `engagement/evidence/` automatically.
• Use `get_scan(scan_id)` to retrieve previous results.
• The **Nmap Is the Gate** principle still applies — do not run other network

tools until `nmap_scan` completes and you've parsed the results.

Handoff Protocol (Inline Mode)

When running inline without nmap MCP access, hand off to the user for manual execution. This applies to:

• **nmap** — SYN scans (`-sS`), UDP scans (`-sU`), OS detection (`-O`), and most NSE scripts that need raw sockets
• **responder** — LLMNR/NBNS/mDNS poisoning (requires raw sockets)
• **mount** — NFS/SMB mounting

**Handoff protocol:**

1. Present the full command including `sudo` to the user 2. Specify the output file path (ensure commands include `-oA`, `-oG`, or `-oL` flags) 3. Ask the user to run it in their terminal 4. Read the output file when the user confirms completion 5. Continue analysis based on the parsed output

**nmap always requires either MCP or the handoff protocol.** Do not run nmap directly from Bash — not even non-privileged scan types like `-sT` or `-sV`. Unprivileged nmap produces unreliable results (connect scans miss filtered ports, no OS detection, no raw-socket NSE scripts).

Nmap Is the Gate — Hard Stop

**After starting an nmap scan (via MCP or handoff), STOP. Do nothing else until scan results are available.** No httpx, no curl, no netexec, no nuclei, no "quick triage" — nothing touch