5.4 Network Recon, Protocol Scanning, Sniffing, and Banner Grabbing

Network reconnaissance is the active half of 2.1 once selectors and the window are real. OSINT told you vpn.dev.example.com exists on paper and that the client hires Palo Alto administrators. Network recon asks: which in-scope addresses answer, which TCP and UDP ports are open, what software banners admit, and what a tap on the wire shows. CompTIA groups the techniques as protocol scanning (TCP/UDP), network sniffing (IoT and OT protocols), and banner grabbing. This is still information gathering — not exploitation. You are building a service list, not dropping a payload.

Tools belong mainly in the later recon-tools chapter. Here, Nmap is the usual scanner, netcat is the usual manual banner client, and Wireshark / tcpdump are the usual sniffers. The exam item is the concept, not a twenty-flag cookbook.

Protocol scanning: TCP versus UDP

TCP is connection-oriented. A client sends SYN; an open port answers SYN-ACK; a closed port answers RST (unless a filter drops the packet). That three-way handshake is why TCP scans have relatively clear open/closed/filtered logic:

• Connect scan — the OS completes the handshake. Noisy, needs no raw sockets, obvious in logs.
• SYN scan — you send SYN and then tear down; still active, still logged by anything that saw the SYN, slightly less chatty than a full connect. Incomplete handshake ≠ passive.

Filtered ports (no reply, or ICMP unreachable) are not "safe." They are unknown. Do not report a filtered port as closed.

UDP has no handshake. You send a datagram to a port. An open UDP service may reply with an application message, may reply with nothing, or may only speak after a well-formed payload. A closed port often returns ICMP port unreachable — unless a firewall eats it. That is why UDP scans are slower, more ambiguous, and easy to misread on a multiple-choice item. Common UDP interests in recon: 53 (DNS), 161 (SNMP), 123 (NTP), 500/4500 (IKE), 162 (SNMP traps), and on OT/IoT segments 1883 (MQTT), 502 (Modbus TCP), 47808 (BACnet). You still only probe them if they are in-scope.

Rate, timing, and decoys are tradecraft; RoE may cap them. Scanning a neighbor's CIDR because it "looked adjacent" is the same over-scope error Domain 1 already punished.

Sequencing on example.com

After RoE names the CIDR and domains:

1. Host discovery on the agreed CIDR (ICMP, TCP ping, ARP on a local segment — still active).
2. TCP SYN scan of agreed ports; a focused UDP pass if RoE expects DNS/VPN/OT.
3. Banner grab on what answered, especially tcp/443 for the web/VPN story.
4. Do not add payments.partner.net just because CT had it as a SAN. Do not scan "any Palo Alto" on the internet because a job post existed.

If the window is announced, tell the SOC your source IPs. If the window forbids DoS, skip aggressive UDP floods and broadcast storms. Information gathering that knocks over a PLC is not a clever scan; it is an incident.

Banner grabbing

Banner grabbing is reading the identification string a service sends when you connect — SSH version, SMTP banner, HTTP Server header, TLS certificate presented on 443, SNMP sysDescr, a Modbus device ID if OT is in-scope. Nmap -sV (service/version detection) and netcat / openssl s_client are the usual implementations. Because you completed (or at least started) a protocol conversation with the live host, banner grabbing is active reconnaissance.

Why the exam cares:

• Banners feed later vulnerability analysis (Product X version Y).
• Banners are themselves information disclosure when they leak exact versions, internal names, or debug realms.
• The TLS certificate you pull from a live 443 is how you confirm the expired CT cert is still served — OSINT hypothesized; the grab verified.

False banners exist (honeypots, reverse proxies). Record what you saw; do not over-claim a CVE from a header alone. That validation step is Domain 3. Here, grab, timestamp, screenshot, move on.

Do not write exploit payloads against the banner. Connecting to SSH to read OpenSSH_8.2 is 2.1. Using a known hole in that version is 4.x.

Network sniffing, including IoT and OT protocols

Network sniffing captures frames on a path you are authorized to see: a SPAN/mirror, a tap, a test VLAN, a wireless monitor session if wireless is in-scope, or a host firewall dump the client provided. Wireshark and tcpdump are the named tools you will see again in 2.4. Sniffing answers questions scans miss: cleartext credentials, talking peers that are not in DNS, and IoT/OT protocols that never banner the way HTTP does.

CompTIA explicitly calls out IoT and OT protocols. On many plant, building-automation, and IoT segments, MQTT, Modbus, and BACnet (and similar) still run without TLS. A capture then is the recon: topic names, register reads, device IDs, sometimes credentials in CONNECT packets. That is information disclosure on a sensitive network.

Rules that keep you employed:

• Sniffing requires authorized presence on that segment. It is not a CT-log lookup. Plug-in, VPN, or SPAN access should be in the SoW.
• Observation is not process control. Seeing Modbus function codes does not authorize writing registers, changing setpoints, or replaying commands at a PLC. OT testing needs explicit RoE, a safety contact, and usually a maintenance window. Replay and register manipulation are Domain 4 specialized-system attacks.
• Capture files contain production data. Store them under the same evidence rules as screenshots of ePHI or card data. Do not copy a PCAP to a home laptop.

"Passive sniffing" (no injected packets) versus "active sniffing" (ARP spoofing to get the frames) is a useful network distinction. ARP spoofing is an on-path attack unless RoE allowed it. For 2.1 classification against OSINT: if you had to join the client's wire, you left the passive-OSINT box.

Putting 2.1 together

Information gathering on PT0-003 is a pipeline, not a tool list. Passive OSINT (social, jobs, repos, dumps, crypto leaks, DNS, CT, search, cache) produces candidates. Authorization turns candidates that match selectors into active network recon (TCP/UDP scans, banners, in-scope sniffing, live HTML scrape). Information disclosure is the usual finding name for what leaked along the way. The next chapter stays in Domain 2 but shifts from gathering to enumeration of OS, services, directories, and shares — still not exploitation.