Active Reconnaissance -- Multi-Protocol Scanning

Step 1: Review passive intelligence

Before running any scans, open your passive reconnaissance summary from Unit 2. The findings from certificate transparency, Shodan, and Google dorks tell you where to focus.

Passive intelligence narrows your scan. Instead of scanning every port on every protocol, you use what you already know to make deliberate choices about what to scan first. If Shodan showed specific open ports, those are confirmed targets. If certificate transparency revealed subdomains, those might indicate additional services. Your passive findings become your scanning strategy's starting point.

Refer to materials/ttp-selection-guide.md -- the active reconnaissance category describes multi-protocol scanning, OS detection, and content discovery as the approaches available. You decide the specifics.

Step 2: UDP scanning

In P2, you scanned with TCP only. TCP scanning gives reliable results because the three-way handshake either completes (open) or does not (closed/filtered). UDP scanning is fundamentally different.

UDP is connectionless. When Nmap sends a UDP probe and receives no response, it cannot tell whether the port is open (the service received the packet but did not reply), filtered (a firewall silently dropped the packet), or something else entirely. Nmap reports this as "open|filtered" -- a state that means "I don't know."

Direct Claude to run a UDP scan against key ports on the target.

Run an Nmap UDP scan against the target. Scan the top 20 UDP ports. Save the output in all three formats: normal, XML, and grepable.

When you review the results, pay attention to how the output looks compared to TCP scans. TCP results say "open" or "closed" with confidence. UDP results say "open|filtered" with ambiguity. AI commonly presents UDP "open|filtered" results with the same confidence as TCP "open" results -- it will tell you a port is open when Nmap is actually saying it does not know.

The output format choice matters too. Saving in XML enables downstream processing with tools that parse Nmap XML. The grepable format is useful for quick command-line filtering. Normal is readable but harder to process programmatically. Choosing the right format is a workflow decision, not just a preference.

Step 3: OS detection

Direct Claude to run OS detection against the target.

Run Nmap OS detection against the target. Include the results alongside the service version information.

Nmap's OS detection is probabilistic. It compares the target's TCP/IP fingerprint against a database of known operating systems and reports match percentages. A result like "Linux 5.4 - 5.15 (95%)" means Nmap is 95% confident, not 100%. A result with 85% confidence and a second guess at 80% means Nmap is not sure.

AI commonly reports OS detection results as definitive fact. It will say "the server runs Ubuntu 22.04" when Nmap actually said "Linux 5.x (92%)." The match percentage and the presence of multiple guesses are the signals that tell you how much to trust the result. Read the numbers, not just the conclusion.

Step 4: Scan timing decisions

Scan timing is a design decision with consequences on both sides.

Nmap's timing templates range from -T0 (paranoid) to -T5 (insane). Aggressive timing (-T4, -T5) sends packets rapidly, completing scans in seconds but generating burst traffic that any monitoring tool flags instantly. Polite timing (-T2, -T3) spaces packets out, taking longer but producing traffic patterns that blend more with normal activity.

Choose a timing profile and explain your reasoning. There is no universally correct choice -- it depends on whether you want to test the monitoring's ability to detect fast scans (use aggressive) or its ability to catch subtle activity (use polite).

Run an Nmap TCP SYN scan against the target with the timing profile I chose. Use -T[your choice] and explain what that timing means for packet rate and detection risk.

After the scan completes, open Grafana and check the logs. Find your scan in the log stream. What does it look like from the defender's side? If you chose aggressive timing, the burst should be obvious. If you chose polite timing, it may be harder to distinguish from normal traffic. This is a preview of the detection challenge in Unit 4.

Step 5: Content discovery with ffuf

ffuf is a content discovery tool. It brute-forces directory and file paths against a web server, discovering endpoints that are not linked from the application's visible pages -- admin panels, backup files, configuration files, development endpoints that were never meant to be public.

Direct Claude to run ffuf against the ordering platform.

Run ffuf against the target web application on port 8080. Use a common wordlist for directory and file discovery. Filter out 404 responses.

Review the results. Look for paths that suggest administrative interfaces, API endpoints, backup files, or developer tools. Cross-reference what ffuf finds with what your passive reconnaissance already discovered -- are there endpoints that only active discovery reveals?

Step 6: Packet-level analysis with Wireshark

Nmap tells you what it determined. Wireshark shows you what happened on the network.

Wireshark (or its command-line version, tshark) captures every packet that crosses the network interface. When you capture during an Nmap scan, you see the actual SYN packets Nmap sends, the SYN-ACK responses from open ports, the RST packets from closed ports, and the silence from filtered ports. This is a different perspective from Nmap's summary report.

Start a packet capture and run a short Nmap scan.

Start a tshark capture on the relevant network interface. While it runs, execute a short Nmap SYN scan against the target. Stop the capture after the scan completes. Review the captured packets.

Compare the capture with Nmap's report. For ports Nmap reported as "open," find the SYN-ACK packets. For ports reported as "closed," find the RST packets. For "filtered" ports, look for the absence of any response. The gap between what the tool reports and what happened on the wire builds understanding of what scanning actually does at the network layer.

Step 7: Document active reconnaissance findings

Compile your active scanning results into a structured report. This document extends the passive intelligence summary from Unit 2 with active findings.

Compile active reconnaissance findings. For each finding, include the scan type (UDP/TCP/OS/content discovery), what was found, the confidence level, and the scan strategy rationale. Note the timing choice and its detection consequences observed in Grafana.

The final document should cover: multi-protocol scan results with UDP ambiguity explicitly noted, OS detection with match percentages and confidence language, content discovery findings, the scan timing decision and what it looked like in the logs, and any packet-level observations from Wireshark that revealed differences between what Nmap reported and what happened on the network.

Refer back to materials/scope-document.md to confirm that all scanning stayed within scope boundaries.