Scanning and Mapping practice questions

TCP Connect scan (-sT)

Why it fails: This technique utilizes the system's underlying connect() system call to establish a complete three-way handshake. Because the connection is fully realized before being dropped, it is easily detected by target operating systems and logging mechanisms, making it highly conspicuous and unsuitable for stealthy reconnaissance operations on sensitive networks.

UDP scan (-sU)

Why it fails: UDP scanning is inherently slower and less reliable than TCP techniques due to the connectionless nature of the protocol. It relies on waiting for ICMP unreachable messages, which are frequently rate-limited or blocked by modern firewalls, making it inefficient for initial host discovery compared to SYN-based TCP scanning methods.

Ping sweep (-sP)

Why it fails: While fast, traditional ICMP echo requests are frequently blocked by perimeter firewalls and host-based intrusion prevention systems. Relying solely on ICMP for discovery in modern enterprise environments often leads to incomplete results because many administrators disable ICMP responses to prevent network mapping, rendering this method unreliable for comprehensive host discovery.

Include the entire internal address space to ensure no assets are missed.

Why it fails: Scanning unauthorized subnets is a violation of typical rules of engagement and can cause service disruptions on production systems. Always limit scans to the explicitly authorized IP ranges defined in the signed scope document to ensure that you do not interfere with critical infrastructure not included in the assessment plan.

Automate the scan to run continuously throughout the investigation.

Why it fails: Continuous automated scanning can lead to significant network noise and potential service degradation. Most incident response engagements require targeted, time-bound discovery phases. Continuous scanning risks triggering security alerts repeatedly and interferes with normal network traffic, which violates the principle of minimizing impact on the client’s production environment during investigations.

Use the most aggressive timing template to minimize engagement time.

Why it fails: Using aggressive timing templates, such as T5, can lead to inaccurate results and excessive network congestion. It also increases the probability of triggering automated defense mechanisms or crashing fragile legacy services. Responders should prioritize accuracy and stability over speed by selecting timing templates appropriate for the network's capacity and risk level.

Full TCP Connect scans

Why it fails: Full TCP connect scans complete the three-way handshake, making them behave like legitimate application traffic. Because they follow standard protocol behavior, they are generally less likely to be blocked by egress filters than more exotic scanning techniques, allowing for a more accurate map of the network services during a formal incident investigation.

TCP SYN scans (-sS)

Why it fails: TCP SYN scans are generally effective because they use standard TCP flags that are commonly permitted by most firewalls. As long as the initial SYN packet can reach the destination and the response is allowed back, the scan remains accurate, making this a reliable method even in many filtered network environments.

Service version detection (-sV)

Why it fails: Service version detection relies on standard TCP connections to probe application banners. Because it uses established connections, it is generally resistant to egress filters that permit standard web or application traffic. This makes it a reliable technique for identifying service versions, provided the initial connection to the target port is successful.

TCP Connect scan using the -sT flag to guarantee complete handshake completion across all targeted destination ports.

Why it fails: Complete three-way handshakes force the operating system stack to allocate socket resources and generate local connection logs, making this technique easily detectable by standard host-based auditing mechanisms and intrusion detection sensors deployed inside the network segment.

ICMP Echo request ping scan utilizing the -PE parameter to discover live IP addresses across the subnet.

Why it fails: Many modern firewalls and host operating systems drop ICMP Echo requests by default to prevent reconnaissance and denial of service vectors, resulting in false negatives that hide genuinely active systems from the incident handler's map.

UDP ping scan using the -PU parameter targeting high-numbered ports to query stateless services.

Why it fails: UDP scans are notoriously slow and unreliable due to ICMP rate-limiting implemented by intermediate routers, frequently leading to inaccurate host discovery results and excessive timeout delays during time-sensitive incident investigations.

TCP SYN stealth scan using the -sS flag to prevent complete three-way handshakes from forming on target ports.

Why it fails: TCP SYN scans initiate half-open connections by sending synchronization packets. Although they do not complete the final handshake, stateful firewalls still log these connection attempts, making them too noisy for completely stealthy host discovery exercises.

UDP packet scanning using the -sU flag to probe high-numbered destination ports across the entire subnet range.

Why it fails: UDP scanning is notoriously slow and unreliable due to ICMP rate-limiting mechanisms implemented on modern routers and operating systems. It generates significant diagnostic traffic rather than discreet host mapping signals.

ICMP Echo request ping sweep using the -sn flag with timing templates set to paranoid levels for evasion.

Why it fails: Many modern operating systems and enterprise firewalls block or rate-limit inbound ICMP echo requests by default. Relying solely on ICMP sweeps often results in missing numerous live hosts that are configured to ignore pings.

ICMP Information Request (-PE with alternate timestamp parameters) to bypass standard router filtering blocks.

Why it fails: ICMP Information Requests and Timestamp queries are part of the broader ICMP suite that network administrators universally block alongside standard Echo requests, rendering them ineffective for bypassing host-level firewall configurations in secure corporate networks.

ARP Ping (-PR) utilizing local broadcast frames to discover active nodes on the directly connected subnet.

Why it fails: While ARP Ping is exceptionally effective for local subnet discovery, it is technically restricted to the local layer-two broadcast domain and cannot traverse routed network segments, making it unreliable for heavily segmented enterprise environments.

TCP NULL Ping (-PN) to disable host discovery and force scanning of all specified IP addresses.

Why it fails: The -PN flag in Nmap does not perform a discovery ping; rather, it completely disables host discovery and assumes all specified targets are online, which severely degrades scanning performance when scanning large, sparse address spaces.

nmap -PE 192.168.1.0/24

Why it fails: The -PE option sends ICMP echo requests. While it avoids TCP and UDP, ICMP traffic is still a network-layer packet that can be logged by host-based firewalls or IDS. The scenario specifically requires avoiding TCP or UDP, but -PE is not the best method because it may be blocked and is less reliable than ARP on a local subnet.

nmap -sn 192.168.1.0/24

Why it fails: The -sn option performs a ping scan (host discovery only) but still relies on ICMP echo requests, TCP SYN to port 443, TCP ACK to port 80, and timestamp requests. These packets can be logged by host-based firewalls, so it does not meet the requirement of avoiding TCP/UDP traffic.

nmap -sP 192.168.1.0/24

Why it fails: -sP is an older alias for -sn and behaves identically. It sends ICMP echo, TCP SYN to port 443, TCP ACK to port 80, and ICMP timestamp requests. Because TCP packets are still transmitted, host-based firewalls can log them, violating the constraint of no TCP or UDP packets.

TCP SYN scan (-sS)

Why it fails: A TCP SYN scan sends a SYN packet and waits for a SYN/ACK or RST. Because the firewall drops unsolicited TCP packets, the SYN will not reach the target, and the scan will report the port as filtered. This scan type is unlikely to succeed in a stateful firewall environment.

TCP window scan (-sW)

Why it fails: A TCP window scan is similar to an ACK scan but examines the TCP window field of RST packets to differentiate open from closed ports. While it may bypass some stateless filters, it still relies on ACK packets. In a stateful firewall that drops unsolicited TCP packets, ACK packets may be dropped or treated as part of an established connection, but window scan is less reliable than ACK or FIN scans for this purpose.

TCP connect scan (-sT)

Why it fails: A TCP connect scan uses the operating system's connect() call to establish a full TCP connection. Like the SYN scan, it sends an initial SYN that the stateful firewall will drop because it is unsolicited. Therefore, it will also fail to identify open ports behind the firewall.

TCP FIN scan (-sF)

Why it fails: A FIN scan sends TCP packets with only the FIN flag set. Many firewalls and stateful devices drop such packets or respond with RST regardless of port state, making results unreliable. Additionally, the firewall here allows ACK but does not explicitly allow FIN, so FIN packets to non-web ports would likely be dropped, yielding filtered results.

TCP Xmas scan (-sX)

Why it fails: The Xmas scan sets FIN, PSH, and URG flags. Like the FIN scan, it is often blocked or mishandled by firewalls, and modern systems may not follow RFC 793 behaviour. Since the firewall allows ACK but not necessarily these flag combinations, the scan would likely be filtered and not provide useful open-port information.

TCP connect scan (-sT)

Why it fails: A TCP connect scan relies on completing the three-way handshake, which requires sending a SYN packet. Since the firewall drops SYN packets to non-web ports, the scanner will receive no response for those ports and will mark them as filtered. This scan type will not reveal open ports outside 80 and 443 in this scenario.

Use -PE to send only ICMP echo requests

Why it fails: -PE sends ICMP echo requests, which many hosts block by default. Relying solely on ICMP will miss those hosts, leading to incomplete mapping. While it is a valid probe, using it alone is insufficient in an environment where ICMP is filtered, and it does not reduce scan time compared to multi-probe discovery.

Use -sS to perform a SYN scan on all ports

Why it fails: A SYN scan (-sS) is a port scan, not a host discovery method. It sends SYN packets to many ports, which is more intrusive and time-consuming than a ping scan. Using it for host discovery would increase network load and scan duration, contrary to the goal of efficient liveness detection.

Use -T5 to set the timing template to insane

Why it fails: The -T5 timing template increases scan speed but can cause packet loss and inaccurate results on large or high-latency networks. It may also trigger IDS alerts. While it reduces scan time, it does not improve host discovery accuracy and can degrade reliability, so it is not a recommended technique for this scenario.

-sV

Why it fails: The -sV flag is used for version detection, which determines the software and version numbers running on open ports by interacting with the application layer. While useful for identifying service vulnerabilities, it does not provide information regarding the underlying operating system kernel or the network stack implementation of the target.

-A

Why it fails: The -A flag enables aggressive scan mode, which combines OS detection, version scanning, script scanning, and traceroute. While it does perform OS detection, it is considered too noisy for standard incident response tasks, as it triggers multiple signatures and may alert security teams to the presence of the responder.

-sS

Why it fails: The -sS flag performs a TCP SYN scan, which is used for port discovery rather than OS fingerprinting. While it is the default and most popular scan type for finding open ports, it lacks the specific analysis tools required to identify the operating system or kernel version of the target system.

T3

Why it fails: T3 is the default timing template and is generally too aggressive for sensitive industrial control systems. It assumes a modern, robust network infrastructure where traffic density is not an issue. Using this template in fragile environments risks overwhelming legacy stacks, potentially leading to system instability, service denial, or unexpected device reboots.

T4

Why it fails: T4 is an aggressive template designed for fast networks and stable hardware. It prioritizes speed over caution and will frequently crash or hang sensitive devices that lack the processing power to handle concurrent packet streams, making it completely unsuitable for environments containing legacy or specialized industrial control equipment during an assessment.

T5

Why it fails: T5 is the fastest, most aggressive timing template available. It is intended for use only on high-speed, reliable networks where speed is the primary constraint. Using T5 against fragile or industrial systems is essentially guaranteed to cause service disruptions, as the sheer volume of packets will overwhelm the target's networking capabilities.

Wireshark

Why it fails: Wireshark is a powerful packet analyzer, not a scanner. While it can capture SMB traffic for later analysis, it is not designed for active discovery or vulnerability identification. It is a passive tool that requires the traffic to exist, making it unsuitable for mapping and identifying vulnerable services on a network.

Netcat

Why it fails: Netcat is a networking utility for reading and writing data across network connections. While it can be used for basic port checking, it lacks the automation and specialized vulnerability-checking capabilities required to identify SMB configuration issues across a large number of hosts efficiently, making it a poor choice for comprehensive network mapping.

Tcpdump

Why it fails: Tcpdump is a command-line packet sniffer used for troubleshooting and debugging network traffic. Like Wireshark, it does not actively probe targets or report on service vulnerabilities. It provides visibility into raw traffic but cannot perform the automated scanning required to inventory vulnerabilities across multiple Windows systems in an enterprise.

To reduce the scan duration by optimizing packet routing.

Why it fails: Randomization does not optimize packet routing; in fact, it can sometimes increase latency due to the overhead of switching targets constantly. The primary purpose of randomization is to evade detection, not to improve the performance or efficiency of the scanning engine. Speed is actually sacrificed for the sake of stealth.

To bypass the target operating system's rate limiting.

Why it fails: While some rate-limiting occurs on individual hosts, randomization is primarily used to avoid network-wide intrusion detection triggers. It does not effectively bypass OS-level rate limiting because, even with randomization, individual hosts will eventually receive probes at a rate determined by the overall scanning speed, which can still trigger local security policies.

To ensure the scanner utilizes all available network interfaces.

Why it fails: Randomizing IP addresses does not influence which network interface Nmap uses to send packets. The selection of network interface is typically determined by the routing table and command-line arguments. Randomization is strictly a technique for obfuscating the scanning pattern to evade detection, not an optimization for the underlying network hardware performance.

TCP SYN scan (-sS)

Why it fails: TCP SYN scanning operates at the transport layer and requires at least a partial handshake. While it is stealthy, it still interacts with the TCP stack of the target, creating logs and potentially causing issues on fragile systems. It is not considered a pure 'connectionless' mapping technique compared to ICMP methods.

TCP Connect scan (-sT)

Why it fails: TCP connect scanning requires a full three-way handshake and is the most visible form of scanning. It is the opposite of a connectionless mapping technique and will be logged extensively by both the target system and network monitoring infrastructure, making it a poor choice for stealthy network discovery in sensitive environments.

UDP scan (-sU)

Why it fails: UDP scanning is a transport-layer discovery technique that attempts to reach specific ports on a system. It is significantly more intrusive than ICMP scanning and often generates false positives if the target rate-limits its ICMP response packets. It is not an appropriate tool for simple network topology mapping and host discovery.

Running an nmap.exe binary from a USB drive.

Why it fails: Executing unauthorized binaries like nmap.exe is almost certain to trigger endpoint detection and response (EDR) solutions. In restricted environments, using external tools is a high-risk activity that may alert the adversary or security team to the presence of the responder, potentially compromising the ongoing incident investigation and the team's professional standing.

Initiating a telnet session to every port.

Why it fails: Telnet is an outdated and insecure protocol, and modern systems often have the client disabled by default. Attempting to initiate manual telnet sessions to every port is inefficient and prone to errors. Furthermore, this activity is highly visible to network monitoring tools and does not provide an automated mapping capability.

Pinging the broadcast address of the subnet.

Why it fails: Pinging a broadcast address is a classic technique that is frequently blocked by modern network configurations to prevent broadcast storms and reconnaissance. Relying on this for port verification is ineffective as it provides no information about specific port statuses, only general network activity, and is often ignored by modern host operating systems.

--spoof-mac

Why it fails: The --spoof-mac option is used to change the MAC address of the source interface, which is helpful for evading local network access controls but does nothing to bypass network-level firewall filtering based on ports. It is ineffective against rules that allow traffic based on port number or protocol source.

-f

Why it fails: The -f flag enables packet fragmentation, which breaks probes into smaller pieces. While it was historically used to bypass primitive filters, modern firewalls easily reassemble these fragments, rendering the technique ineffective. It is not designed to manipulate source port headers and does not help with port-based filter bypass in modern enterprise networks.

--data-length

Why it fails: The --data-length option appends random data to the sent packets. This is primarily used for evading signature-based detection by altering the packet's footprint, but it does not change the source port or help in bypassing port-based firewall rules. It is irrelevant to the requirement of appearing as legitimate DNS traffic.

--verbose

Why it fails: The --verbose flag increases the amount of information printed to the screen but does not explain the logic behind port states. It provides details on the scanning process, such as host discovery and timing, but fails to give the specific reasoning regarding the packet responses that resulted in a specific port state.

--packet-trace

Why it fails: While --packet-trace shows every packet sent and received, it is overwhelming for most users and does not provide the concise logic for why Nmap determined a port state. It is a debugging tool for raw packet analysis, not a reporting tool designed to explain the determination of port states clearly.

-d

Why it fails: The -d flag enables debugging, which outputs an extreme amount of information regarding Nmap's internal operations. It is intended for developers debugging the Nmap tool itself and is not useful for responders trying to interpret scan results, as it lacks clear, actionable information about why specific ports were marked as filtered or closed.

The scan will consume excessive bandwidth.

Why it fails: While aggressive scans do increase traffic, the primary issue on a high-latency network is not bandwidth consumption, but rather the inaccuracy of the scan results. The scanner will timeout long before it can accurately map the network, leading to incomplete reports that fail to show existing services due to timing constraints.

The scan will trigger an automated shutdown of the network.

Why it fails: While aggressive scanning can cause issues, it is highly unlikely to trigger an automated total network shutdown. The primary risk is the loss of data integrity and reliability of the scan results. Overstating the disruptive impact of scanning is unnecessary, as the inaccuracy is the main risk to the incident response.

The scan will crash the Nmap engine.

Why it fails: Nmap is built to handle high-speed scanning and is unlikely to crash due to network latency. The engine will simply continue to send probes based on the specified timing template. The problem lies with the accuracy of the interpretation of the results, not the stability of the Nmap software itself under load.

It requires root privileges on the scanning host to construct raw TCP frames with custom header flags.

Why it fails: Raw packet generation in modern port scanners requires elevated privileges regardless of the specific scan flag configuration chosen. This operational requirement applies equally to SYN, ACK, and FIN scans, meaning privilege level does not dictate the limitation of ACK scans specifically.

It causes immediate system instability and kernel panics on legacy Microsoft Windows operating systems due to malformed TCP stacks.

Why it fails: Standard TCP ACK packets are completely valid within the TCP specification and do not cause system crashes or kernel panics on any modern or legacy operating system platforms during standard network enumeration activities.

It triggers immediate critical high-severity alerts on all intrusion detection systems due to the distinct lack of a three-way handshake initiation.

Why it fails: While security monitoring systems may log unusual traffic patterns, ACK scans often blend in better with legitimate established session traffic traversing firewalls than blatant SYN scans, meaning they do not inherently trigger high-severity alerts everywhere.