Reconnaissance practice questions

Nmap with -sS flag

Why it fails: Nmap -sS is an active SYN stealth scan that interacts directly with the target infrastructure. This generates significant network traffic, which is easily detected by intrusion detection systems. Passive reconnaissance aims to remain invisible to the target organization while gathering intelligence through publicly accessible third-party sources or DNS infrastructure queries.

Netcat

Why it fails: Netcat is a versatile networking utility used for reading from and writing to network connections. While it can interact with DNS ports, it is not designed to automate the discovery of subdomains. It lacks the enumeration logic and wordlists required to systematically query DNS for hidden hostnames during a reconnaissance engagement.

Metasploit Auxiliary Modules

Why it fails: Metasploit auxiliary modules are generally used for active exploitation or vulnerability scanning rather than passive reconnaissance. Utilizing these modules often involves direct interaction with the target, which violates the principles of passive information gathering. Reconnaissance should focus on non-intrusive methods to map the target environment without triggering security alerts.

A (Address)

Why it fails: While A records map names to IPs, they are foundational rather than insightful for infrastructure details. In a multi-select question, A records are less 'useful' for specific infrastructure inference compared to MX, PTR, and CNAME, which explicitly reveal services, pointers, and aliases that provide more context for the target.

SOA (Start of Authority)

Why it fails: SOA records contain administrative information for a zone, such as the primary name server and contact details. While technically part of the DNS zone, it provides less insight into the target's actual service infrastructure compared to records that describe mail flow, reverse lookup data, or alias mappings.

Running a full TCP port scan on the entire public IPv4 space

Why it fails: Scanning the entire IPv4 space is impractical and highly illegal. It would generate massive amounts of noise and result in the tester's IP being blacklisted by ISPs. Reconnaissance should be focused on the target's specific infrastructure. Indiscriminate scanning is not a valid or professional reconnaissance strategy for a penetration tester.

Attempting to brute-force the organization's corporate LDAP server

Why it fails: Brute-forcing an internal LDAP server is an active, aggressive, and highly intrusive attack. It is not a method for cloud reconnaissance. This activity would likely trigger an immediate security response and is generally considered out of scope for the reconnaissance phase of most professional penetration testing engagements.

Performing a Man-in-the-Middle attack on the corporate Wi-Fi

Why it fails: This is a physical or network-local attack that requires proximity to the target's corporate site. It is unrelated to discovering cloud infrastructure. Cloud reconnaissance focuses on the public-facing aspects of the target's presence, not on local network attacks that would be performed during a later, more intrusive phase.

Nmap

Why it fails: Nmap is an active scanning tool used for port discovery and service enumeration. Since the objective is passive reconnaissance via search engines, utilizing Nmap would transition the engagement into an active state, potentially generating logs and alerting the target security operations center to your presence prematurely.

Shodan

Why it fails: Shodan is an excellent search engine for Internet-connected devices, but it is not a tool for performing advanced dorking queries on traditional web search engines like Google or Bing. While powerful for identifying services, it does not fulfill the requirement of automating specific Google dorking queries.

Wireshark

Why it fails: Wireshark is a packet analyzer designed for inspecting network traffic in real-time or from captured pcap files. It cannot perform search engine dorking or interface with web-based indexers to discover sensitive files or administrative portals, making it entirely unsuitable for this specific passive reconnaissance objective.

Perform a DNS zone transfer on the target's mail domain to extract a list of email addresses

Why it fails: DNS zone transfers do not contain email addresses; they contain DNS records like MX, A, and TXT. Even if a zone transfer is successful, it would not provide a list of employee email addresses. This technique is irrelevant to email enumeration and would not help verify addresses. It also requires an active query to the target's DNS server.

Query the target's SMTP server with the VRFY command for each candidate address

Why it fails: The VRFY command is often disabled on modern SMTP servers, especially cloud-based services, to prevent address enumeration. Even if enabled, sending VRFY commands directly to the target's SMTP server generates logs and may trigger alerting. This is an active technique that interacts with the target's infrastructure, violating the stealth requirement.

Send test emails to candidate addresses and monitor for bounce-backs from the target's mail server

Why it fails: Sending test emails directly to the target's mail server is an active technique that will generate logs and may trigger spam filters or alerting. Bounce-backs can reveal valid addresses, but the method involves direct interaction and could be considered intrusive. It also risks your IP being blacklisted or the test being detected.

nmap -sn 192.168.1.0/24

Why it fails: The -sn option performs a ping scan, which typically uses ICMP echo requests to discover hosts. Since the scenario states that ICMP is blocked, this scan would likely miss live hosts. It does not use TCP SYN packets to common ports, making it ineffective here.

nmap -sU -p 53 192.168.1.0/24

Why it fails: The -sU option initiates a UDP scan, which is connectionless and often unreliable for host discovery due to lack of response. While it can be used to scan UDP port 53, it does not use TCP SYN packets and is not the best choice for identifying live hosts when ICMP is blocked.

nmap -sT -p 80,443 192.168.1.0/24

Why it fails: The -sT option performs a TCP connect scan, which completes the full three-way handshake. While it can identify live hosts, it is less stealthy and may be logged by the target. It does not specifically address ICMP blocking, and the full connection is more likely to be detected.

TheHarvester and Maltego

Why it fails: TheHarvester collects emails, hostnames, and employee names from public sources, and Maltego is a link-analysis platform that can visualize relationships among entities. While both are useful OSINT tools, neither maintains its own historical DNS database. They surface current or indexed data and depend on other sources for historical records, so they do not by themselves provide the historical infrastructure mapping the scenario requires.

Nmap and Masscan

Why it fails: Nmap and Masscan are active port scanners that send packets directly to target addresses. Using them would generate traffic on the target's perimeter and could trigger intrusion detection alerts, violating the requirement to avoid alerts. They also report current state only, not historical mappings, and they require you to already know which IP ranges to scan, so they do not fit the passive, historical requirement.

Shodan and Censys

Why it fails: Shodan and Censys are internet-wide scan databases that index currently exposed services and banners. They are excellent for identifying live hosts and service versions, but they reflect a snapshot of what is reachable now rather than a historical mapping. They also may not associate hosts with the organization if the IP space is not clearly labeled, so they do not directly satisfy the requirement for historical infrastructure data.

HaveIBeenPwned API

Why it fails: HaveIBeenPwned is excellent for checking breached credentials, but theHarvester's integration with it is limited to domain-wide breach exposure, not email enumeration. It returns lists of breached accounts but does not provide employee names or email patterns. Relying solely on this source would leave you without the broad email and name data that a penetration test recon phase requires.

Bing search engine

Why it fails: Bing is a search engine that theHarvester can query, but querying it still involves sending requests to Bing's servers, not the target. While Bing may return indexed pages containing emails, it often lags behind other sources and does not aggregate data from multiple public repositories. For maximum passive collection with zero target contact, a dedicated OSINT API that compiles data from numerous sources is more efficient and less likely to miss recent leaks.

Shodan

Why it fails: Shodan is a search engine for internet-connected devices and services, not people. It can reveal exposed services, banners, and vulnerabilities but does not index email addresses or employee names. Using Shodan during theHarvester execution would yield host and service data, which is useful for active scanning but does not fulfill the requirement for passive email and name enumeration.

Use a DNS cache snooping technique against the target's recursive resolver.

Why it fails: DNS cache snooping sends queries to the target's recursive resolver, which is part of the target's infrastructure. This is an active technique that generates traffic to the target and may be logged. Furthermore, it only reveals whether a record is cached, not the actual internal IP address. It also does not work if the resolver is configured to refuse non-recursive queries, and it violates the passive requirement.

Query a public DNS resolver like 8.8.8.8 for each subdomain.

Why it fails: Querying a public resolver still sends DNS queries, but they go to Google's resolver, not the target's authoritative nameserver. However, this does not reveal internal IP addresses because public resolvers only have access to the external DNS view. In a split-horizon setup, internal names resolve to private IPs only from internal resolvers. Using 8.8.8.8 would return either NXDOMAIN or public IPs, not the internal addresses you seek.

Perform a zone transfer (AXFR) against each authoritative nameserver.

Why it fails: An AXFR zone transfer is an active query sent directly to the target's authoritative nameserver. It would reveal internal records only if the server is misconfigured to allow transfers, but it also generates logs and alerts on the target side. This violates the requirement to avoid sending DNS queries to the target's nameservers. Additionally, split-horizon configurations typically prevent zone transfers from the external view, making this approach both noisy and ineffective.

Performing a brute-force attack on the corporate firewall

Why it fails: Brute-forcing a firewall is an active, aggressive reconnaissance technique that will likely trigger security alarms. OSINT gathering is inherently passive, focusing on external information sources. Engaging in brute-force activities during the initial reconnaissance phase is counter-productive, as it risks detection and blocking before any meaningful intelligence has been successfully acquired.

Conducting a port scan of the internal network

Why it fails: Port scanning internal network segments is an active reconnaissance technique usually performed after gaining an initial foothold or within the perimeter. This falls outside the scope of passive OSINT gathering. Effective OSINT focuses on non-intrusive collection methods, whereas port scanning generates identifiable traffic patterns that are easily monitored by security teams.

Directly calling the IT helpdesk to request employee email addresses

Why it fails: This is a form of active social engineering, not passive reconnaissance. While effective for obtaining information, it involves direct interaction with the target organization. Passive reconnaissance methods are prioritized early in an engagement to minimize the risk of detection. Direct contact should be reserved for later stages of an authorized penetration test.

To bypass the target organization's firewall.

Why it fails: Google Dorks are search queries used on external search engines to find public information. They cannot interact with or bypass a firewall because they do not involve direct communication with the target's network. They are purely an information gathering technique for data already indexed by third-party search platforms.

To execute remote code on the target's web server.

Why it fails: Google Dorks are read-only search queries and lack the capability to execute code. They are strictly for information retrieval. Attempting to use search operators to trigger server-side code execution is impossible because the search engine acts as an intermediary, not a conduit to the target server's execution environment.

To perform a brute-force attack on user credentials.

Why it fails: Brute-force attacks require repeated interactions with an authentication endpoint. Google Dorks are static search queries directed at a search engine's index. They cannot be used to perform authentication attempts against a target system. They are purely for discovery and do not support the interaction required for credential testing.

To increase the speed of the DNS resolution process.

Why it fails: WHOIS data is for ownership and administrative record keeping, not for accelerating DNS resolution. The speed of DNS resolution depends on the configuration of authoritative name servers and local caching. Using multiple registries does not improve network performance; it only improves the accuracy of ownership information for IP addresses.

To bypass the need for an active port scan.

Why it fails: WHOIS lookups provide administrative information, not service availability or port status. While it helps in scoping, it does not replace the need for active scanning to determine which services are actually running. Port scanning is required to verify the technical state of the identified infrastructure regardless of ownership.

To automatically detect if a server is running an exploit.

Why it fails: WHOIS databases contain registration details and administrative contact information. They do not contain technical information regarding running services, vulnerabilities, or exploit statuses. This information is purely administrative and is distinct from the technical vulnerability assessment data gathered during the active scanning phase of the penetration test.

The files can be used to execute arbitrary commands on the client machine.

Why it fails: Metadata harvesting itself does not execute code. While the files might contain malicious macros, the act of extracting metadata is a passive read-only operation. The risk lies in the information disclosed within the metadata, not in the metadata extraction tool's ability to trigger code execution on the client.

It indicates the current load on the corporate web server.

Why it fails: Metadata relates to the file's creation and properties, not the server's operational load. Server load is determined by analyzing response times or specialized headers, not file-level metadata. Therefore, metadata analysis is an ineffective method for measuring the server's current resource utilization or performance metrics during reconnaissance.

It bypasses the need for an external vulnerability assessment.

Why it fails: Metadata is just one piece of the reconnaissance puzzle. It does not replace the need for vulnerability assessment, which identifies weaknesses in the technical infrastructure. While metadata provides clues, a full assessment is required to validate the actual security posture of the systems and applications being analyzed.

To improve the speed of data transfer during scans.

Why it fails: Anonymity measures like VPNs or proxies typically introduce latency and reduce overall network throughput. They are used for security and operational secrecy, not for performance optimization. Using non-attributable sources is a tactical decision to maintain the stealth of the engagement, acknowledging that performance might be negatively impacted as a result.

To bypass the need for explicit written authorization.

Why it fails: Anonymity does not replace the requirement for legal authorization. All penetration testing must be conducted under a strict contract. Anonymity is a tool for professional practice, not a mechanism to bypass legal or ethical requirements. Regardless of the source IP, the tester must have written permission to perform actions.

To increase the accuracy of vulnerability detection tools.

Why it fails: The accuracy of scanning tools is determined by the tool configuration and the target's response, not the source IP. Using an anonymous proxy does not improve the tool's ability to identify vulnerabilities; in fact, it may cause issues if the proxy alters packet headers or disrupts the TCP handshake process.

Immediately run a Metasploit exploit module against the server.

Why it fails: Launching an exploit before fully understanding the risk and testing environment is reckless. It could crash the service or trigger an alert without having a secondary plan. Reconnaissance should lead to structured research, where the tester understands the vulnerability before attempting to exploit it in a controlled manner.

Contact the organization's IT department to report the vulnerability.

Why it fails: A penetration tester is hired to test the security of an organization, not to provide immediate remediation services during the reconnaissance phase. Reporting the issue directly is outside the scope of the engagement contract unless specifically requested by the client. The tester must follow the agreed-upon reporting process.

Ignore the CMS and look for other systems.

Why it fails: An unpatched CMS is a significant finding that could provide an easy initial foothold into the target's network. Ignoring it is a missed opportunity for a thorough assessment. Every discovered vulnerability should be documented and evaluated for its potential to contribute to the overall success of the test.

To identify vulnerabilities without touching the server.

Why it fails: Passive reconnaissance cannot identify vulnerabilities in the same way active scanning does. It can identify potentially vulnerable software versions, but the actual existence of a vulnerability must be validated through active interaction. Passive methods are for discovery, not for definitive vulnerability validation against a specific service endpoint.

To guarantee access to the target's internal network.

Why it fails: Reconnaissance does not grant access. It is purely an information-gathering stage. No amount of passive reconnaissance will provide direct access to an internal network. Access must be earned through the exploitation of vulnerabilities discovered during the later stages of the testing process, which is why reconnaissance is just the beginning.

To bypass the organization's internal intrusion detection systems.

Why it fails: Passive reconnaissance doesn't bypass IDS because it never interacts with the target network's traffic monitoring. It gathers data from external sources that the target does not control. Bypassing an IDS is a technique used during the exploitation or movement phases, not during the initial reconnaissance of publicly available data sources.

SSH brute-force tools

Why it fails: SSH brute-force tools are used for attempting unauthorized access to a system. They are not for reconnaissance regarding physical location or IP ownership. Engaging in brute-force attacks during the reconnaissance phase is highly intrusive and will likely cause the tester's IP to be blocked, failing the goal of stealthy reconnaissance.

Packet sniffing on the target's Wi-Fi

Why it fails: Packet sniffing is an active activity that requires local network access. It is not a method for determining IP ownership or registration details. Using a sniffer for reconnaissance is inappropriate and violates the passive nature of the information gathering phase, as it involves intercepting live traffic from the organization.

Web browser history inspection

Why it fails: Web browser history is local to the user's machine and has no relevance to identifying the ownership or location of a remote organization's network infrastructure. This is a client-side activity and does not provide any intelligence regarding the target's network, which is the primary focus of the reconnaissance phase.

Internal employee passwords from active memory.

Why it fails: theHarvester is an OSINT tool that collects public information. It cannot access internal memory or extract passwords. Any attempt to gain passwords from memory would require access to the host system, which is far beyond the scope of passive OSINT gathering. It is strictly limited to harvesting publicly accessible data.

SQL injection vulnerabilities on web forms.

Why it fails: theHarvester is not a vulnerability scanner. It does not test web forms for SQL injection or any other type of security flaw. It only collects public contact and structure information. Vulnerability scanning requires active tools that specifically probe web application endpoints, which is a different phase of the penetration test.

Full network topology maps including internal routers.

Why it fails: theHarvester cannot map internal network topology. It is restricted to collecting information available on public search engines and servers. It has no capability to probe internal network infrastructure or routers. Mapping an internal network is a highly intrusive activity that would occur much later in the penetration testing process.

Perform DNS cache snooping against the internal recursive resolver

Why it fails: Cache snooping requires sending queries to the internal recursive resolver, which is an active technique that sends traffic to the internal network. It also only reveals recently cached records, not the full internal namespace. This would not meet the requirement of avoiding traffic to the internal network and is unlikely to yield comprehensive internal hostnames.

Use DNS zone transfer requests against the external authoritative name servers

Why it fails: Zone transfers against external authoritative servers typically only reveal public DNS records, not internal hostnames. In a split-horizon setup, the external view is intentionally limited. Even if a zone transfer succeeds, it would not expose the internal namespace, which is served by separate internal DNS servers that are not accessible externally.

Query the internal DNS server directly using its private IP address

Why it fails: Directly querying the internal DNS server requires network access to the private IP address, which you do not have from an external perspective. This would be an active technique that sends traffic to the internal network, violating the requirement to avoid touching the internal network. It also assumes the internal DNS server is reachable, which is unlikely from the internet.

traceroute

Why it fails: traceroute is used to trace the path packets take to a destination host. It does not interact with DNS zone transfer mechanisms and cannot retrieve zone data. Its role is network path discovery, not subdomain enumeration via zone transfers.

nmap

Why it fails: nmap is primarily a port scanner and network mapper. Although it can perform some DNS queries via NSE scripts, it is not designed for zone transfers. Using nmap for this purpose would be inefficient and non-standard; dig is the correct tool for attempting an AXFR.

whois

Why it fails: whois queries domain registration databases to obtain ownership and contact information. It does not perform DNS zone transfers or retrieve subdomain records. While useful for reconnaissance, it does not fulfill the specific requirement of attempting an AXFR.