Vulnerability Discovery and Analysis practice questions

Ping sweep (-sn)

Why it fails: Ping sweep (-sn) only probes for host availability using ICMP Echo Request (and ARP on local subnets) and never transmits TCP packets. This means it cannot enumerate open TCP ports, which is the primary goal of the scan described in the question. While it quickly identifies live systems, it fails to reveal which services are running, making it insufficient for a comprehensive host/service discovery mission. Additionally, ICMP probes may be filtered by firewalls, producing incomplete results without any port state information.

TCP connect scan (-sT)

Why it fails: TCP connect scan (-sT) uses the operating system's connect() system call to perform a complete three-way handshake with every port. Because the handshake is fully completed, the target service logs a full connection event, and the scanner's real IP is left in the logs, making it significantly more detectable than a SYN scan. It is also slower because the kernel handles each connection sequentially and must wait for the full handshake to conclude. While it works without raw packet privileges, its lack of stealth and higher overhead make it unsuitable for a penetration test looking to avoid observation and quickly map many ports.

UDP scan (-sU)

Why it fails: UDP scan (-sU) is designed specifically for User Datagram Protocol ports, not TCP ports, and operates by sending UDP datagrams and analyzing responses—most commonly receiving an ICMP Port Unreachable to mark a port closed. This technique is entirely inappropriate for the TCP-based SYN scan described in the question, as it does not perform any TCP handshake or partial handshake. UDP scanning is inherently slow and unreliable, relying on ICMP feedback that is often rate-limited or blocked, and it produces no information about TCP service states. Thus, using UDP scan would fail to answer whether TCP ports are open and would introduce considerable network noise, making it the wrong tool for this stealth-oriented task.

Repeater

Why it fails: Repeater allows a tester to manually craft a single HTTP request, send it, and inspect the raw response, optionally modifying and resending it. It lacks payload iteration and automated response analysis; it is designed for precise, one-off testing, not for automated fuzzing with multiple payloads. Because the pen tester's need is to automate fuzzing across many inputs, Repeater cannot fulfill that requirement.

Proxy

Why it fails: Burp Proxy operates as an intercepting forward proxy that sits between the browser and target, capturing and modifying individual requests in real time. It enables manual manipulation of parameters on the fly but does not generate a series of varying payloads; it is a passive and interactive tool for observing and tweaking traffic, not for systematic fuzzing. While useful for reconnaissance, it does not meet the requirement for automated fuzzing.

Sequencer

Why it fails: Sequencer is a Burp tool that collects a large sample of session tokens or other values and applies statistical tests to assess their entropy and predictability. It focuses on cryptographic and session randomness analysis, not on injecting payloads into request parameters. Using Sequencer here would not perform parameter fuzzing; it would analyze token quality, rendering it irrelevant to the stated task.

CrackMapExec

Why it fails: CrackMapExec is for Windows/AD, not cloud.

Prowler

Why it fails: Prowler is for CIS benchmarks, not exploitation.

ScoutSuite

Why it fails: ScoutSuite is multi-cloud, but for AWS specifically, Pacu is more focused on exploitation.

Brute-forcing SSH credentials

Why it fails: Wireshark is a passive sniffer/analyzer; it captures and decodes network packets but does not generate its own authentication attempts. Brute-forcing SSH requires an active client to repeatedly try credentials against the SSH service, which is outside Wireshark's functionality. It can only observe an ongoing brute-force attack, not perform one.

Performing active vulnerability scanning of hosts

Why it fails: Active vulnerability scanning requires sending crafted probes and observing responses to identify open ports and vulnerabilities, which means generating outbound network traffic. Wireshark is strictly passive: it only captures frames already on the wire, never transmitting packets itself. Thus, it cannot function as an active scanner; it could analyze the traffic generated by a scanner like Nmap, but it cannot run the scan.

Cracking WPA2 handshakes directly

Why it fails: Wireshark can capture the WPA2 4-way handshake if it is present in the traffic, but it does not include a cracking engine to derive the passphrase. Cracking requires offline tools like aircrack-ng or hashcat that perform dictionary/rule-based attacks against the handshake's hashed key material. Wireshark's role ends at saving the handshake to a file; it cannot verify or recover the password.

Nmap -sP

Why it fails: Nmap -sP (or -sn) performs host discovery only, sending ICMP echo requests, TCP SYN to port 443, and TCP ACK to port 80, then stops after determining whether a host is alive. It never initiates a TCP connect or SYN probe to enumerate open ports, so it yields only a list of live hosts, not the services or ports running on them. For a penetration test that requires identifying all live hosts and open ports, this is insufficient.

Nmap -sU

Why it fails: Nmap -sU invokes a UDP scan, which works by sending empty or protocol-specific UDP datagrams to target ports and interpreting ICMP Port Unreachable responses to mark closed ports; if no response is received, the port is classified as open|filtered. Because UDP is connectionless and many services don't reply, the scan is inherently slow, requiring timeouts and retransmissions, and it covers only UDP services, missing the TCP services that most critical applications (HTTP, SSH, RDP) rely on. It is not the ideal single-choice scan for a broad host/port enumeration during a penetration test.

Nmap -sT

Why it fails: Nmap -sT performs a full TCP connect scan, completing the three-way handshake by invoking the operating system's connect() call for every tested port. This not only takes significantly longer because each open port requires an extra RST to close the connection, but it also generates a completed connection record in the target's service logs and is easily spotted by network-based intrusion detection systems. While it can accurately identify open TCP ports, its speed and detectability make it suboptimal compared to stealthier techniques like a SYN scan.

Switch to John the Ripper with a brute-force attack

Why it fails: Brute-force is extremely slow for WPA2.

Use Wireshark to analyze the handshake for plaintext hints

Why it fails: Handshakes do not contain plaintext password hints.

Perform a deauthentication attack to force clients to reconnect and capture additional handshakes

Why it fails: More handshakes don't help if the password is not in the dictionary.

Path traversal

Why it fails: Path traversal is incorrect because it describes a file-system attack in which an attacker manipulates relative paths (e.g., ../../etc/passwd) to read or write files outside an intended directory. When decompiling with dnspy, a path traversal weakness would appear as unsanitized user input being concatenated into file paths or streams, not as deserialization calls. The decompiled code for insecure deserialization, by contrast, would show deserializer APIs like BinaryFormatter.Deserialize or JsonConvert.DeserializeObject being invoked on untrusted data, which is a completely different code pattern.

SQL injection

Why it fails: SQL injection is incorrect because that vulnerability occurs when untrusted input is incorporated into database queries, typically through string concatenation in command text, allowing an attacker to alter the query's logic or execute arbitrary SQL. In dnspy, SQL injection would appear as dynamic SQL strings and ExecuteNonQuery/ExecuteReader calls, not as deserialization of object streams. Insecure deserialization instead involves the reconstruction of .NET objects from binary or JSON data, where the risk comes from type-name resolution and gadget chains, not from malformed SQL syntax.

Hardcoded credentials

Why it fails: Hardcoded credentials are incorrect because that issue involves embedded secrets such as passwords, API keys, or connection strings in source code, which would be visible as plain string literals when decompiling. Insecure deserialization does not rely on static secrets; it arises when a deserializer (e.g., BinaryFormatter) trusts type information inside a serialized payload to instantiate arbitrary types. The dnspy result would show a Serialize/Deserialize call pattern and possibly gadget-inducing classes, not a hardcoded password field.

airmon-ng

Why it fails: Incorrect. Airmon-ng enables monitor mode but does not capture handshakes.

airodump-ng

Why it fails: Incorrect. Duplicate of option A; airodump-ng is already accounted for.

aircrack-ng

Why it fails: Incorrect. Aircrack-ng is used for cracking handshakes offline, not capturing them.

Change the root password to a known value

Why it fails: Changing the root password can provide access but is less stealthy and may alert the administrator; not typically listed as a primary persistence technique.

Disable SELinux

Why it fails: Disabling SELinux is a defense evasion technique, not a persistence technique.

Ruby

Why it fails: Ruby's Marshal module can deserialize objects with arbitrary behavior, and YAML.load with unsafe symbols can lead to object injection. However, Ruby deserialization flaws are far less prevalent in penetration tests because Ruby on Rails rarely exposes raw Marshal data to unauthenticated users, and the default safe-loading behavior has improved since Rails 5. This makes Ruby a less likely target than Java or .NET, which commonly accept and deserialize binary payloads over HTTP.

Python

Why it fails: Python's pickle module executes arbitrary code during unpickling, and vulnerable applications sometimes expose pickled objects; tools like pickle-pwn exist for exploitation. Yet in real-world pentests, Python deserialization attacks are rarely encountered compared to Java or .NET, because Python web frameworks (Django/Flask) default to JSON with session data signed rather than deserialized from the request body. The attack surface is more often internal (e.g., Redis or RabbitMQ payloads) rather than a straightforward web-facing RCE.

PHP

Why it fails: PHP's unserialize() triggers magic methods like __wakeup() and enables object injection, but exploitation typically requires a POP (Property-Oriented Programming) chain built from application-specific classes. Unlike Java's common out-of-the-box gadget libraries, PHP gadget chains often depend on the exact framework version, and modern PHP versions with lazy loading of classes mitigate some attacks. While serialization issues exist in PHP applications, classic pentesting courses emphasize Java and .NET because of their more widely documented, ready-to-use exploit chains.

CrackMapExec

Why it fails: CrackMapExec is a post-exploitation tool for Active Directory environments, not an AWS auditing tool.

ScoutSuite

Why it fails: ScoutSuite is a multi-cloud auditing tool that supports AWS but is not AWS-specific.

Pacu

Why it fails: Pacu is an AWS exploitation framework used for penetration testing and red teaming, not primarily for auditing.

GetNPUsers

Why it fails: Incorrect: GetNPUsers retrieves TGTs (ticket-granting tickets) for AS-REP roasting, not TGS tickets.

psexec

Why it fails: Incorrect: psexec is used for remote execution, not ticket extraction.

wmiexec

Why it fails: Incorrect: wmiexec is used for Windows Management Instrumentation execution, not ticket extraction.

secretsdump

Why it fails: Incorrect: secretsdump dumps credential hashes, not Kerberos tickets.

Burp Suite Repeater

Why it fails: Burp Suite Repeater is excellent for manually manipulating HTTP requests and observing server responses, but it does not execute JavaScript or render HTML. It can confirm that a payload is reflected in the response, but it cannot verify whether the JavaScript actually executes in a browser context under a Content Security Policy. To validate client-side execution, a browser-based tool or proxy that renders content is required.

Nikto

Why it fails: Nikto is a web server scanner that checks for known vulnerabilities, misconfigurations, and outdated software. It does not craft or execute XSS payloads, nor does it render JavaScript. Nikto might flag missing security headers or potential XSS issues, but it cannot verify whether a specific reflected payload executes in a browser under a given CSP. It is not suitable for this task.

OWASP ZAP with the AJAX Spider

Why it fails: OWASP ZAP's AJAX Spider is designed to crawl JavaScript-heavy applications and discover endpoints, not to validate XSS payload execution. While ZAP can detect reflected input, the AJAX Spider does not provide a controlled environment to confirm that a specific payload triggers JavaScript execution, especially with a CSP header present. It is a discovery tool, not an execution verification tool.

Enable 'Safe Checks' in the scan policy

Why it fails: Safe Checks in Nessus instructs the scanner to avoid plugins that could potentially crash the target service. While this reduces the risk of disruption, it does not verify the presence of vulnerabilities or reduce false positives. It is a safety setting, not a validation mechanism. In this scenario, the tester needs to confirm actual vulnerabilities, not just avoid risky checks.

Enable 'Scan for web vulnerabilities' to cross-check findings

Why it fails: Web vulnerability scanning focuses on HTTP/HTTPS services and would not help verify operating system or installed software vulnerabilities on a Windows host. It might even introduce additional false positives if web services are not present. The tester needs a method to confirm actual installed software, which credentialed scanning provides.

Adjust the 'Max checks per host' setting to increase scan thoroughness

Why it fails: Increasing the maximum number of checks per host can improve coverage but does not inherently validate findings. It may even increase false positives if plugins are more aggressive. The issue here is not scan depth but verification of results. This setting is about performance and coverage, not accuracy of individual findings.

Burp Suite

Why it fails: Burp Suite intercepts and manipulates HTTP/S traffic for web application testing, but it lacks a native repository of pre-written exploit modules and payloads for arbitrary service exploitation. The question requires a framework with a large, curated database of such modules, which is the defining feature of Metasploit. Burp Suite is tempting because its proxy and repeater tools are ideal for manual web vulnerability verification, making it the correct choice for a web application assessment rather than service-level exploitation.

Wireshark

Why it fails: Wireshark is a network protocol analyzer that captures and passively inspects packets traversing a network interface. It has no capability to craft or transmit custom exploit payloads, nor does it maintain a database of vulnerability exploits; at best it supports reconnaissance by revealing service banners, credentials, or protocol behavior, which is only a precursor to actual exploitation. Therefore, while Wireshark is valuable in the enumeration phase, it is not a tool for exploiting a vulnerable service.

Nmap

Why it fails: Nmap is a network scanning and enumeration tool used for host discovery, port scanning, and service/version detection. Although its Nmap Scripting Engine (NSE) includes some scripts that can probe for or even trigger certain vulnerabilities, Nmap lacks the broad, curated repository of full exploitation modules, payload generators, and post-exploitation tooling that define an exploitation framework. Its primary role in a penetration test is mapping the attack surface, not delivering a reliable exploit against a service.

psexec.py

Why it fails: PsExec is an Impacket remote administration tool that executes commands on a target system by creating a Windows service via the Service Control Manager (SVCCTL) over SMB. Its purpose is to provide an interactive shell or run arbitrary commands, not to read the SAM, NTDS.dit, or LSA secrets. Therefore, it would not be used to extract password hashes after gaining access to a domain controller.

GetUserSPNs.py

Why it fails: GetUserSPNs.py is an Impacket script designed for Kerberoasting: it queries Active Directory for user accounts with Service Principal Names (SPNs) and requests service tickets (TGS) from the Key Distribution Center. These tickets are formatted for offline password cracking, but they only expose hashes for specific service accounts, not all domain users or computer accounts. Thus, while useful for privilege escalation, it does not dump the full set of hashes that reside in NTDS.dit on a domain controller.

wmiexec.py

Why it fails: wmiexec.py uses Windows Management Instrumentation (WMI) to execute commands remotely, creating a semi-interactive shell via classes like Win32_Process and requiring an administrative account with WMI access. It operates by spawning new processes on the target but never reads the registry hive files or database files where password hashes are stored, so it cannot be used to extract credentials. It is an alternative to PsExec for remote code execution, not a hash-dumping utility.

airmon-ng

Why it fails: airmon-ng only enables monitor mode on the wireless interface; it never processes the captured handshake or tests passphrases. It is tempting because it is the first Aircrack-ng tool used in a WPA2 assessment, and it would be correct when preparing an adapter to capture frames before airodump-ng runs.

airodump-ng

Why it fails: airodump-ng captures frames and writes the WPA2 handshake to a .cap file, but performs no offline dictionary or brute-force attack against the PMK. It is tempting as the tool that obtains the handshake, and would be correct when scanning channels and capturing the four-way exchange.

aireplay-ng

Why it fails: aireplay-ng injects frames to force clients to reconnect, generating a handshake for capture, but it does not derive the pre-shared key. It is tempting because it accelerates handshake collection, and would be correct when deauthenticating a station so airodump-ng can record the exchange.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting (XSS) fundamentally targets the client-side execution context, not the database. An attacker injects malicious JavaScript or HTML into the application's output, which is then rendered by a victim's browser. Unlike SQL injection, the injected payload does not alter any server-side SQL statement; instead, it manipulates how the page is interpreted client-side. Thus, the presence of unsanitized input alone does not indicate XSS unless it reaches an output sink such as echo or innerHTML.

Path traversal

Why it fails: Path traversal, also known as directory traversal, exploits a vulnerability in file path handling rather than database queries. An attacker injects sequences like ../ to escape the intended directory and read arbitrary files from the server's filesystem. This attack focuses on server-side file operations such as file_get_contents(), include, or fopen(), where user input is used to construct a filesystem path insecurely. Since the input is processed by the filesystem layer and not the SQL query parser, it cannot be classified as SQL injection.

Command injection

Why it fails: Command injection occurs when user-controlled input is passed unfiltered to an operating system command executed via functions like exec(), system(), or shell_exec(). The attacker appends shell metacharacters such as ;, |, or && to execute arbitrary commands on the host. This vulnerability exploits the shell's command parser, not the SQL query interpreter, so the injected content is processed by the operating system rather than a database. Therefore, it is a completely different attack class from SQL injection, which targets the SQL language syntax.

Aircrack-ng

Why it fails: Aircrack-ng is a specialized suite for wireless network security testing, designed to capture packets and crack WEP and WPA-PSK keys via offline analysis. It performs no interactive authentication attempts against a live SSH service and does not support SSH as a target protocol, so it cannot brute-force credentials over the network.

Hashcat

Why it fails: Hashcat is a high-speed offline password recovery tool that operates on pre-captured hash values (e.g., /etc/shadow SHA-512, NTLM, bcrypt). It requires a hash file as input and never contacts a target service, so it cannot perform online SSH brute-force attacks where each guess is sent to the sshd daemon.

John the Ripper

Why it fails: John the Ripper is a versatile offline password cracker that works by comparing candidate hashes against a pre-computed or incremental set of password hashes. It is not designed to initiate network connections or send authentication requests to a remote SSH service, so it cannot be used for active online brute-force attacks directly.

requests

Why it fails: The `requests` library is strictly an HTTP client built atop urllib3. It operates entirely at the application layer (Layer 7), managing HTTP/1.1 semantics, session cookies, and TLS, but it exposes no control over IP or TCP header fields such as sequence numbers, window sizes, or TCP flags. Because it cannot open raw sockets or inject arbitrary packets, it is completely unsuitable for crafting low-level network probes. It would be the correct choice only for web application interaction, not packet crafting.

socket

Why it fails: The `socket` module provides the foundational interface for network communication in Python, allowing for operations like establishing connections and sending/receiving data. It is tempting because it enables low-level network interaction, including the creation of raw sockets. However, for crafting custom TCP packets with specific flags and manipulating individual header fields, `socket` requires the manual, byte-by-byte construction of entire IP and TCP headers, including checksum calculation. This makes it cumbersome for the precise packet crafting required, where a library that abstracts header creation would be more effective. It would be the correct choice for standard TCP/UDP client/server implementations or basic network I/O.

impacket

Why it fails: Impacket is a collection of Python classes focused on implementing and interacting with Windows network protocols, especially SMB, MSRPC, Kerberos, and NetBIOS. Although it contains some low-level packet-handling utilities for its own protocol implementations, its design goal is not general-purpose packet crafting. Using Impacket to forge arbitrary TCP packets would require working around its protocol-specific abstractions and would lack the intuitive, protocol-agnostic API that Scapy offers. Thus it is not the correct choice for crafting custom TCP packets in a standalone Python script.