Reconnaissance and Enumeration practice questions

nmap -sU

Why it fails: nmap -sU is a generic UDP port scanner that probes port 161 to determine whether UDP SNMP is open or filtered, but it does not decode or retrieve OID-based management values. While nmap can combine -sU with SNMP-specific NSE scripts (e.g., snmp-info) for deeper analysis, the bare -sU scan itself remains a connectivity test, not a full SNMP enumeration tool.

curl

Why it fails: curl is designed for HTTP, FTP, and other application-layer protocols that operate over TCP or clear-text streams, but SNMP uses the connectionless UDP transport with ASN.1 BER-encoded PDUs on port 161. Since curl has no built-in SNMP protocol support and cannot speak SNMP's request/response format, it is wholly unable to query an SNMP agent for management information.

snmp-check

Why it fails: snmp-check is a Perl-based utility that attempts default community strings and parses specific OIDs to display users, processes, and network interfaces, but it is not among the two standard tools expected for this task. It requires a valid community string upfront and lacks the brute-force capability of onesixtyone and the comprehensive MIB-walking power of snmpwalk, making it an ancillary script rather than a primary enumeration method.

NS record query

Why it fails: An NS record query returns only the authoritative name servers for a zone, revealing DNS infrastructure but not any other records. This tells an attacker which servers host DNS for the domain, but it does not expose hosts, IPs, or service configurations. Consequently, such a query is too narrow for broad information gathering.

MX record query

Why it fails: An MX record query reveals only the mail exchange servers and their priority values, which can hint at the email platform in use. It does not enumerate other DNS record types or internal hosts, and it omits crucial data like IP addresses or subdomains. Thus, it provides minimal value for comprehensive reconnaissance.

A record query

Why it fails: An A record query simply maps a single hostname to its IPv4 address and returns no additional DNS records. It does not enumerate other subdomains, aliases, or service records, and it requires prior knowledge of the hostname to be useful. Its scope is far too limited for broad information gathering.

SOA

Why it fails: The SOA record provides administrative metadata for a DNS zone, including the primary name server, a serial number, and timing intervals for refresh and retry. It is essential for zone management but does not transfer the zone's contents. Zone enumeration via a full transfer relies on the AXFR query type, not the SOA record, so SOA does not serve as a tool for pulling all DNS records.

NS

Why it fails: NS records identify the authoritative name servers for the domain, which is useful for targeting where to send zone-transfer requests. However, the NS record itself is not the mechanism that retrieves zone data; it only provides pointers to the name servers. To perform a full zone transfer, the tester must issue an AXFR query to one of those NS-listed servers, not rely on NS records as the enumeration method.

PTR

Why it fails: PTR records are used in reverse DNS zones to map IP addresses to hostnames, functioning in the opposite direction of a forward A or AAAA record. They do not participate in forward zone transfers, and a standard AXFR for a forward zone would not return PTR records unless the zone contains them (which is rare). Therefore, PTR is unrelated to the full-zone-transfer enumeration technique and is not the query type used to reveal all records in a domain.

Nmap

Why it fails: Nmap is an active reconnaissance tool that sends crafted packets to target hosts to discover open ports, running services, and operating system details. This direct interaction generates network traffic that can be detected by intrusion detection systems and logged by the target, violating the passive nature of this phase. Passive reconnaissance requires leveraging pre-existing data sources, not transmitting packets to the target infrastructure.

Shodan

Why it fails: Shodan is a search engine that indexes banners, service information, and vulnerabilities from internet-connected devices, making it valuable for mapping external attack surfaces. However, it focuses on device-level and port-level data, not historical web content such as archived pages, documents, or previous website versions. Unlike the Wayback Machine, Shodan does not provide a chronological record of how a target's web presence evolved over time.

Wireshark

Why it fails: Wireshark is a network protocol analyzer that captures and inspects live packets traversing a network interface in real time. To use it effectively, the pentester must be connected to the target network or positioned to intercept traffic, which is an active or internal activity that generates or requires existing network access. Passive reconnaissance avoids such traffic capture and instead gathers data from third-party repositories or public records without touching the target's systems.

Performing a zone transfer

Why it fails: A DNS zone transfer (AXFR request) copies an entire zone file from a DNS server to a client, revealing all DNS records such as A, AAAA, MX, TXT, and hostnames for a domain. It might expose an 'api.example.com' subdomain, but it cannot reveal the URI path structure of a web application, such as /v2/users or /graphql, because those are application-level routes. Zone transfers are an infrastructure enumeration technique, not a web API endpoint discovery method, and are rarely successful on properly configured DNS servers.

Running Nmap with service version detection

Why it fails: Nmap with service version detection (-sV) identifies the service and version listening on an open port, such as an nginx or Apache HTTP server, but it does not traverse the web server's directory structure or parse application routes. The API endpoint paths are specific to the application and are invisible to port scanning because they are resource identifiers within the HTTP protocol. While Nmap may find a port running 'REST API' in its banner, it cannot locate the actual endpoint URLs or parameters, so it is not useful for web API endpoint discovery.

site:target.com ext:pdf confidential

Why it fails: The ext: operator acts as a loose alias for filetype: in Google searches, but without the intext: operator, the keyword 'confidential' is not restricted to document content—Google matches it against the entire indexed page, including titles, URLs, and surrounding HTML. This query returns PDFs that mention 'confidential' anywhere on the page, not necessarily within the PDF's extracted text, diluting the results. Additionally, ext: is not officially documented by Google, so behavior can be inconsistent across data centers and over time, making it less reliable than the canonical filetype: syntax.

site:target.com intitle:confidential pdf

Why it fails: intitle:confidential restricts matches to the HTML title element, but PDFs do not have native HTML titles; Google synthesizes a title from the document metadata or filename. As a result, this query will miss PDFs whose content contains 'confidential' but whose title does not, and the bare term 'pdf' is treated as a general keyword, not a file-type filter. It therefore returns mostly HTML pages that mention 'pdf' and have 'confidential' in the title, failing to isolate sensitive PDF content.

inurl:target.com filetype:pdf confidential

Why it fails: inurl:target.com does not restrict the search to target.com's domain; it looks for 'target.com' as a substring anywhere in the URL, such as in a query parameter or a directory name, so pages on entirely different domains can be included. The proper domain-scoping operator is site:, which limits all results to that exact host and its subdomains. With the domain filter compromised, the filetype:pdf and 'confidential' operations apply to an over-broad result set, making the query unreliable for finding sensitive files on the intended target.

snmpget -v 2c -c public target_ip

Why it fails: The snmpget command retrieves a single, specifically identified OID from the MIB tree, so it returns data only for an exact object you already know. During enumeration, a tester typically does not have a preexisting list of system OIDs and needs to discover the structure, and snmpget does not reveal sibling branches or unknown tables. It is a point-query tool, not a tree-walking enumeration tool, making it inefficient and incomplete for broad information gathering.

snmpset -v 2c -c public target_ip

Why it fails: The snmpset command writes or modifies values on an OID, such as altering an interface's admin status or changing a system parameter, rather than reading or collecting data. Using it during enumeration is inappropriate not only because it fails to retrieve information, but also because it can make unauthorized configuration changes that trigger alarms, disrupt device state, or lock the tester out. Additionally, snmpset requires knowing the exact OID, type, and value to set, which contradicts the purpose of discovering what MIB objects exist. It is an active write operation, not a passive enumeration technique.

snmpbulkwalk -v 2c -c public target_ip

Why it fails: The snmpbulkwalk command uses the GETBULK PDU to retrieve multiple OIDs in a single request, which can be faster for large tables such as route or interface tables. However, many SNMP agents either do not support GETBULK, cap the number of rows returned, or truncate large responses, resulting in incomplete enumeration. Net-SNMP's standard snmpwalk command is preferred because it uses GETNEXT, which is universally compatible with SNMP v1, v2c, and v3 agents, making it the accepted baseline tool. Thus, while snmpbulkwalk has niche performance benefits, it is less universally reliable and not typically the first choice in penetration testing.

-sV

Why it fails: The -sV flag tells Nmap to perform version detection on open ports by sending a series of probes and analyzing banner responses. This identifies the specific service and application version, such as Apache/2.4.41, but it does not perform any operating system fingerprinting. In an active reconnaissance context, -sV is therefore not the correct switch for OS identification, which is the focus of the question.

-A

Why it fails: The -A flag is an aggregate 'aggressive mode' switch that turns on OS detection (-O), default NSE scripts (-sC), version detection (-sV), and traceroute simultaneously. While it would eventually reveal the OS, it is not the minimal, focused command for OS detection, and it generates substantially more network traffic that may increase the chance of detection by the target. Because the question asks specifically about OS detection, specifying -A introduces unnecessary scans and is therefore not the best answer.

-sS

Why it fails: The -sS flag performs a SYN (half-open) port scan by sending raw TCP SYN packets and observing whether the target responds with SYN-ACK, RST, or nothing. It is an efficient way to discover which ports are open, closed, or filtered, but it produces no OS fingerprinting information and does not invoke any NSE scripts. Consequently, -sS alone cannot satisfy the goal of OS identification, so it is incorrect for this active reconnaissance task.

Perform a DNS zone transfer against the target's domain

Why it fails: A zone transfer (AXFR/IXFR) copies the entire DNS zone from a primary to secondary server; for security, public authoritative servers only allow it from designated IPs, so an external tester will almost always receive a REFUSED response. Even in the rare case it succeeds, the zone simply reflects the public DNS records, which for a domain behind a CDN point to the CDN's edge IPs, not the origin. Therefore, this technique is both low-success and, if it works, unlikely to expose the actual backend address.

Run a full TCP port scan against the domain with Nmap

Why it fails: Nmap begins by resolving the hostname, so scanning "www.target.com" will target the A/AAAA records returned by DNS. With a CDN, those records are the CDN's anycast or load-balanced IPs, meaning the scan will enumerate ports on the edge infrastructure (e.g., 80/443 and CDN-specific services) and not the origin server. The results are misleading and may trigger defensive alerts; the tester should instead map subdomains and resolve only non-CDN records before scanning.

Use Shodan to search for the domain's SSL certificate hash

Why it fails: Shodan's certificate hash search indexes products by the SHA-256 fingerprint of the TLS certificate they present. When a CDN terminates TLS and serves the site's certificate at the edge, the hash will match thousands of Shodan banners associated with CDN nodes, not the origin IP. Moreover, if the site uses a wildcard or shared certificate, the hash may also match unrelated servers hosted by the same provider, further diluting the result and making origin discovery unreliable.

sublist3r

Why it fails: Sublist3r is a well-known subdomain enumeration tool that relies primarily on search engines and public sources for passive discovery. Although it is functional, it is not one of the three tools the exam context expects, and it lacks the active brute-force and API integration capabilities that distinguish Amass and dnsx. In this question, where Amass, Subfinder, and dnsx are the designated correct choices, Sublist3r is a plausible but incorrect distractor.

gobuster dns

Why it fails: Gobuster's DNS mode performs subdomain brute forcing by sending DNS queries with wordlists directly against the target domain. Unlike dedicated DNS enumeration tools, it focuses exclusively on brute force and does not incorporate passive OSINT sources or extensive record validation, making it less comprehensive for full-scope enumeration. In this context, where more specialized tools are expected, selecting Gobuster DNS is incorrect because it is not among the three commonly used tools the question is asking for.

Using DNS enumeration tools like nslookup or dig

Why it fails: DNS enumeration may be passive but typically involves direct queries to DNS servers, which might log the request.

Querying Shodan for open ports on the target's IP range

Why it fails: Shodan queries are considered passive, but the stem asks for employee information; Shodan is more about infrastructure.

Reviewing the target's website on Netcraft

Why it fails: Netcraft provides passive info about web servers, but not primarily employee data.

The Nmap results may have false positives for open ports

Why it fails: Nmap's SYN scan is considered highly reliable for determining open TCP ports because it directly elicits a SYN-ACK from a listening service. False positives are uncommon, and while some stateful firewalls can craft SYN-ACK responses for filtered ports, this anomaly is rare and easily detected by performing a full TCP handshake or service version detection. Thus, inaccurate Nmap port data is not a typical cause of misleading vulnerability scan results in this context.

Nessus will only scan the top 1000 ports by default, potentially missing services on higher ports

Why it fails: Nessus does not restrict itself to the top 1000 ports by default; its default port range is often 1-10000, and it can be configured to scan all 65535 ports. More importantly, during active reconnaissance, a tester typically feeds Nessus the specific open ports discovered by Nmap, so the scan focuses on known entry points. The idea that Nessus only scans the top 1000 ports is a misconception, and port coverage is a configurable parameter, not an inherent limitation that would invalidate the scan.

Nikto

Why it fails: Nikto is a web vulnerability scanner that checks for known vulnerabilities, misconfigurations, and outdated software by comparing responses against a database of signatures (such as server headers like a specific Apache or PHP version). While it can flag default files like /admin or /phpinfo.php, it is not a brute-forcing engine that systematically traverses a custom wordlist to discover arbitrary hidden directories. Therefore, it is the wrong choice when the goal is to enumerate an application's routes and endpoints from scratch.

Burp Suite

Why it fails: Burp Suite is primarily an intercepting proxy with a suite of manual testing tools, including repeater, intruder, and scanner, but it is not optimized for headless, fast directory brute-forcing without significant configuration. Its Intruder can perform wordlist-based attacks but is rate-limited for manual use; conducting large-scale content discovery typically requires e.g. a separate extension like Content Discovery or invoking it via API. The core product is too heavyweight and interactive compared to command-line brute-forcers designed for automated reconnaissance.

Use Nmap with the smb-enum-users NSE script to enumerate users via SMB.

Why it fails: The smb-enum-users NSE script enumerates users via SMB, but Exchange does not expose user enumeration over SMB. This script targets Windows file-sharing services, not Exchange's authentication interfaces. Using it against an Exchange server would likely return no results or trigger unnecessary SMB traffic, making it ineffective for this scenario.

Use the Metasploit auxiliary module auxiliary/scanner/http/owa_login with a username list to perform password spraying.

Why it fails: The owa_login module performs password spraying, which attempts authentication with common passwords against enumerated accounts. However, the question asks for user enumeration without lockouts, not password guessing. Password spraying can trigger lockouts if misconfigured and does not enumerate usernames; it assumes valid usernames already exist.

Use Hydra with the -L users.txt -P passwords.txt options against the Exchange server's SMTP port.

Why it fails: Hydra is a password-cracking tool that performs brute-force or dictionary attacks. Using it against SMTP would attempt authentication with username and password lists, which can trigger lockouts and is not a user enumeration technique. It is noisy and likely to be detected, making it unsuitable for stealthy enumeration.

Performing a DNS zone transfer (AXFR) against the target's authoritative name servers.

Why it fails: A DNS zone transfer is an active technique that queries the target's name servers directly. It is not passive because it sends traffic to the target and can be logged. Additionally, zone transfers are often misconfigured or blocked, and they only reveal subdomains if the server allows AXFR, which is rare in secure environments.

Running a brute-force subdomain enumeration tool like Gobuster with a large wordlist.

Why it fails: Gobuster is an active tool that sends DNS queries or HTTP requests to guess subdomains. It generates traffic to the target's infrastructure and can be detected. While effective, it is not passive reconnaissance. The question specifically asks for passive techniques, so this option is incorrect.

Using the Shodan API to search for services associated with the target's IP ranges.

Why it fails: Shodan can reveal services and sometimes hostnames, but it is not primarily a subdomain enumeration tool. It indexes banners from internet-facing devices, which may include subdomains if they are in certificate fields or HTTP headers, but this is incidental. It is less reliable for systematic subdomain discovery compared to dedicated techniques like CT logs or DNS datasets.

Run a full TCP connect scan of all 65535 ports with timing template T4 to quickly map the entire attack surface

Why it fails: Timing template T4 is aggressive and likely to trigger IDS alerts due to high packet rates. A full connect scan of all ports also completes handshakes, generating more logs. While it is thorough, it sacrifices stealth significantly and does not align with the requirement to minimize detection while maintaining reasonable thoroughness.

Perform a slow, randomized TCP connect scan with Nmap using timing template T2 and decoy addresses

Why it fails: A TCP connect scan completes the full three-way handshake, which is more likely to be logged by the target's services and IDS than a SYN scan. Although T2 and decoys add some stealth, the connect scan itself is noisier. This approach does not best balance thoroughness and stealth compared to a SYN scan with slower timing.

Use a UDP scan of all ports with default timing to identify every possible service before any TCP probing

Why it fails: UDP scanning is slow, often unreliable due to rate limiting and lack of responses, and scanning all UDP ports is extremely time-consuming. It also does not prioritize the most common TCP services that typically expose the attack surface. This approach is neither efficient nor stealthy and would delay useful results without guaranteeing better coverage.

Nmap OS detection scans against discovered IP addresses

Why it fails: Nmap OS detection sends crafted packets to target hosts, which is active reconnaissance and may be logged or blocked. It does not reveal employee names or email addresses, and it directly contacts the target's infrastructure. This contradicts the passive requirement and does not provide the requested personnel or email information.

Manual browsing of the target's public website and job postings

Why it fails: Browsing the target's website does contact the target's web server, so it is not strictly passive. While job postings can reveal technologies, the act of visiting the site generates traffic. The requirement specifies sources that do not directly contact the target's infrastructure, making this less suitable than third-party sources like LinkedIn or Shodan.

Direct SMTP VRFY commands against the target's mail server

Why it fails: SMTP VRFY commands are sent directly to the target's mail server, making this active reconnaissance. Many mail servers disable VRFY or respond ambiguously to prevent enumeration. Because the scenario requires sources that do not directly contact the target's infrastructure, this method violates the constraint and is not an appropriate choice.

Shodan

Why it fails: Shodan is incorrect because it is a search engine for internet-connected devices, not email addresses. It indexes service banners, open ports, and device fingerprints across the global IP space, making it invaluable for discovering exposed infrastructure and industrial control systems, but it does not crawl mailboxes or extract email addresses from public sources. During a pentest, Shodan helps map an organization's external attack surface, yet it is fundamentally not designed for email harvesting.

Censys

Why it fails: Censys is incorrect because it performs continuous Internet-wide scans of IP addresses, open ports, and TLS certificates, rather than collecting email data. Its strength lies in asset discovery, vulnerability identification, and analyzing certificate transparency logs, all of which support infrastructure reconnaissance but not the enumeration of emails. While Censys can provide insights into an organization's exposed services, it cannot fulfill the specific requirement of gathering email addresses during a penetration test.

Maltego

Why it fails: Maltego is incorrect for this task because, although it can be used for link analysis and OSINT correlation, it is not specifically focused on email harvesting out of the box. Maltego is a graphical intelligence platform that visualizes relationships between entities, and while it has transforms that can query email-related sources, using it requires configuring those transforms and integrating third-party data; it is not a dedicated email collector like theHarvester, and its primary value is in connecting and analyzing data rather than directly extracting email addresses.

False negative

Why it fails: A false negative in a web application vulnerability scan occurs when the scanner fails to detect an actual security flaw that is present, such as a stored XSS or a known vulnerable dependency. This is the most dangerous type of error because it provides a false sense of security, leading security teams to believe the application is secure when an exploitable vulnerability remains. Unlike a false positive, it does not trigger unnecessary investigation but instead allows real risk to go unaddressed, potentially resulting in a breach.

True positive

Why it fails: A true positive means the scanner accurately identified a vulnerability that genuinely exists in the web application, such as an unpatched critical CVE or a misconfigured CORS policy. The scanner's detection logic, whether signature-based or heuristic, correctly matched the evidence of the flaw in the HTTP responses or server behavior. This is the ideal scanning outcome because it directs remediation efforts toward a real risk, though manual verification is still recommended to confirm the finding before remediation.

Inconclusive

Why it fails: An inconclusive result indicates that the scanner could not gather sufficient evidence to determine whether a vulnerability is present, often due to session expiration, multi-step authentication, or nondeterministic server responses. It is not an incorrect alert but rather an unresolved one, meaning the scanner abstains from a definitive verdict. This finding demands manual penetration testing or a re-scan under controlled conditions, distinguishing it from a false positive, which is a confident but wrong assertion of a vulnerability.

-sU

Why it fails: The -sU option instructs Nmap to perform a UDP scan, sending datagrams to target ports and inferring status from ICMP port-unreachable responses or silence; it never sends TCP SYN packets, so it cannot directly identify open TCP ports in a SYN scan. UDP scanning is also inherently slower and less reliable than TCP SYN scanning because UDP is connectionless and responses depend on application behavior.

-sT

Why it fails: The -sT option performs a TCP connect scan, invoking the operating system's connect() system call to initiate a normal three-way handshake; if the handshake completes, the port is considered open and Nmap then sends a RST to close the connection. This full handshake is logged by applications and can trigger IDS/IPS alerts, so unlike -sS it is not a half-open SYN scan and is more detectable.

-sN

Why it fails: The -sN option sends a TCP packet with no header flags set, creating a NULL scan that exploits RFC 793 behavior: many systems will drop the packet silently for open ports and send an RST for closed ports, making open ports appear as 'open|filtered' in ambiguous cases. This scan type relies on system-specific TCP stack behavior and does not use SYN packets at all, so it cannot perform a half-open SYN handshake to definitively mark a port as open.