Enumeration and Reconnaissance practice questions

Attempt a brute-force login with a large password list.

Why it fails: Brute-forcing RDP is extremely noisy and likely to be detected by account lockout policies. This is a poor reconnaissance step and should only be performed after careful consideration of the risks, as it does not provide information about the service version or configuration, which are the real objectives.

Connect using the telnet command.

Why it fails: Telnet is not compatible with the RDP protocol. Attempting to connect to port 3389 using Telnet will fail to establish a session and provides no meaningful information about the service. This is a waste of time and does not contribute to the enumeration of the target host's services.

Send an HTTP GET request to the port.

Why it fails: Port 3389 is for RDP, not HTTP. Sending an HTTP request to this port will not result in a valid response or provide information about the RDP service configuration. This is an incorrect application of protocols and demonstrates a lack of understanding regarding the port's function.

Upload a PHP web shell to the /includes/ directory to verify write permissions.

Why it fails: While web shells are useful, attempting to upload one before verifying existing credentials is premature and potentially noisy. Testing the discovered credentials is a passive or low-impact action that could provide access without needing to modify the file system, thereby reducing the risk of triggering file integrity monitoring systems.

Perform a full port scan on the target using Nmap to identify other listening services.

Why it fails: Port scanning is a standard enumeration task, but it is less urgent than validating the discovered credentials. Once you have a username and password, prioritizing their use allows you to pivot quickly. You can scan for other services concurrently or later, but the credentials offer an immediate, high-probability exploit path.

Delete the config.php.bak file to hide your tracks and prevent others from finding it.

Why it fails: Deleting files is an intrusive action that can alert system administrators to your presence through file integrity alerts or unexpected application errors. Maintaining the integrity of the target environment while enumerating is crucial for long-term stealth; focus on using the information gained rather than modifying the environment.

nmap -sU -p 161 --script snmp-info <target>

Why it fails: The snmp-info script attempts to retrieve system information but often relies on the same default community strings and may behave similarly to the brute script if the community string is non-default or the service is firewalled. It is less reliable for a first manual check and does not let you specify an arbitrary OID.

onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt <target>

Why it fails: onesixtyone is a community string scanner, not an information retrieval tool. It would help discover the correct community string, but the scenario implies you already know SNMP is running; you need to extract data. After finding the community string, you would still need snmpwalk to pull system information.

snmpget -v2c -c private <target> 1.3.6.1.2.1.1.1.0

Why it fails: Using the community string 'private' is a guess and often wrong; 'private' is typically used for read-write access, not read-only. Also, snmpget retrieves a single OID, whereas snmpwalk on the system group retrieves multiple useful values at once. This command may fail if the community string is not 'private'.

The target is using SNMPv3 with no authentication and no encryption.

Why it fails: SNMPv3 with no authentication and no encryption (noAuthNoPriv) does not use community strings. The command specified '-v2c' and '-c public', which are SNMPv2c parameters. Therefore, this option is incorrect because the protocol version and security model do not match the command used.

The target's firewall is allowing all UDP traffic to port 161 from any source.

Why it fails: While the firewall may allow UDP 161, that alone would not cause the SNMP service to return information. The service must also be configured with a valid community string. The firewall rule is a necessary but not sufficient condition; the default community string is the key factor here.

The SNMP service is configured to allow any community string for read access.

Why it fails: SNMP does not have a configuration that allows any community string by default. The service must be explicitly configured with specific community strings, and 'public' is a common default. The success indicates that 'public' is valid, not that any string would work.

Perform a pass-the-hash attack using the bcrypt hashes against the web application's login form.

Why it fails: Pass-the-hash is a technique for NTLM or similar challenge-response protocols, not for bcrypt hashes used in a web application's database. Web login forms typically hash the submitted password and compare it to the stored hash, so you cannot replay the hash directly. You must crack the bcrypt hashes to recover plaintext passwords.

Use `hashcat -m 0` to crack the hashes in mode 0 (MD5).

Why it fails: Mode 0 in `hashcat` is for raw MD5, but the hashes are bcrypt, not MD5. Running mode 0 would produce no matches because the algorithm is incorrect. The correct `hashcat` mode for bcrypt is 3200. Choosing the wrong mode wastes time and may mislead you into thinking the hashes are uncrackable.

Use the `users` table entries to perform a SQL injection attack on the login form.

Why it fails: You already have the database contents, including the password hashes. SQL injection would be redundant and does not leverage the information you obtained. The immediate goal is to convert the hashes into usable credentials, which requires offline cracking, not further injection attempts that may be unnecessary.

net group "Domain Computers" /domain

Why it fails: `net group "Domain Computers" /domain` lists the members of the Domain Computers group, which includes all workstations and member servers but not domain controllers. While this provides a list of computers, it may not include all computer objects (e.g., domain controllers are in a different group). Also, the output can be large and may not be as straightforward as dsquery.

net view /domain

Why it fails: `net view /domain` lists the domains in the network, not the computers within a specific domain. It requires the Computer Browser service, which is often disabled in modern Windows environments. To list computers in the current domain, you would use `net view /domain:<domain_name>`, but that still relies on the Computer Browser service and may not work reliably.

nltest /dclist:<domain>

Why it fails: `nltest /dclist:<domain>` lists all domain controllers in the specified domain, not all computers. While domain controllers are critical targets, the goal is to enumerate all computers. This command is useful for identifying DCs but does not provide a full list of member servers and workstations.

TCP SYN scanning with `nmap -sS` against all hosts.

Why it fails: A full TCP SYN scan sends packets to every port on every host, which is noisy and easily detected by IDS/IPS. Even though SYN scanning is faster than a full connect scan, the volume of packets and the half-open connections can trigger alerts. It is not a stealthy host discovery technique when applied broadly.

ICMP echo requests with `nmap -sn` to a range of IPs.

Why it fails: ICMP echo requests are commonly blocked by firewalls and are easily detected by IDS. Using `nmap -sn` with ICMP may miss hosts that do not respond to ping and will generate log entries on monitored networks. It is not the most appropriate choice for stealthy host discovery.

Passive network sniffing with `tcpdump` on a mirrored port.

Why it fails: Passive sniffing does not generate traffic and is inherently stealthy, but it requires access to a mirrored port or a hub, which may not be available. It also only reveals hosts that are actively communicating. While useful, it is not an active technique and may not discover all live hosts, so it is not the best answer for active reconnaissance.

`smbclient -L //10.10.10.25 -p 445 -N`

Why it fails: Specifying port 445 with `-p 445` forces the connection to the closed port, which will fail. Since port 445 is closed, this command cannot list shares. The `-p` flag is used to override the default port, but here it points to an unavailable service, making the command ineffective.

`nmap --script smb-enum-shares -p 139 10.10.10.25`

Why it fails: The `smb-enum-shares` NSE script is designed to work over port 445 and may not function correctly on port 139. While it can sometimes work over NetBIOS, it is less reliable than `smbclient` for this specific scenario. Using `smbclient` directly ensures a connection over the correct port and protocol.

`enum4linux -a 10.10.10.25`

Why it fails: `enum4linux` is a powerful enumeration tool that can list shares, users, and more, but it primarily relies on port 445 and may not work correctly when only port 139 is open. It can sometimes fall back to NetBIOS, but `smbclient` is more direct and reliable for listing shares over port 139. `enum4linux` is better suited for comprehensive enumeration when port 445 is available.

Send a UDP packet to port 53 and wait for a DNS response.

Why it fails: UDP discovery relies on application-level responses which are often unreliable due to firewall rules or services not running. If the DNS service is not active or if the packet is dropped silently, you will incorrectly conclude the host is offline, leading to missed targets during your reconnaissance phase.

Use ARP scanning regardless of the network topography.

Why it fails: ARP scanning is restricted to the local subnet and will not work if the target host resides in a different network segment. Relying on ARP for host discovery outside the local broadcast domain will fail because routers do not forward ARP requests, making this technique contextually inappropriate.

Send a broadcast ping to the entire subnet range.

Why it fails: Broadcast pings are generally ignored by modern operating systems and network devices to prevent amplification attacks. Using this method is ineffective in modern, well-configured networks and may trigger network intrusion detection systems, leading to your source IP being blocked before you even begin your actual enumeration process.

Immediately attempt to exploit the FTP service with anonymous login.

Why it fails: While FTP enumeration is valid, focusing on the web service is generally more productive for initial entry if the web application lacks security controls. Prioritizing FTP without knowing if anonymous access is enabled is less efficient than gathering reconnaissance data from a web server that is already confirmed open.

Brute-force the SSH service using a list of common passwords.

Why it fails: SSH brute-forcing is noisy and likely to be detected by modern intrusion detection systems or account lockout policies. This action should be avoided early in the engagement unless you have confirmed that the target is highly vulnerable or you have no other viable path for initial access.

Run a full vulnerability scanner against the entire target IP.

Why it fails: Blindly running full vulnerability scanners is often ineffective and generates excessive traffic that flags your activities to security teams. Manual enumeration techniques provide more accurate and context-aware insights, allowing you to tailor your testing efforts to the specific services found rather than relying on noisy, automated tool outputs.

Perform a brute-force attack on the C$ share.

Why it fails: Brute-forcing administrative shares is aggressive and likely to trigger account lockout policies or security alerts. Administrative shares usually require high-level privileges, and attempting to guess credentials for them is inefficient compared to identifying misconfigured shares that allow anonymous or guest read access, which is a common vulnerability.

Attempt to ping the host using ICMP to check SMB connectivity.

Why it fails: Pinging a host only confirms that the network path is open and the host is active; it provides zero information regarding SMB share availability or configuration. This step is unrelated to the specific goal of enumerating SMB shares and does not contribute to gathering the required filesystem intelligence.

Use the telnet command to connect to port 445.

Why it fails: Telnet is designed for interactive text communication and is incapable of performing the complex SMB handshake required to list shares. While it can confirm that the port is open, it cannot provide the functional data necessary to enumerate the actual file structure or permissions of the SMB environment.

netcat

Why it fails: Netcat is a versatile networking utility often used for manual banner grabbing or simple data transfers. While it can connect to ports, it is not designed for efficient, large-scale port scanning or service version detection, which are better handled by dedicated scanners like Nmap in a professional assessment.

Wireshark

Why it fails: Wireshark is a packet analyzer used for inspecting network traffic in real-time. It is excellent for deep protocol analysis but is not a scanning tool designed to probe ports or identify remote service versions on a target host, making it unsuitable for the initial reconnaissance phase of an assessment.

grep

Why it fails: Grep is a command-line text search utility used to find patterns within files. It is purely for data processing and string manipulation and lacks any networking capabilities required for interacting with remote targets, identifying open ports, or performing the service enumeration necessary during the reconnaissance phase of testing.

The color scheme of the website.

Why it fails: The visual design and color scheme of a website do not provide any information regarding security posture or potential vulnerabilities. Focusing on superficial elements wastes time and distracts from the technical reconnaissance required to identify exploitable code or configuration weaknesses in the underlying application and server infrastructure.

The number of images hosted on the server.

Why it fails: The quantity of images hosted has no relevance to the security of the application. While image metadata might occasionally reveal minor information, the count itself is a distraction that does not aid in finding logical flaws, misconfigurations, or software vulnerabilities necessary for successful exploitation during a penetration test.

HTTP on port 80

Why it fails: Port 80 is used for web services and is not the protocol used for querying domain directory information. While some web-based portals might display user names, they are not the primary source for comprehensive user enumeration in an Active Directory environment, making this an ineffective target for this goal.

FTP on port 21

Why it fails: FTP is a file transfer protocol and is not designed for directory service lookups or user enumeration. While an FTP server might reside on a domain controller, it does not provide the mechanism to query the Active Directory database for user account information, making this an incorrect target.

SMTP on port 25

Why it fails: SMTP is used for email transmission. While some SMTP servers may support the VRFY command for user verification, this is rarely reliable on modern systems and is not the standard protocol for general directory enumeration in an Active Directory domain, making it an inferior choice for this specific task.

The operating system is exclusively Windows.

Why it fails: The header explicitly mentions Ubuntu, which is a Linux distribution. Claiming the OS is Windows contradicts the provided exhibit data, which shows a standard Linux-based software stack. Incorrectly identifying the OS would lead to attempting non-applicable exploits, wasting time and potentially triggering alarms on the target system.

The database being used is Microsoft SQL Server.

Why it fails: The headers show no information regarding the back-end database. PHP and Apache can interface with many databases, such as MySQL or PostgreSQL. Assuming a Microsoft SQL Server back-end based on these headers is unsupported and would likely lead to incorrect exploitation strategies during the assessment process.

The application is currently configured for debugging mode.

Why it fails: The provided headers contain typical server information and do not indicate a debug mode. Debugging headers are usually more descriptive, often revealing internal file paths or variable contents. The current headers provide no evidence to support the claim that the application is running in a debug state.

Attempt a brute-force attack on the SSH service.

Why it fails: SSH is unrelated to SNMP on port 161. Attempting to brute-force SSH when SNMP is available ignores the primary target of interest. SSH brute-forcing is also more likely to be detected by security systems, making it a poor choice compared to checking for default SNMP community strings.

Run a full Nmap script scan for all protocols.

Why it fails: While Nmap is useful, performing a full scan for all protocols is inefficient and generates excessive network traffic. Targeted exploitation or enumeration of the specific service found is preferred in professional testing to maintain a low profile and focus efforts on the most likely vectors of compromise.

Ignore the port as it is rarely used for anything critical.

Why it fails: SNMP is a common and often overlooked vector for significant information disclosure. Ignoring it is a mistake because network administrators frequently leave it running with default settings, providing an easy entry point for intelligence gathering. Expert testers know that every open port potentially holds a critical piece of information.

Use ping to verify the host is reachable.

Why it fails: Ping only confirms connectivity and provides no information regarding service versions or vulnerabilities. Using it to assess for SMB exploits is useless, as it cannot interact with the SMB protocol or perform any kind of vulnerability detection, making it an inappropriate tool for this specific technical requirement.

Run a full Nessus scan against the IP.

Why it fails: While Nessus is a powerful scanner, running a full scan is often too noisy and against the methodology of a focused manual penetration test. Using targeted scripts is preferred to reduce the risk of crashing the target system and to maintain a more controlled and surgical testing environment.

Use telnet to manually send an exploit string.

Why it fails: Telnet is not suitable for sending complex binary exploit strings for SMB vulnerabilities. Attempting this manually is prone to error, highly unlikely to succeed, and lacks the precision required for testing specific vulnerabilities. Using specialized tools like Nmap scripts or Metasploit modules is the correct, professional approach.

Perform a full port scan on all 65535 ports concurrently.

Why it fails: Scanning all ports concurrently generates a massive spike in network traffic, which is a primary indicator for IDS/IPS systems. This is extremely noisy and will almost certainly alert the target's security team, violating the principle of stealth and potentially leading to the tester's IP being blacklisted early on.

Use aggressive service detection flags in all scans.

Why it fails: Aggressive service detection flags force the scanner to perform deep probes and multiple handshake attempts, creating highly unusual traffic patterns that are easily flagged by security analysts. This behavior is the opposite of stealth and should only be used when necessary and with full authorization for a noisy test.

Scan from the same IP address at all times.

Why it fails: Consistently scanning from the same IP address makes it trivial for security teams to identify and block the source. While sometimes required by the scope, failing to vary techniques or utilize proxying when allowed decreases the chance of long-term success during a multi-day or multi-week penetration testing engagement.

It indicates the server is using an outdated version of Apache.

Why it fails: The presence of a .git directory is a configuration error of the application deployment, not the web server software itself. It implies that the version control metadata was accidentally uploaded, which is a distinct issue from the underlying Apache server version and should be treated as such.

It means the server is vulnerable to SQL injection.

Why it fails: While the source code might reveal SQL injection vulnerabilities, the presence of a .git directory itself does not imply that the application is vulnerable. It is a source of information that requires manual analysis; the vulnerability is a separate issue that must be discovered through careful code review.

It suggests that the server is running on a Windows OS.

Why it fails: Git is platform-independent and can be found on both Linux and Windows servers. The directory's existence is entirely independent of the operating system choice. Assuming the OS based on the presence of a Git directory is a logical fallacy and does not aid in your actual technical assessment.

All ports from 1 to 1000.

Why it fails: The output states that 998 ports are closed. Claiming all 1000 are open is a direct contradiction of the provided text. Accurate reading of scan results is non-negotiable, as misinterpreting data can lead to targeting services that are not actually present or available for interaction during the assessment.

Only port 22.

Why it fails: The output explicitly lists both port 22 and port 80 as open. Ignoring port 80 would be a major oversight, as web services are among the most common and critical entry points in an assessment, and failing to notice this would result in a significant gap in the reconnaissance process.

No ports are open.

Why it fails: The report clearly displays two open ports. Stating that no ports are open ignores the provided data entirely, which would be a critical failure in an assessment scenario. Every detail in a scan report is vital for building an accurate picture of the target environment's security posture.