Vulnerability Scanning and Penetration Testing practice questions

TCP ACK scan with -sA and -T1

Why it fails: A TCP ACK scan with -sA is used to map firewall rulesets, not to identify open services. It sends ACK packets and interprets RST responses to determine filtered versus unfiltered ports, but it cannot distinguish open from closed ports. Therefore, it would not fulfill the requirement of identifying exposed services on the medical devices.

TCP connect scan with -sT and -T0

Why it fails: A TCP connect scan with -sT completes the three-way handshake, which can cause some legacy devices to allocate resources and potentially hang. Even with -T0 (paranoid timing), the full connection attempt is more intrusive than a half-open scan. This technique is not ideal when the goal is to minimize impact on fragile production devices.

TCP SYN scan with -sS and default timing

Why it fails: A TCP SYN scan with -sS and default timing sends SYN packets and may elicit RST responses, but the default timing template can still generate bursts that overwhelm fragile devices. Additionally, the half-open scan still requires raw socket privileges and may not fully avoid disruption. It is not the safest choice for legacy medical devices that are sensitive to even moderate traffic spikes.

OWASP ZAP in safe mode with passive scanning only

Why it fails: OWASP ZAP's safe mode prevents actions that could be destructive, and passive scanning only observes traffic without sending attack payloads. However, passive scanning alone cannot actively test authentication or session management flaws such as weak password policies or session fixation, because it does not send crafted requests. It is too limited to meet the objective of identifying those specific vulnerabilities.

OWASP ZAP in protected mode with active scanning enabled

Why it fails: Protected mode in OWASP ZAP restricts scanning to URLs within a defined scope, which helps avoid testing unintended targets. However, enabling active scanning still sends attack payloads that can modify data or cause denial of service. The combination does not satisfy the non-destructive requirement, as active scanning remains inherently intrusive and may disrupt the application.

Burp Suite Professional with active scanning and default settings

Why it fails: Burp Suite's active scanner sends numerous attack payloads that can modify data, trigger account lockouts, or cause denial of service. Default settings may not respect application-specific safe testing constraints, and active scanning can inadvertently alter database records or session states. This approach violates the requirement to avoid data modification and service disruption, making it unsuitable for this scenario.

nmap -sL 192.168.1.0/24

Why it fails: The -sL option performs a list scan, which simply enumerates each IP address in the target range and optionally attempts reverse DNS resolution. It does not send any packets to the targets and therefore cannot determine which hosts are live. This is purely a listing operation and does not satisfy the requirement for host discovery.

nmap -sP 192.168.1.0/24

Why it fails: The -sP option was the older syntax for ping scanning but has been deprecated in modern Nmap versions. While it may still work in some legacy installations, it is not the current recommended flag and can produce warnings. The correct modern equivalent is -sn, which provides the same host discovery functionality without port scanning.

nmap -Pn 192.168.1.0/24

Why it fails: The -Pn option treats all hosts as online and skips host discovery entirely, proceeding directly to port scanning. This is the opposite of what the tester wants, as it would scan ports on every IP in the range even if they are not live. It is useful when ICMP is blocked, but not for a ping sweep.

exploit/multi/http/log4shell_header_injection

Why it fails: The exploit/multi/http/log4shell_header_injection module attempts to exploit the vulnerability by injecting a malicious JNDI payload into HTTP headers and then delivering a payload to the target. This goes beyond simple verification and could cause unintended execution or instability. It is not the appropriate choice when the goal is only to confirm the vulnerability's presence safely.

auxiliary/scanner/http/log4j_scanner

Why it fails: The auxiliary/scanner/http/log4j_scanner module scans for older Log4j vulnerabilities, such as CVE-2017-5645, but does not specifically target the Log4Shell JNDI injection flaw. Using it would likely miss CVE-2021-44228 because the detection logic differs. It is not the correct module for verifying Log4Shell.

exploit/multi/http/log4shell_http_headers

Why it fails: The exploit/multi/http/log4shell_http_headers module is an exploitation module that delivers a payload after triggering the vulnerability. It is not intended for safe verification and may cause code execution on the target. The analyst should avoid exploit modules when the objective is only to confirm the presence of the vulnerability without risking system compromise.

Maximum concurrently scanned hosts

Why it fails: This setting controls how many hosts are scanned in parallel, but it does not limit the number of checks per host or the overall intensity. Reducing it can help, but it does not directly address the load from multiple simultaneous checks on a single fragile system. The tester needs a more granular control over concurrent checks.

Scan speed

Why it fails: The scan speed setting in OpenVAS is not a standard configuration option in the same way as concurrent hosts or NVTs. While some interfaces offer a 'safe' or 'fast' mode, it is not the precise parameter for limiting concurrent checks per host. The tester should use the specific concurrency settings instead.

Network timeout

Why it fails: The network timeout setting determines how long the scanner waits for a response before considering a check failed. Adjusting it does not reduce the number of concurrent checks or hosts, so it does not mitigate the risk of overwhelming a fragile system. It is unrelated to the concurrency load.

nmap -sU

Why it fails: The -sU option performs a UDP scan, which sends UDP datagrams to target ports and interprets ICMP port-unreachable messages or lack of response. UDP scanning is unrelated to TCP connect scanning and does not satisfy the requirement for a TCP-based full connection scan. It also often requires elevated privileges for raw packet crafting.

nmap -sA

Why it fails: The -sA option executes a TCP ACK scan, which is used to map firewall rulesets and determine whether ports are filtered. It does not perform a full TCP connect scan and cannot determine if a port is open for application connections. ACK scanning requires raw packet privileges and is not a substitute for a connect scan.

nmap -sS

Why it fails: The -sS option initiates a TCP SYN scan, also called a half-open scan, which requires raw packet privileges and root or administrator access. It sends a SYN packet and analyzes the response without completing the handshake. Because the analyst may not have raw socket privileges, this scan type is not appropriate for the stated requirement.

Nessus Essentials

Why it fails: Nessus Essentials is a free but license-limited version of Tenable's commercial scanner, capped at 16 IP addresses. It cannot scan a 254-host subnet without purchasing a license, so it fails the stated requirement of scanning the entire subnet with no budget. It is also not open source.

Nmap with the NSE vuln category

Why it fails: Nmap's NSE vuln scripts can detect some vulnerabilities, but Nmap is primarily a port scanner and host discovery tool. It lacks the comprehensive vulnerability database, credential-based patch auditing, and reporting depth expected from a dedicated scanner, so it does not fully satisfy the requirement for a maintained vulnerability scanner.

Wireshark

Why it fails: Wireshark is a protocol analyzer used to capture and inspect network traffic. It does not perform vulnerability scanning, does not maintain a vulnerability feed, and cannot enumerate hosts or authenticate to targets. Using it as a scanner would miss the required checks entirely, so it is not a valid choice.

Perform a TCP SYN scan of the internal subnet from the compromised host

Why it fails: A SYN scan maps open ports and services on other hosts but does not reveal missing patches or local insecure configurations on the host where the shell resides. It also generates significant network traffic that could trigger detection. This technique addresses network reconnaissance, not the local vulnerability discovery the scenario requires.

Run a credentialed vulnerability scan from the scanner appliance using domain admin credentials

Why it fails: Credentialed scanning from an external appliance provides deep visibility, but it requires valid administrative credentials and network access to the scanner. In this scenario the tester already has a shell and wants local, post-exploitation discovery. Using domain admin credentials is also a privilege escalation risk that may exceed the authorized scope and does not leverage the existing foothold.

Capture traffic with tcpdump on the compromised host for several hours

Why it fails: Packet capture can reveal cleartext credentials or interesting protocols traversing the host, but it does not enumerate installed patches or configuration weaknesses. It also requires storage and time, and the results are unrelated to the specific goal of identifying missing updates and insecure local settings. This is a network analysis technique, not host vulnerability enumeration.

Kerberos ticket for domain authentication

Why it fails: Nessus does not directly accept Kerberos tickets as a credential type for authenticated scanning. While Windows authentication may involve Kerberos behind the scenes, the scanner expects username and password or hash credentials via SMB. Providing a Kerberos ticket alone is not a supported configuration method in Nessus for host-based checks.

Database credentials for SQL Server instances

Why it fails: Database credentials are used for specialized database vulnerability checks, such as auditing SQL Server configurations and permissions. They do not enable operating system-level authenticated scanning of Windows or Linux hosts. The question asks for credentials to perform local checks on servers, which requires SSH and SMB, not database logins.

SNMP community strings for network devices

Why it fails: SNMP community strings are used to query network devices such as routers, switches, and printers for configuration and interface information. While useful for scanning network infrastructure, SNMP credentials do not provide authenticated access to Windows or Linux servers for local vulnerability checks. They are not part of the credential set for server operating system scanning.

Enable password authentication on the target hosts

Why it fails: Enabling password authentication would allow the scanner to use passwords, but the scenario does not state that passwords are the intended method. Many hardened environments deliberately disable password authentication in favor of keys. Turning it on weakens security and may not address the actual problem if the scanner is configured for key-based access.

Change the SSH port on the targets to 2222

Why it fails: Changing the SSH port would only matter if the scanner were configured to use a non-default port and the targets were listening elsewhere. The scenario gives no indication of a port mismatch, and manual SSH logins work on the default port. Altering the port adds complexity without addressing the authentication failure.

Disable SELinux on the target hosts

Why it fails: SELinux enforces mandatory access controls and could block unusual login contexts, but it would typically also affect manual SSH sessions. Since manual logins succeed, SELinux is not the cause. Disabling it reduces the security posture and does not resolve the scanner-specific authentication problem.

Launch a denial-of-service test against the production application to check resilience

Why it fails: Denial-of-service testing against a production application can cause outages and is rarely authorized in a standard web assessment. It does not help find application vulnerabilities and introduces significant risk. Unless explicitly scoped, this action is inappropriate and could violate the rules of engagement, so it should not be included.

Use a network protocol analyzer to capture all traffic between the tester and the application

Why it fails: Capturing traffic can help confirm cleartext transmission or inspect tokens, but it is not a primary web application assessment technique and does not systematically find injection or logic flaws. It may also capture sensitive data that must be handled carefully. As a standalone inclusion it adds limited value compared with automated scanning and manual testing.

Run a full TCP port scan of the web server before testing the application

Why it fails: A port scan identifies open services on the host but does not assess the web application itself. While useful for infrastructure context, it does not contribute to finding application-layer vulnerabilities such as SQL injection or broken access control. The scenario focuses on web application assessment, so this is not a primary action.

Rescan the server with a different unauthenticated scanner to compare results

Why it fails: Using another unauthenticated scanner may provide a second opinion, but it still relies on remote inference and can produce the same false positive. It does not definitively confirm patch status. Authenticated scanning or manual host verification is needed to resolve the discrepancy accurately, so this step alone is insufficient.

Immediately take the server offline to prevent exploitation

Why it fails: Taking a production server offline based on an unconfirmed unauthenticated finding is premature and disruptive. The finding may be a false positive caused by banner grabbing or version inference. The analyst should first validate the result through authenticated scanning or manual verification before recommending outage, which could cause unnecessary business impact.

Accept the administrator's statement and close the finding as a false positive

Why it fails: Closing the finding solely because the administrator disagrees ignores the possibility that the server is genuinely vulnerable or that a patch did not apply correctly. Proper validation is required before dismissing a critical finding. Accepting the statement without evidence could leave a serious vulnerability unaddressed and undermine the integrity of the vulnerability management process.

Skip active scanning entirely and rely only on the client's existing asset inventory spreadsheet, then begin exploitation attempts against the listed hosts.

Why it fails: Relying solely on an inventory spreadsheet abandons the tester's responsibility to verify what is actually reachable and listening, so stale or incomplete records would skew the assessment. It also ignores the engagement objective of mapping live hosts, ports, and versions. Beginning exploitation against unverified inventory entries could target decommissioned or unauthorized systems, creating legal and safety problems.

Run a full Nmap scan with -sS and no timing adjustments across the entire /16, then immediately launch the exploitation framework against every discovered service.

Why it fails: A SYN scan across a /16 without timing controls can generate a large volume of packets and saturate network links or overwhelm legacy devices, which risks the denial-of-service condition the rules of engagement prohibit. Coupling discovery directly to exploitation also ignores the discipline of validating findings before attempting exploitation, and it can destabilize production services. This approach prioritizes speed over the client's stated safety constraints.

Use a single aggressive Nmap scan with -T5 and the default top-1000 ports, then treat every open port as an exploitable finding in the final report.

Why it fails: The -T5 timing template sends packets as fast as possible, which is exactly the behavior most likely to cause service degradation or packet loss on production systems, violating the engagement constraint. Treating every open port as an exploitable vulnerability also produces false positives and misrepresents risk in the report. Discovery data alone does not establish exploitability without validation.