---

name: network-network-recon description: You are helping a penetration tester perform network reconnaissance and service sources: community, blacklanternsecurity/red-run

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 touches the network until nmap results are parsed. The nmap scan is the foundation. Every subsequent decision — which services to enumerate, which skills to route to, which quick wins to check — depends on knowing the full port and service landscape. Running tools before nmap completes wastes time on assumptions, produces duplicate traffic, and risks missing the ports that actually matter.

Non-privileged commands that CAN be executed directly by Claude for post-scan service enumeration (only AFTER nmap results are parsed):

• httpx, netexec, nuclei, whatweb, ffuf
• ldapsearch, smbclient, rpcclient, snmpwalk

Batch all pending privileged commands so the user can run them in one pass. Present them as a numbered list, each with its output file path.

Step 1: Host Discovery

Identify live hosts in the target range. Skip for single-host targets.

# ARP ping (fastest — same subnet only)
sudo nmap -sn -PR 10.10.10.0/24 -oG discovery.gnmap

# ICMP echo + TCP SYN(80,443) + TCP ACK(80) + ICMP timestamp (default -sn)
sudo nmap -sn 10.10.10.0/24 -oG discovery.gnmap

# TCP-only host discovery (ICMP blocked)
sudo nmap -sn -PS22,80,135,443,445,3389,8080 10.10.10.0/24 -oG discovery.gnmap

# UDP host discovery
sudo nmap -sn -PU53,161,137 10.10.10.0/24 -oG discovery.gnmap

# Combined — most thorough
sudo nmap -sn -PE -PP -PS21,22,25,80,113,135,443,445,3389,8080 -PU53,111,137,161 10.10.10.0/24 -oG discovery.gnmap

Parse live hosts for next steps:

# Extract live hosts from nmap greppable output
grep "Status: Up" discovery.gnmap | awk '{print $2}' > live_hosts.txt

Present the list of live hosts. Ask which to scan further or proceed with all.

Pivot Mode — Scanning Through a Tunnel

When the orchestrator says you're scanning through a tunnel (chisel SOCKS, SSH dynamic forward, ligolo, etc.), everything changes. Nmap through proxychains is extremely slow — a /24 with top-1000 ports means 256,000 TCP connect attempts through SOCKS, each timeout ~15 seconds. A full subnet scan can take hours and often times out.

Check the engagement state (get_state_summary()) for tunnel details. The Tunnels section tells you the tunnel type, local endpoint, whether proxychains is required, and which hosts are already known-live.

The nmap MCP Server Does NOT Support Proxychains

The nmap_scan MCP tool runs nmap directly — it cannot route through SOCKS proxies. When scanning through a tunnel that requires proxychains, you MUST use Bash with dangerouslyDisableSandbox: true instead of the nmap MCP server.

All nmap commands through proxychains require these flags:

proxychains4 -f <config_path> nmap -sT -Pn -n [other options] TARGET

• -sT — TCP connect scan (only scan type that works through SOCKS)
• -Pn — skip host discovery (ICMP doesn't work through SOCKS)
• -n — no DNS resolution (avoid DNS leaks outside the tunnel)
• No -sS, -sU, -O, or raw-socket features — SOCKS is TCP-only

Two-Phase Approach (Required for Pivot Scanning)

Never scan an entire subnet with nmap through proxychains. Instead, use a fast Phase 1 to find live hosts, then targeted Phase 2 for port/service detail.

Phase 1: Fast Host Discovery

Use lightweight methods that are much faster than nmap through SOCKS. Try these in order — use whichever works for your access level on the pivot host.

Option A — Commands on the pivot host via existing shell session. If you have a shell on the pivot host (WinRM, SSH, reverse shell), run discovery commands directly on it. No proxychains overhead — these execute locally on the internal network.

Windows pivot host:

# ARP cache — already-known neighbors (instant)
arp -a

# DNS zone dump — if pivot host is a DC or has DNS access
Get-DnsServerResourceRecord -ZoneName <domain> -RRType A | Select-Object HostName, @{N='IP';E={$_.RecordData.IPv4Address}}

# Ping sweep (fast, covers the subnet)
1..254 | ForEach-Object { $ip="192.168.100.$_"; if(Test-Connection -Count 1 -Quiet -TimeoutSeconds 1 $ip){$ip} }

# PowerShell TCP port check on specific hosts (confirm specific services)
Test-NetConnection -ComputerName 192.168.100.2 -Port 445 -InformationLevel Quiet

Linux pivot host:

# ARP cache
arp -a

# Ping sweep
for i in $(seq 1 254); do ping -c1 -W1 192.168.100.$i &>/dev/null && echo "192.168.100.$i alive" & done; wait

# Bash TCP check (no tools needed)
for port in 22 80 135 445 3389 5985; do
  (echo >/dev/tcp/192.168.100.2/$port) 2>/dev/null && echo "192.168.100.2:$port open"
done

Option B — Single-port sweep through proxychains. If you can't run commands on the pivot host, sweep one common port across the subnet. Much faster than scanning many ports per host.

# SMB sweep — fast, catches Windows hosts
proxychains4 -f <config> nxc smb 192.168.100.0/24 --timeout 5 2>&1 | grep -v "timeout"

# Or nmap with a SINGLE port — minimize SOCKS overhead
proxychains4 -f <config> nmap -sT -Pn -n -p 445 192.168.100.0/24 --open -oG pivot_discovery.gnmap

Option C — Combined approach (best results). Run ARP + ping sweep on the pivot host first, then validate with a single-port proxychains sweep to catch hosts that block ICMP.

After Phase 1, collect the list of confirmed live hosts. Only these hosts proceed to Phase 2.

Phase 2: Targeted Port Scanning

Scan ONLY the live hosts found in Phase 1. Use focused port lists, not -p-.

# Common Windows ports — covers most AD/enterprise services
proxychains4 -f <config> nmap -sT -Pn -n -p 21,22,25,53,80,88,110,135,139,143,389,443,445,464,587,636,993,995,1433,2049,3268,3306,3389,5432,5985,5986,8080,8443,9389 <live_host> -oA pivot_scan_HOSTNAME

# If you already know the OS (e.g., from Phase 1 SMB banner), narrow further:
# Windows server — core ports
proxychains4 -f <config> nmap -sT -Pn -n -p 80,88,135,139,389,443,445,636,1433,3268,3389,5985,5986,8080 <live_host> -oA pivot_scan_HOSTNAME

# Linux server — core ports
proxychains4 -f <config> nmap -sT -Pn -n -p 21,22,25,53,80,110,139,143,443,445,993,2049,3306,5432,8080 <live_host> -oA pivot_scan_HOSTNAME

Service version detection — only on confirmed open ports:

# After finding open ports, run -sV on JUST those ports
proxychains4 -f <config> nmap -sT -Pn -n -sV -p <open_ports_csv> <live_host> -oA pivot_svc_HOSTNAME

**Ti