PT0-002 Reconnaissance and Enumeration Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  TCP connect scan (-sT)

  Why it's wrong here

  TCP connect scan (-sT) uses the operating system's connect() system call to perform a full three-way handshake with the target port. When the handshake completes, the port is marked open, but the session is fully established, which is far more intrusive and likely to be logged by firewalls, IDS/IPS, and application servers. The scan is slower because it must wait for the handshake to complete for every port and may also have to retrieve a service banner. While -sT is a valid fallback when raw socket privileges are unavailable, it sacrifices stealth for compatibility, making it a poor choice when the client wants to minimize detection.

• ✗

  UDP scan (-sU)

  Why it's wrong here

  UDP scan (-sU) sends UDP datagrams to target ports and expects an ICMP port unreachable response to mark a port closed, but it does not interact with TCP ports at all. If the target service is TCP-based, this scan will yield no useful port state information, because the TCP stack will not respond to UDP probes. Additionally, UDP scanning is slow and unreliable: open UDP ports often silently drop packets, and ICMP responses from closed ports are frequently rate-limited, leading to false negatives or indeterminate results. Therefore, -sU is not merely less stealthy for TCP services; it is fundamentally incompatible with the goal of scanning TCP port states.

• ✓

  SYN scan (-sS)

  Why this is correct

  SYN scan (-sS) sends a bare SYN packet to each port, and if a SYN/ACK is returned, the port is considered open; the scan then immediately replies with an RST to tear down the half-open connection before the handshake completes. This avoids creating a full TCP session, so the target application never sees a completed connection, making it far less likely to appear in application-level logs. Because it sends raw packets, it requires root or CAP_NET_RAW privileges, but it is the default and fastest scan type in Nmap. It is not completely invisible—stateful firewalls can still detect the unprompted SYN/ACK followed by RST—but it is significantly more stealthy than a full connect scan.

• ✗

  Ping sweep (-sn)

  Why it's wrong here

  Ping sweep (-sn) disables port scanning entirely and performs only host discovery; Nmap sends ICMP echo requests, TCP pings to common ports, or ARP requests to determine which hosts are online. This measures host availability only, not whether any particular TCP port is open, so it cannot answer the client's question about open ports on the target. Even if the target responds to pings, that says nothing about whether port 443, 22, or 8080 is listening, and a host that blocks ICMP might appear 'down' to a sweep but still have open TCP ports. Thus, -sn is at most a pre-scan step, not a replacement for an actual TCP port scan.

Go deeper

Related to this question