Scanning Networks and Enumeration practice questions

A stateful firewall is blocking inbound SYN packets to port 80 but allowing responses to outbound connections.

Why it fails: A stateful firewall tracks the state of active network connections. It can be configured to block new, unsolicited inbound SYN packets from specific sources (like the pen tester's host) to port 80, while simultaneously allowing established connections or connections originating from trusted internal hosts. The successful browsing from another internal host indicates the server is listening, and the firewall permits connections from that specific, authorized source, or allows return traffic for legitimate outbound connections.

The web server is running on a non-standard port that you did not scan.

Why it fails: If the web server were running on a non-standard port, attempting to browse to it using the default HTTP port (80) would fail, regardless of the source host. The fact that another internal host can successfully browse to the web server implies it is indeed listening and responding on port 80, making this option incorrect.

The server's TCP/IP stack is misconfigured and does not respond to SYN scans.

Why it fails: A fundamental misconfiguration of the server's TCP/IP stack would likely prevent any successful TCP connection to port 80, including the successful browsing from another internal host. Since another host can browse to the server, its TCP/IP stack is functioning correctly and listening on port 80, indicating the issue lies elsewhere, likely with an intermediary security device.

TCP SYN scan using `nmap -sS`

Why it fails: A TCP SYN scan (`-sS`) is primarily a port scanning technique, not solely for host discovery. It involves sending SYN packets to a range of ports on each target, expecting SYN/ACK for open ports or RST for closed ones. This process generates significantly more network traffic and takes considerably longer than a simple host discovery method, making it inefficient when the objective is merely to identify active hosts with minimal network footprint.

Ping sweep using `nmap -sn`

Why it fails: The `nmap -sn` command performs a ping sweep, which is specifically designed for efficient host discovery without conducting a full port scan. It intelligently sends a combination of ICMP echo requests, TCP SYN packets to common ports (like 443), and an ACK packet to port 80 by default to determine if a host is online. By disabling port scanning, this method significantly reduces the number of packets sent per target, making it highly efficient for identifying live hosts with minimal network overhead.

UDP scan using `nmap -sU`

Why it fails: A UDP scan (`-sU`) is primarily used for discovering open UDP ports, not efficient host discovery. It sends UDP packets to target ports and waits for an ICMP port unreachable message to determine if a port is closed, or for an application response if it's open. This process is inherently slow due to retransmission delays and often unreliable for simple host discovery, generating substantial traffic as it probes multiple UDP ports per host, far exceeding the requirements for merely identifying active hosts.

The target host has a host-based firewall that drops SYN packets but allows full connections.

Why it fails: Host-based firewalls typically treat SYN packets the same as any other TCP packet; they don't distinguish half-open vs. full connection.

The target host has ICMP filtering enabled, preventing Nmap from identifying it as online.

Why it fails: ICMP filtering would affect ping sweeps, not TCP scans; Nmap uses TCP probes to determine host status regardless of ICMP.

Nmap's SYN scan requires root privileges, and the tester ran it without sudo.

Why it fails: If the tester ran SYN scan without root, Nmap would fall back to connect scan automatically, not return no open ports.

Requesting a DNS zone transfer to obtain a list of user account names from the SRV records.

Why it fails: DNS zone transfers are designed to replicate DNS database records, primarily A, AAAA, MX, and SRV records, between authorized DNS servers. While SRV records identify services and their hostnames (e.g., LDAP, Kerberos), they do not contain user account names or security identifiers. Therefore, requesting a zone transfer will reveal network infrastructure and service locations, but not a list of user accounts.

Sending Kerberos AS-REQ packets and analyzing the error codes (e.g., KDC_ERR_PREAUTH_REQUIRED vs KDC_ERR_C_PRINCIPAL_UNKNOWN).

Why it fails: Sending Kerberos Authentication Service Request (AS-REQ) packets and observing the Key Distribution Center (KDC) responses is a method for validating whether a known username exists, not for enumerating unknown users. If a username is valid but preauthentication is required, the KDC returns KDC_ERR_PREAUTH_REQUIRED. However, if the username does not exist, the KDC responds with KDC_ERR_C_PRINCIPAL_UNKNOWN. This distinction helps confirm the existence of a specific user, but it does not provide a list of all users without prior knowledge of potential usernames.

The EC2 instance is behind a NAT gateway that only allows outbound traffic. The load balancer is in a public subnet, but the instance is in a private subnet and cannot be reached from the internet directly.

Why it fails: A NAT Gateway primarily facilitates outbound internet access for instances in private subnets; it does not govern inbound traffic to those instances. While an EC2 instance in a private subnet cannot be reached directly from the internet, this is due to its private IP address and subnet routing, not the NAT Gateway itself. A load balancer, however, can successfully forward traffic to such an instance's private IP, making the NAT Gateway irrelevant to the inbound connection path from the load balancer.

The VPC's network ACL is blocking inbound SYN packets to the EC2 instance's public IP, while allowing established connections. The TCP connect scan sends ACK packets, which bypass the ACL.

Why it fails: This statement is incorrect because a standard TCP connect scan, typically initiated by tools like Nmap, begins with a SYN packet to establish a connection. If a Network ACL (NACL) is configured to block inbound SYN packets, the connect scan would fail to initiate the three-way handshake. While some advanced scanning techniques might use ACK packets, a basic TCP connect scan does not send ACK packets to bypass SYN blocking, as NACLs are stateless and would drop the initial SYN.

The EC2 instance does not have a public IP assigned; the load balancer performs destination NAT. The initial scan targeted the load balancer's IP, not the instance's IP.

Why it fails: If the EC2 instance lacks a public IP, a direct scan to its IP from the internet is inherently impossible, as there is no routable address. While a load balancer does forward traffic to private IPs (similar to destination NAT), the statement that "The initial scan targeted the load balancer's IP, not the instance's IP" contradicts the scenario where a direct scan to the instance failed. The core reason for the differential scan results lies in the security group configuration, not solely the absence of a public IP or the load balancer's NAT function.

SYN scan (-sS)

Why it fails: The SYN scan (-sS), often referred to as a 'half-open' scan, sends a SYN packet and waits for a SYN/ACK response, then immediately sends an RST, preventing a full TCP connection. While stealthier than a full TCP connect scan because it doesn't complete the three-way handshake, it is not considered an advanced evasion technique against modern security devices. Most contemporary firewalls and intrusion detection systems (IDS) are specifically configured to detect and log SYN packets directed at closed ports or excessive SYN activity, making it easily identifiable.

ACK scan (-sA)

Why it fails: An ACK scan (-sA) sends TCP packets with only the ACK flag set, primarily to map firewall rules and determine their statefulness, rather than to identify open ports directly or evade detection. If a firewall is stateful, it will drop unsolicited ACK packets, resulting in no response, indicating a 'filtered' state. Conversely, an unfiltered port will typically respond with an RST packet, signifying that the port is reachable but not necessarily open for service. This scan type is about firewall assessment, not hiding the scanner's presence or the scan's nature.

Idle scan (-sI)

Why it fails: The Nmap idle scan (-sI) is a highly sophisticated and truly evasive technique that leverages a 'zombie' host to scan a target without sending any packets directly from the attacker's IP address. It works by monitoring the IP ID sequence number of an idle zombie host, then sending spoofed SYN packets from the zombie's IP to the target. By observing changes in the zombie's IP ID sequence after the target responds, the scanner can infer open ports on the target, effectively making the zombie appear as the source of the scan.

Xmas scan (-sX)

Why it fails: The Xmas scan (-sX) sends TCP packets with the FIN, PSH, and URG flags all set, resembling a 'Christmas tree' of lights, and relies on RFC 793 behavior where closed ports respond with an RST, while open ports typically send no response. Although it can sometimes bypass older, less sophisticated firewalls that only inspect for SYN packets, modern intrusion detection systems (IDS) are specifically designed to flag such non-standard flag combinations. Consequently, this scan type is generally detectable and not considered an effective evasion technique against contemporary security infrastructures.

Identity and Access Management (IAM): An on-premises or cloud-based security policy enforcement point placed between cloud consumers and providers.

Why it fails: This description incorrectly defines Identity and Access Management (IAM). IAM is primarily concerned with managing user identities and their permissions to access cloud resources, ensuring authentication and authorization based on established policies. The provided definition, describing an intermediary security policy enforcement point placed between cloud consumers and providers, accurately characterizes a Cloud Access Security Broker (CASB), not IAM.

Data Loss Prevention (DLP): A networking approach that separates control and forwarding planes for dynamic configuration.

Why it fails: This statement inaccurately describes Data Loss Prevention (DLP). DLP focuses on identifying, monitoring, and protecting sensitive data from unauthorized exfiltration or misuse, ensuring data confidentiality and compliance across various states (at rest, in transit, in use). The definition provided, which details a networking approach separating control and forwarding planes for dynamic configuration, precisely describes Software-Defined Networking (SDN), not DLP.

Perform a DNS zone transfer to obtain hostnames and associated user records.

Why it fails: A DNS zone transfer can reveal hostnames and IP mappings, but it does not provide NetBIOS names or logged-on user accounts. DNS records are unrelated to NetBIOS name resolution or user session information. This technique would not satisfy the client's request for Windows-specific enumeration data.

Run nbtscan against the target IP range to retrieve NetBIOS name tables.

Why it fails: nbtscan is excellent for retrieving NetBIOS name tables, including computer names, but it does not enumerate logged-on user accounts. The scenario explicitly asks for both NetBIOS names and logged-on users, so nbtscan alone is insufficient. A tool that can query the NetBIOS session service for user information is needed.

Use Nmap with the -sU -p 137,139,445 flags to scan for open NetBIOS ports.

Why it fails: Nmap can identify open NetBIOS ports (137, 139, 445) but does not extract NetBIOS names or logged-on user accounts. Port scanning only reveals service availability, not the rich enumeration data the client requires. The tester needs a dedicated enumeration tool that can query the NetBIOS Name Service and retrieve host and user information.

net view

Why it fails: net view is a Windows command that lists shared resources on a network, but it does not provide detailed permission information. It is limited to showing share names and comments. It is not a penetration testing tool and does not offer the granularity needed for security assessment. Therefore, it is not the best choice for enumerating shares and permissions.

smbclient

Why it fails: smbclient is a tool that allows connecting to SMB shares and performing operations like listing files, but it is not specifically designed for enumerating shares and permissions across a server. It can list shares with the -L option, but it does not provide detailed permission information. Other tools like enum4linux or smbmap are more suited for comprehensive share enumeration.

nmap with smb-enum-shares script

Why it fails: Nmap's smb-enum-shares script can enumerate SMB shares and provide some permission information, but it is not a dedicated command-line tool for this purpose. It is part of Nmap's scripting engine and may not provide the depth of enumeration that enum4linux offers. While it can be used, it is not specifically designed for comprehensive share and permission enumeration.

Perform SNMP enumeration to gather system information.

Why it fails: Performing SNMP enumeration is inappropriate without prior indication of the service running, as SNMP typically operates over UDP port 161. While it can yield extensive system information, blindly attempting it on a generic server during an internal penetration test is inefficient and unlikely to succeed unless a port scan specifically identifies UDP 161 as open and responsive. The absence of an open SNMP port makes this an ineffective initial enumeration strategy.

Attempt a DNS zone transfer from the server.

Why it fails: Attempting a DNS zone transfer is a technique specifically designed to extract comprehensive DNS records from a DNS server, not a general web server. This method is only viable if the target server is configured as an authoritative DNS server and permits zone transfers, which is not indicated here. Applying this technique to a non-DNS server would yield no useful information and is a misapplication of the reconnaissance method.

Enumerate NetBIOS names using `nbtstat`.

Why it fails: Enumerating NetBIOS names using `nbtstat` is primarily relevant for identifying Windows-based systems and their shared resources. NetBIOS services typically communicate over UDP ports 137 and 138, and TCP port 139. Without specific information suggesting a Windows host or these ports being open, attempting NetBIOS enumeration is generally ineffective and a poor use of time during initial reconnaissance on an unknown server.

Conduct a full TCP port scan of the entire network using SYN scan.

Why it fails: A full TCP port scan, which attempts to connect to all 65,535 possible TCP ports across an entire network range, is highly inefficient and disruptive. This extensive scanning generates a massive volume of network traffic, significantly increasing the likelihood of detection by intrusion detection systems (IDS) and potentially causing performance degradation on network devices due to the sheer number of connection attempts.

Use a ping sweep to identify live hosts, then perform a version scan on each.

Why it fails: While a ping sweep (ICMP echo request) can effectively identify live hosts that respond to pings, it only confirms host presence and does not reveal open ports or running services. Subsequently performing a version scan on *each* identified live host would still require a separate, potentially extensive port scan for each host to determine service versions, making it a two-step, less efficient, and more time-consuming process compared to directly scanning the target port with version detection.

Perform an ARP scan of the entire subnet and then check each host manually.

Why it fails: An ARP scan is effective for discovering all active hosts on a local subnet by mapping IP addresses to MAC addresses, confirming their presence on the network segment. However, after identifying these hosts, the requirement to "check each host manually" is extremely impractical and time-consuming for any sizable network. Manual checking provides no automated way to gather service version information and is highly inefficient for vulnerability assessment or even basic device inventory.

Banner grabbing

Why it fails: Banner grabbing involves connecting to an open port on a target system and observing the service's initial response, often called a banner. This technique primarily identifies the specific application, its version, and sometimes the underlying operating system running on that particular host. While useful for identifying vulnerable services and enumerating host-specific software, it provides no information about the network path or the sequence of routers packets traverse to reach the target.

DNS enumeration

Why it fails: DNS enumeration systematically queries Domain Name System (DNS) servers to gather information about hostnames, IP addresses, mail servers, and other records within a specific domain. This process helps map the logical structure of an organization's online presence and identify potential targets by resolving names to addresses. However, it focuses on discovering domain assets and their associated IP addresses, not on tracing the physical or logical routing path packets take across the network to reach those hosts.

SNMP walk

Why it fails: An SNMP walk is used to query a Simple Network Management Protocol (SNMP) agent on a network device to retrieve a hierarchical tree of Management Information Base (MIB) data. This data provides detailed operational statistics, configuration parameters, and status information about the device itself, such as interface status, CPU usage, or its internal routing table. While it offers deep insight into a single device's state and configuration, an SNMP walk does not actively discover or map the end-to-end network path between multiple devices across the internetwork.

Captured network packets

Why it fails: Captured network packets cannot be obtained directly through SNMP. SNMP is a protocol designed for managing and monitoring network devices by collecting specific management information from MIBs, not for intercepting or storing the actual data plane traffic. Tools like Wireshark or tcpdump are used for packet capture, operating at a lower level of the network stack.

User account passwords

Why it fails: User account passwords are not stored in SNMP Management Information Bases (MIBs) and therefore cannot be obtained via SNMP queries. Storing sensitive credentials like passwords in MIBs would represent a severe security vulnerability, as SNMP community strings, especially in versions 1 and 2c, are often transmitted in cleartext. MIBs are designed to store operational and configuration data, not authentication secrets.

Modify network interface settings

Why it fails: While SNMP can be used to modify network interface settings if write access is configured (e.g., via a specific write community string in SNMPv1/v2c or authenticated write operations in SNMPv3), the question specifically asks what *information can be obtained*. Modifying settings is an *action* or *configuration task*, not the *retrieval of information*. Therefore, this option describes an operational capability rather than an informational retrieval.

-sT (TCP connect scan)

Why it fails: The -sT option performs a full TCP three-way handshake (SYN, SYN/ACK, ACK) with the target port, which is the most straightforward and "loudest" type of TCP scan. Because it completes the connection, it is highly visible to the target operating system's logging mechanisms, firewalls, and Intrusion Detection Systems (IDS), making it easily detectable and logged. This method is generally avoided when attempting to evade network defenses due to its inherent lack of stealth.

-sV (version detection)

Why it fails: The -sV option instructs Nmap to perform service and version detection on open ports, which involves sending a series of additional, specific probes to identified open ports to elicit banner information or application-specific responses. These extra probes generate significantly more network traffic and distinct application-layer signatures compared to simple port scanning, making the scan much more detectable by firewalls, IDS, and network monitoring tools. Its purpose is identification, not evasion.

The port is closed and the target sent a RST packet.

Why it fails: If a port is truly closed, the target host's TCP/IP stack would respond to an incoming SYN probe with a TCP RST (Reset) packet, indicating that no service is listening on that port. Nmap interprets this RST response as the port being definitively 'closed'. The 'filtered' state, however, implies that no such RST packet was received, meaning the probe was likely intercepted and dropped before reaching the host's TCP stack.

The port is open but the service is not responding to the scan.

Why it fails: For Nmap to classify a port as 'open', the target service must successfully complete the initial TCP three-way handshake by responding to a SYN probe with a SYN/ACK packet. Even if the service subsequently fails to respond to application-layer requests or is misconfigured, the initial SYN/ACK would still confirm the port's 'open' status. A 'filtered' state indicates that Nmap did not receive any SYN/ACK response, suggesting the probe never reached the service to begin with.

The port is open but Nmap cannot determine the service.

Why it fails: Nmap's ability to determine the service version (e.g., Apache HTTPD 2.4) is a separate function from determining the port state (open, closed, filtered). If a port is open, Nmap will report it as 'open', even if it cannot identify the specific service or its version due to an unknown banner or custom application. The 'filtered' state specifically signifies that Nmap's probes are being blocked, preventing any determination of whether the port is open or closed, let alone the service running on it.

Attempt to connect to the file server via RDP (port 3389) using the compromised user's credentials.

Why it fails: Attempting to connect via RDP (port 3389) to a file server with limited user credentials is generally ineffective. File servers are primarily designed for data storage and sharing, not interactive desktop access, meaning RDP is often disabled or restricted to administrative accounts. Even if the port were open, a standard compromised user account from a workstation would almost certainly lack the necessary "Remote Desktop Users" group membership on the server to establish a session.

Use PsExec to execute commands remotely on the file server using the compromised user account.

Why it fails: Using PsExec to execute commands remotely on a file server requires elevated privileges, specifically local administrator rights on the target system. A compromised standard user account from a workstation will not possess these administrative credentials on the file server. Consequently, any attempt to use PsExec would result in an "Access Denied" error, making it an unsuitable initial reconnaissance or lateral movement technique without prior privilege escalation.

Run a full vulnerability scan (e.g., Nessus) against the entire subnet to identify weaknesses.

Why it fails: Running a full subnet vulnerability scan from a single compromised workstation would generate excessive network traffic and trigger host-based firewall alerts, as the file server’s SMB port is only open to workstations, not to a scanning tool’s IP range. This approach is tempting because Nessus is designed to systematically identify missing patches and misconfigurations across many hosts, and it would be correct if the client had granted administrative credentials and the firewall rules permitted broad scanning.

Port 3389 is open and running a Remote Desktop service, but the service version could not be identified.

Why it fails: A 'filtered' state in Nmap output explicitly indicates that Nmap was unable to determine if the port is open or closed because packet filters, such as a firewall, are preventing its probes from reaching the target port. Therefore, inferring that the port is open and running a specific service, even without version identification, is an incorrect conclusion. Nmap cannot confirm any service activity on a filtered port, only that its probes were obstructed.

Port 3389 is closed and the target is ignoring the probe.

Why it fails: If port 3389 were truly closed, Nmap would typically receive an RST (reset) packet in response to its probes, leading to a 'closed' status in the scan results. The 'filtered' state, however, signifies that Nmap's probes were likely dropped by an intermediary device, such as a firewall, without receiving any response. This prevents Nmap from confirming the port's actual state and does not imply the target is merely ignoring the probe on a closed port.

The target is likely a honeypot designed to simulate a Windows machine.

Why it fails: While honeypots can exhibit various behaviors, a 'filtered' port status alone provides no specific indication of a honeypot. This state primarily suggests the presence of a network filtering device, like a firewall, actively dropping or rejecting scan packets. Identifying a honeypot would typically require more advanced analysis, such as inconsistent service banners, unusual responses to specific probes, or a high number of open, vulnerable-looking ports that don't correspond to a typical production system.

Perform a TCP connect scan (-sT) on all ports of the subnet to identify open ports and services.

Why it fails: A TCP connect scan (-sT) is highly detectable because it completes the full TCP three-way handshake (SYN, SYN/ACK, ACK) for every open port. This full connection establishment is logged by most intrusion detection systems (IDS) and firewalls, making it a noisy and easily traceable method. Furthermore, scanning all 65535 ports across an entire subnet with this method would generate an immense volume of network traffic, significantly increasing the likelihood of detection and potentially impacting network performance.

Perform an Xmas scan (-sX) on all ports of the subnet to evade detection by sending packets with invalid flag combinations.

Why it fails: An Xmas scan (-sX) attempts to evade detection by sending TCP packets with the FIN, PSH, and URG flags set, expecting no response for open ports and an RST for closed ports, based on RFC 793. However, many modern firewalls and operating systems do not strictly adhere to this RFC behavior, often dropping such malformed packets or responding inconsistently. This makes the Xmas scan unreliable for accurately determining port states, especially against hardened targets or those behind stateful firewalls, leading to false negatives or positives.

Perform a UDP scan (-sU) on all ports of the subnet because UDP is connectionless and less likely to be logged.

Why it fails: A UDP scan (-sU) is inherently slow and unreliable for identifying open UDP ports because it relies on receiving an ICMP Port Unreachable message for closed ports, which can be rate-limited or dropped by firewalls. For open UDP ports, there's often no response unless an application-layer service responds, making it difficult to distinguish between open and filtered states. Crucially, a UDP scan is completely ineffective for discovering TCP-based services, which are the primary focus for most network penetration tests, rendering it an inappropriate choice for this objective.

Scanning, Reconnaissance, Gaining Access, Maintaining Access, Covering Tracks

Why it fails: Initiating a penetration test with Scanning before Reconnaissance is fundamentally inefficient and often ineffective. Without prior information gathering, such as target scope, IP ranges, or domain names, the scanning phase lacks direction and context. Reconnaissance provides the essential intelligence required to conduct targeted and meaningful scans, identifying specific assets and services for vulnerability assessment.

Reconnaissance, Scanning, Gaining Access, Covering Tracks, Maintaining Access

Why it fails: This order is incorrect because Covering Tracks should always occur after Maintaining Access. The objective of Maintaining Access is to establish persistence within the compromised system, ensuring the attacker can re-enter at will. Attempting to cover tracks before securing this persistent access risks losing the foothold entirely, making subsequent re-entry significantly more challenging or impossible.

Gaining Access, Reconnaissance, Scanning, Maintaining Access, Covering Tracks

Why it fails: Starting a penetration test with Gaining Access is illogical and practically impossible without prior preparatory steps. Successful exploitation requires a thorough understanding of the target's attack surface, which is derived from Reconnaissance and Scanning. These initial phases identify potential entry points and vulnerabilities, making a targeted and successful Gaining Access attempt feasible.

Generate shellcode, then identify vulnerability, then find offset, then craft exploit, then execute

Why it fails: This sequence is fundamentally flawed because shellcode generation is dependent on prior reconnaissance. An attacker must first identify a specific buffer overflow vulnerability, understand the target architecture, and determine critical constraints such as available buffer size, bad characters, and the exact return address overwrite location. Generating shellcode prematurely, without this context, would likely result in an incompatible or ineffective payload that cannot achieve arbitrary code execution.

Identify vulnerability, then generate shellcode, then find offset, then craft exploit, then execute

Why it fails: This is incorrect because generating shellcode before finding the offset may result in shellcode that is too large or does not align with the buffer structure. The offset is critical to know the exact location to overwrite EIP, which influences where shellcode can be placed.

Find offset, then identify vulnerability, then generate shellcode, then craft exploit, then execute

Why it fails: Attempting to find the offset before identifying a specific vulnerability is illogical and impractical. The "offset" refers to the precise number of bytes required to overwrite the Extended Instruction Pointer (EIP) or Return Instruction Pointer (RIP) on the stack, which is unique to a particular vulnerable buffer within a program. Without first identifying *which* buffer can be overflowed, there is no specific target or context to determine an offset, making this step impossible to execute effectively.