Reconnaissance and Enumeration practice questions

Shodan

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

DNS cache snooping

Why wrong: DNS cache snooping is an active technique because it sends crafted queries to a recursive resolver, such as an ISP's DNS server, and examines whether the response is marked authoritative or non-authoritative to infer if that resolver has previously cached a specific domain. This interaction generates network traffic and can be detected by the resolver's operators, making it observable and active. It is not passive reconnaissance because it queries third-party infrastructure rather than relying on publicly available, append-only data sources. Since the goal is to remain undetected, this method is inappropriate as a purely passive approach.

Subdomain bruteforce with gobuster

Why wrong: Subdomain brute-force enumeration with gobuster is an active reconnaissance method because it floods a target's authoritative DNS server (or configured resolver) with a large volume of automated DNS queries for common subdomain labels, such as admin, dev, or mail. Each query is a direct, protocol-level interaction with the target's DNS infrastructure, and the volume and pattern of queries can be easily logged by the server, triggering rate limits or security alerts. Unlike querying public transparency logs, this approach relies on direct interrogation and trial-and-error, so it is neither passive nor stealthy. In a PenTest engagement, such activity should be timed and scoped carefully to avoid denial-of-service or detection.

DNS zone transfer

Why wrong: A DNS zone transfer (AXFR/IXFR) is an unequivocally active technique because it queries the target's authoritative name server directly to request a complete copy of the zone file, thereby exposing all DNS records, including hosts, aliases, and infrastructure details. This request is a distinct, loggable interaction that requires specific transport (TCP) and can only succeed if the server is misconfigured to allow transfers to arbitrary hosts, which is rare in hardened environments. Even when unsuccessful, the query itself is visible to the target and may be flagged as an information-gathering attempt. Because it relies on direct server interaction, it is not passive and should only be performed with explicit authorization.

Ping sweep with nmap -sn

Why wrong: A ping sweep with nmap -sn is incorrect because by default Nmap sends IP-based probes such as ICMP echo requests, TCP SYN to port 443, and TCP ACK to port 80. Many hosts and firewalls are configured to drop ICMP echo requests entirely, and aggressive network policies can also filter the TCP probes, causing live hosts to be missed. While Nmap may fall back to ARP when run with root privileges on a local subnet, the standard -sn behavior explicitly depends on Layer 3 and Layer 4 packets, which are substantially less reliable than a pure Layer 2 ARP scan.

TCP SYN ping with nmap -PS

Why wrong: A TCP SYN ping with nmap -PS sends SYN packets to a specified port (commonly port 80) and considers a host alive if it receives a SYN/ACK or RST response. This is a Layer 3/4 probe, so it is subject to stateful firewall inspection, egress filtering, and rate limiting; if the destination port is closed or filtered, the absence of a response does not necessarily mean the host is down. Furthermore, SYN pings can trigger intrusion detection or prevention systems because they resemble the initial stage of a port scan, reducing their stealth and reliability as a pure host-discovery technique.

UDP scan with nmap -sU

Why wrong: A UDP scan with nmap -sU is designed for port discovery, not host discovery, and is inherently unreliable for finding live hosts. UDP is connectionless, so most services do not reply to unsolicited packets, and the scanner often relies on ICMP port-unreachable responses to infer host status—responses that are frequently rate-limited or filtered by firewalls. Additionally, UDP scanning can be extremely slow because of retransmission timeouts, making it a poor choice for quickly identifying active systems compared to ARP, which provides immediate, unambiguous replies.

Perform a DNS zone transfer

Why wrong: A DNS zone transfer is a technique used against DNS servers to request a full copy of a zone's resource records, such as A, MX, and NS records, but it has no bearing on the client-side JavaScript running in a web application. While a successful AXFR can reveal internal hostnames and network architecture, it cannot expose API endpoints, keys, or logic embedded in the application's code. This option is wrong because it targets infrastructure DNS, not the web client's static resources, and would likely be part of passive reconnaissance, not JavaScript analysis.

Run a Nikto scan against the application

Why wrong: Nikto is an open-source web server scanner that checks for known vulnerabilities, insecure files, outdated server software, and dangerous misconfigurations; it sends crafted HTTP requests to the server and inspects response headers and content. It does not execute or parse JavaScript in the browser context, so it cannot discover dynamically defined API routes or hardcoded secrets that only appear after the client-side script runs. Running Nikto would be a useful complementary step during a comprehensive assessment, but it is not the correct method for analyzing JavaScript files to extract endpoints and credentials.

Use theHarvester to search for API endpoints

Why wrong: theHarvester is an OSINT tool designed to gather email addresses, employee names, subdomains, and hostnames from public sources like search engines, PGP key servers, and shodan, but it does not interact with the target web application's JavaScript. It performs passive reconnaissance across the internet, not client-side code analysis, and its output is limited to publicly indexed metadata, not API endpoints or secrets hardcoded into a live application's scripts. Using theHarvester here would be a misunderstanding of its role; it is a data collection tool, not a JavaScript parser or endpoint extractor.

crt.sh

Why wrong: crt.sh provides a searchable interface to Certificate Transparency (CT) logs, allowing analysts to identify SSL/TLS certificates issued for a domain and thereby enumerate subdomains. However, it only contains certificate metadata such as issuer, validity period, and subject alternative names, not the actual content of the websites that used those certificates. Therefore, it cannot be used to retrieve archived or historical versions of web pages, which is the specific requirement in this scenario.

Censys

Why wrong: Censys is a search engine that continuously scans the entire IPv4 and IPv6 address space, recording detailed information about services, open ports, and TLS certificates. While it does store historical network-level data, its records are structured around hosts and protocols rather than the rendered content of web pages. Consequently, Censys cannot provide the archived snapshots of a site's HTML and visual layout that the Wayback Machine offers.

Shodan

Why wrong: Shodan indexes internet-connected devices by probing ports and services, collecting response banners and metadata such as server software and location. Although Shodan occasionally captures screenshots of web services, these are incidental to its scanning and are not a comprehensive historical archive of a site's content. Therefore, it falls far short of the Wayback Machine's ability to view how a URL appeared at any given point in the past.

It eliminates false positives entirely

Why wrong: No scanning methodology can guarantee the complete absence of false positives. Even with valid credentials, a scanner can misinterpret configuration states, encounter incomplete patch data, or match vulnerability signatures incorrectly, leading to reported issues that do not actually exist under the specific deployment context. Authenticated scanning reduces this noise by inspecting local system state, but it does not eliminate the possibility of erroneous findings.

It reduces network traffic

Why wrong: Authenticated scanning typically increases network traffic rather than reducing it. The scan must first complete authentication handshakes, negotiate protocols, and maintain sessions for each target, then it often queries additional endpoints (registry, file system, services) that unauthenticated scans would not touch. This added communication can create a larger network footprint, especially in environments with many hosts.

It avoids detection by intrusion detection systems

Why wrong: Authenticated scans are not designed to evade intrusion detection; they can still be detected by IDS/IPS through patterns like repeated login attempts, unusual account usage, or the execution of scanner-related commands. Many IDS rules specifically flag credentialed scanning activities because they may resemble account compromise or lateral movement, and the scanner's privileged access can trigger alarms.

Gobuster

Why wrong: Gobuster is a high-speed brute-force tool used to enumerate directories, files, DNS subdomains, and virtual hosts by sending HTTP requests and matching response codes. It tells you whether a path exists but does not inspect the response body, headers, or scripting patterns to identify frameworks or libraries. Therefore, while it can reveal an admin panel or backup file, it cannot determine the underlying web technologies, making it unsuitable for the stated task.

theHarvester

Why wrong: theHarvester is an OSINT utility that queries search engines and public sources to harvest email addresses, hostnames, and subdomains associated with a target domain. It operates externally and never makes authenticated or direct HTTP requests to the target's web server to inspect banners, cookies, or JavaScript. Thus, it gathers reconnaissance metadata but lacks any mechanism for fingerprinting the specific web technologies in use.

Nmap

Why wrong: Nmap is a network scanner that performs host discovery, port scanning, and service/version detection via protocol-driven probes, and its version detection can sometimes identify the web server software. However, it does not recursively parse HTML, evaluate JavaScript files, detect CMS plugins, or identify frontend frameworks, so its web technology coverage is incidental and shallow. On a web app test, Nmap's version detection is a baseline, but it cannot replace a purpose-built HTTP fingerprinting tool.

DNS zone transfer

Why wrong: DNS zone transfer is an active reconnaissance technique because it involves sending an AXFR query directly to the target's authoritative DNS server, requesting a full copy of the zone file. This requires interacting with the target's infrastructure and typically only succeeds if the server is misconfigured to allow transfers from any host; a properly configured server will refuse, and the request itself is recorded in the DNS server's logs.

Scanning ports with Nmap

Why wrong: Scanning ports with Nmap is inherently active as it transmits crafted packets—TCP SYN scans, UDP probes, ICMP pings—to the target host. Every probe elicits a response (or a timeout-driven inferred state) that the scanner observes, and these packets are logged by intrusion detection systems and firewalls, making the activity detectable and attributable to the attacker's source IP.

Sending phishing emails

Why wrong: Sending phishing emails is clearly active because it involves direct interaction with the target's users and systems, delivering a malicious payload or credential-harvesting link to a recipient. This creates network traffic to and from the target, triggers email gateway logging, and often requires subsequent user interaction—making it a high-risk, intrusive technique that is the antithesis of passive reconnaissance.

nmap -sU

Why wrong: 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 wrong: 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 wrong: 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.

Running Nikto with default options

Why wrong: Nikto is fundamentally a vulnerability scanner, not a directory bruteforcer; it probes for known server-side vulnerabilities, outdated software, and misconfigurations using a built-in database of signatures. Although it includes some checks for common files and paths, its scanning logic is not optimized for exhaustive, recursive path enumeration, so it will miss many hidden directories and is slower for pure content discovery. Its role is to assess security weaknesses after directories are already found, not to discover them as a primary function.

Querying theHarvester

Why wrong: theHarvester is an OSINT tool that passively gathers information from public sources—such as search engines, PGP key servers, and certificate transparency logs—to collect emails, subdomains, and hostnames. It does not send HTTP requests to the target web application to probe for directories or files; rather, it mines third-party data that may indirectly hint at hosts, but never enumerates the application's internal path structure. Therefore, it is completely unable to discover directories on the target site, making it an incorrect option.

Nmap

Why wrong: Nmap is fundamentally a network mapping and port scanning utility that sends crafted packets to hosts to discover open ports, services, and OS fingerprints. While it includes a dns-brute NSE script for brute-forcing hostnames, that is a secondary add-on and lacks the breadth of passive intelligence sources—such as certificate transparency logs, search engine scraping, or DNS archive queries—that subdomain enumeration tools aggregate. In a real engagement, relying on Nmap for subdomain discovery would yield a sparse host list and likely miss the less common, security-relevant subdomains a tester needs.

dirsearch

Why wrong: dirsearch is a web content discovery tool that sends HTTP requests to a single target web root, cycling through a wordlist of paths and files to identify existing resources by analyzing response codes (e.g., 200, 301, 403). It operates entirely at the URI level after a hostname or IP is already known, so it has no mechanism to query DNS, parse certificate transparency records, or connect to passive OSINT APIs. By its design, dirsearch answers 'what directories exist on this web server?' not 'what hostnames point to this organization?'—the latter being the core task in subdomain enumeration.

Gobuster

Why wrong: Gobuster is a versatile brute-force tool with multiple modes, and its DNS mode does send DNS queries to a configured resolver for every word in a given wordlist to test if it resolves as a subdomain. However, this active brute-force approach only finds names that exist in the tester's wordlist and that pass DNS resolution; it ignores passive sources like certificate transparency logs, reverse WHOIS, or web search results that can reveal subdomains not guessable through a list. Amass, by contrast, integrates dozens of passive data feeds and cross-correlates findings using graph analysis, giving far greater coverage and reducing the chance of missing non-standard subdomains that a brute-force dictionary would overlook.

-sA

Why wrong: The -sA option directs Nmap to send TCP ACK packets to the target, a technique used primarily to probe firewall rules rather than determine whether a port is open or closed. Because any non-filtered state will respond with an RST, a response only confirms the host is reachable or that the firewall statelessly allows ACKs; no response suggests filtering. Therefore, the ACK scan cannot serve as a direct substitute for SYN scanning during active port discovery, as it lacks the ability to discriminate between listening and non-listening ports.

-sU

Why wrong: The -sU flag performs a UDP scan by transmitting UDP datagrams to potentially open ports and waiting for an ICMP Port Unreachable error from closed ports. Since open UDP services often send no reply, an empty response leaves the port in an open|filtered state, making the scan slow and less deterministic. This mode is also heavily reliant on ICMP rate limiting, and unlike SYN scanning, it requires substantial time and can be disrupted by unreliable UDP behavior, so it is not the ideal stealthy active reconnaissance technique.

-sT

Why wrong: The -sT option executes a full TCP connect scan by initiating the complete three-way handshake via the operating system's connect() syscall, and only reports the port open if the handshake succeeds. This method is easy to log and identify at the application or network level, and it consumes more time and connection resources than a half-open SYN scan. While it requires no raw-packet privileges, the fully completed connections are far more detectable, making it less suitable for stealth-focused active reconnaissance.

nmap -A 192.168.1.0/24

Why wrong: -A is an aggressive scan mode that layers OS fingerprinting (-O), version detection (-sV), default NSE scripts (-sC), and traceroute into a single run. Because these techniques all require port scan results to be useful, -A implicitly performs a full port scan across the target range, generating heavy traffic and taking considerably longer than a host discovery sweep. On a /24 subnet, this noise can trip IDS/IPS alerts and will not provide any additional benefit for the immediate goal of simply identifying which IPs are alive, making it an inefficient and risky choice at this early stage.

nmap -sS 192.168.1.0/24

Why wrong: -sS is a SYN stealth port scan, not a host discovery mechanism; it sends TCP SYN packets to a specific list of ports (commonly the top 1000) and analyzes the responses to classify ports as open, closed, or filtered. This means it only reveals liveness for hosts that happen to respond to one of those probed ports, so hosts without any open TCP ports or behind strict firewalls that drop unsolicited SYNs can be missed entirely. It also wastes network overhead by scanning hundreds of ports on every address instead of just checking whether each host is reachable, which is not the intended purpose of a post-initial-access subnet sweep.

nmap -O 192.168.1.0/24

Why wrong: -O is the flag for remote OS detection, which attempts to fingerprint the operating system by sending specially crafted TCP/IP packets and analyzing subtle differences in their responses. For this to work, Nmap first needs a port scan to identify open ports and a closed port to collect comparative probe data; if a host is alive but has no reachable open ports, -O will often fail to produce a conclusive fingerprint or may mark the host as filtered. Therefore, -O is a post-discovery enumeration technique that depends on knowing which hosts and ports are available, rather than a tool for initially discovering which IPs are up on a subnet.

Running Nikto for web server vulnerabilities

Why wrong: Nikto is a legacy web server scanner that sends a battery of predefined HTTP requests to identify outdated software, dangerous CGI files, and server misconfigurations. It does not parse JavaScript bundles or follow client-side application logic, so it cannot reveal API endpoints that are only defined as string literals or fetch calls. This makes it unsuitable for endpoint discovery, as its focus is purely on server-side vulnerability fingerprinting.

Directory bruteforcing with gobuster

Why wrong: Directory brute-forcing with gobuster makes thousands of HTTP requests based on a wordlist to identify existing paths, but it only finds resources that are directly accessible and return a distinct status code. Endpoints that are only referenced inside JavaScript are invisible to this method because they are not discovered through file-system enumeration. Additionally, it is noisy, may be blocked by rate limiting, and often misses non-standard API routes that require special headers or parameters.

Using Wappalyzer to fingerprint technologies

Why wrong: Wappalyzer infers the underlying technology stack by inspecting HTTP response headers, HTML meta tags, and JavaScript global identifiers, such as detecting React, Django, or jQuery. This is useful for selecting known exploits, but it provides no visibility into the specific URI structure, API endpoints, or routing tables of the application. It can tell you what framework is running, not which resources are exposed through that framework.

Ignore findings related to missing headers as low priority

Why wrong: Ignoring missing headers findings as low priority is inadvisable because headers such as Strict-Transport-Security, X-Frame-Options, and Content-Security-Policy play a critical security role; their absence can enable clickjacking, protocol downgrade attacks, or content injection. Even if Nikto classifies them as informational or low risk, a penetration tester should verify each finding and assess the real-world exploitability within the target environment, rather than dismissing them outright.

Increase the scan intensity to get more details

Why wrong: Increasing scan intensity (e.g., higher nmap timing, deeper directory brute force, or more aggressive Nikto tuning) may yield additional data, but it also raises the risk of false positives, server load, or even crashing the target. More importantly, it doesn't address the core problem: existing scan results still need validation, and aggressive scanning could introduce new variables or inconsistencies, making the findings even harder to interpret rather than clearer.

Accept all findings as true since Nikto is a reliable tool

Why wrong: While Nikto is a widely used and respected web vulnerability scanner, it is not a substitute for human judgment; its database of tests can flag benign files, outdated software versions, or missing headers that are not actually exploitable in the specific context. Blindly accepting every automated result as true would lead to wasted resources chasing phantom issues and could obscure real, verified vulnerabilities in the final report, so every finding must be correlated with manual inspection.

NS record query

Why wrong: 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 wrong: 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 wrong: 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.

Analyzing malware samples

Why wrong: Shodan is an internet device search engine that catalogs banner data and service fingerprints from publicly reachable IPs; it does not receive, execute, or analyze malware binaries. Malware analysis typically requires a sandbox or disassembler to inspect code behavior, not a network index. Therefore, using Shodan for this purpose is incorrect.

Exploiting vulnerabilities in IoT devices

Why wrong: While Shodan can reveal IoT devices with known default credentials or outdated firmware (e.g., exposed cameras or routers), it only surfaces information from banners and protocol handshakes; it does not actively attempt to compromise devices or run exploit code. Penetration testers might use Shodan to find targets, but exploitation is performed with separate tools like Metasploit or custom scripts. So the statement that Shodan itself exploits is wrong.

Performing live port scans on target IPs

Why wrong: Shodan does not offer on-demand scanning of arbitrary targets; its database is built from its own scheduled, global scanning campaigns. If a pen tester needs real-time port state or service version information for a specific IP, they must use tools like Nmap directly, which conduct active scans. Thus, Shodan acts as a historical index rather than a live scanning tool.

OpenVAS

Why wrong: OpenVAS is a full-scope network vulnerability scanner that performs port mapping, service discovery, and OS-level CVE enumeration across an entire network. It does not have a WordPress-specific fingerprinting engine or the ability to enumerate plugin/theme versions or test wp-login brute force, so its results are too broad to catch application-level WordPress flaws.

Nikto

Why wrong: Nikto is an open-source web server scanner that looks for generic signature issues like default files, insecure CGI binaries, and server header problems. It lacks WordPress-aware logic, so it cannot identify plugin versions from readme.txt or enumerate users through the WordPress REST API, rendering it insufficient for a WordPress-dedicated pen test.

Gobuster

Why wrong: Gobuster is a fast directory, file, DNS, and virtual-host enumerator that brute-forces URLs using wordlists, making it useful for discovering hidden paths like /wp-admin or /wp-content/uploads. It does not execute any vulnerability detection or WordPress version/plugin fingerprinting, so even when it finds a path, it cannot assess the target's security posture or identify an exploitable issue.