Vulnerability Scanning practice questions

Failing to update the scanner's plugin database prior to running the scan.

Why it fails: Failing to update plugins typically results in false negatives, where the scanner misses actual vulnerabilities, rather than false positives. If the database is outdated, the scanner lacks the logic to detect new flaws, leaving the target's risk profile unassessed rather than inaccurately reported.

Scanning the target from a different subnet than the target server.

Why it fails: Scanning from a different subnet might introduce latency or firewall issues, but it does not inherently cause false positives. Network positioning might cause timeouts or missed services, but the accuracy of the vulnerability signatures themselves is independent of the network topology between the scanner and target.

The geographic location of the penetration testing team's main office.

Why it fails: The location of the security team is irrelevant to the technical impact of a scan on a production server. Performance and availability are dictated by the target's workload and network capacity, not by where the analysts are physically sitting when they initiate the scan.

The requirement to have all employees logged into the network at once.

Why it fails: User activity has no direct impact on the technical execution of a vulnerability scan. While high network traffic from users might impact bandwidth, scanning does not require user presence. This is an operational, not a technical, consideration for setting a scan window.

The version of the operating system running on the scanner itself.

Why it fails: The scanner's own OS version does not affect the impact on the production target. As long as the scanner meets the software requirements, its internal configuration is secondary to the target's ability to handle the scanning traffic during the scheduled maintenance window.

The scanner is using the wrong network interface for the subnet.

Why it fails: If the scanner were using the wrong interface, it likely would not reach any hosts, not just a single host. A failure to detect one specific host while others are reachable points to a policy or network-level blocking mechanism targeting that specific IP address.

The scanner's license limit for IP addresses has been exceeded.

Why it fails: License limits usually result in the scanner stopping entirely or throwing an error message in the logs, rather than inaccurately reporting a single host as down. This is an administrative issue that would affect the entire scanning scope, not just one specific target machine.

The target host has an empty port list defined in the scan policy.

Why it fails: An empty port list would result in the scanner reporting the host as 'up' but finding zero open ports. It would not cause the scanner to fail the initial host discovery phase. If the host is reported as down, the failure occurred before port scanning began.

Decrease the timeout_ms to 100.

Why it fails: Reducing the timeout to 100ms is too aggressive for most network environments. It would cause a massive spike in packet retransmissions and dropped connections, as the scanner would assume a host or port is unresponsive before the packets actually have a chance to complete the round-trip.

Decrease the threads_per_host to 1.

Why it fails: Reducing threads per host would force the scanner to handle each target system serially. This would drastically increase the scan duration, as the scanner would no longer be able to effectively probe multiple ports or services simultaneously on a single host, resulting in much slower performance.

Change the depth to 'shallow'.

Why it fails: Changing the depth to shallow would reduce the number of checks performed. While this makes the scan faster, it results in a less comprehensive assessment, potentially missing critical vulnerabilities. Efficiency should be achieved through concurrency optimization rather than sacrificing the breadth of the security assessment.

The ability to bypass all existing network firewalls.

Why it fails: Authentication does not grant the scanner the ability to bypass network firewalls. The scanner still needs to establish a network connection to the target; authentication only changes the method of interaction once the connection is established, not the network-level path to the host.

Complete immunity from being detected by IDS systems.

Why it fails: While authenticated scans are quieter, they are not invisible. Security monitoring tools can still detect the authentication traffic and the subsequent API queries. No scanning technique provides total immunity from detection; the goal is to balance thoroughness with the potential for triggering alerts.

The scanner is using the wrong version of the SSH protocol.

Why it fails: While SSH version mismatches can occur, SSH version 2 is universally standard. If the scanner and target were using fundamentally incompatible protocols, no connection would be established at all. SSH authentication failures are usually due to credential or configuration policy issues rather than protocol versioning.

The SSH service port has been changed from 22 to a random port.

Why it fails: While changing the SSH port is a common hardening step, the scanner can easily be configured to scan non-standard ports. An authentication failure is different from a connection failure; if the port were the issue, the scanner would report that it could not connect at all.

The SSH service requires MFA for all login attempts.

Why it fails: Multi-Factor Authentication (MFA) is rarely applied to automated scanning accounts because it breaks the unattended nature of the process. If MFA were required, it would be an administrative misconfiguration rather than a common technical reason for an automated scan failure in a typical environment.

To increase the speed of the scan by avoiding network latency.

Why it fails: While reducing latency is a minor benefit, it is not the primary reason for internal placement. The main purpose is to ensure the scan is not subject to the filtering or rate-limiting rules of firewalls that would otherwise distort the vulnerability assessment results.

To reduce the amount of log data generated on the network switches.

Why it fails: Placing the scanner in a segment does not decrease the amount of traffic generated; it actually concentrates the traffic on that specific segment. The goal is to obtain accurate results by bypassing firewall filtering, not to optimize for network switch log volume.

To ensure that the scanner is visible to all users on the network.

Why it fails: The scanner should not be visible to general users; in fact, it should be kept as inconspicuous as possible to avoid attracting unwanted attention. Visibility to users is a security risk, as it might lead to unauthorized interaction or tampering with the scanning infrastructure.

The scan policy is configured to 'Perform thorough tests (may disrupt your network)' disabled.

Why it fails: This setting, when disabled, reduces scan intensity and may skip some intrusive checks, but it would not eliminate nearly all findings. Patch auditing relies on registry and file enumeration, which still occurs under normal settings. A server missing many patches would still show dozens of findings, so this alone cannot account for the sparse results.

The scan policy has 'Safe Checks' enabled.

Why it fails: Safe Checks prevents plugins that may crash services or hosts from running, but it does not suppress patch-level detection. Most missing-patch plugins are considered safe and would still execute. Enabling Safe Checks typically reduces denial-of-service risk, not the overall number of findings, so it would not explain a near-empty report on an unpatched server.

The scan policy has 'Only use credentials to perform local checks' disabled.

Why it fails: This option, sometimes called 'local checks only', when disabled allows both local and remote checks. Disabling it would not suppress results; it would broaden them. Enabling it restricts to local checks, which is the opposite of what would cause a near-empty report. Therefore this setting is not the likely cause of the limited findings.

Configure the scanner to use the Domain Administrator account for full registry access.

Why it fails: Domain Administrator accounts provide excessive privileges that violate the principle of least privilege. If the scanner host is compromised, an attacker would gain immediate domain-wide control, significantly increasing the risk profile of the vulnerability scanning infrastructure itself during routine assessment tasks.

Use a local account with no password to allow quick automated authentication.

Why it fails: Local accounts without passwords are inherently insecure and are frequently disabled by default security policies. Attempting to use null sessions or blank passwords will likely fail on modern Windows systems, preventing the scanner from accessing necessary APIs to perform a comprehensive vulnerability assessment.

Store credentials in plain text in the scanner configuration file for easier automation.

Why it fails: Plain text credential storage is a severe security vulnerability that allows anyone with file system access to extract valid administrative passwords. Modern scanners provide encrypted vaults or secure credential managers to protect sensitive data from unauthorized exposure on the scanning host.

Increase the timing template to -T5 to make the scan faster.

Why it fails: Increasing the timing template to -T5 focuses on speed and often causes missed packets or dropped connections due to congestion. It does not improve the accuracy of script-based directory enumeration and could lead to server-side rate limiting that blocks the scanner entirely.

Add the --script-args='http-enum.basepath=/admin' argument to the command.

Why it fails: Specifying a basepath forces the script to search only from that specific directory, which likely misses all other common locations. This narrows the scope incorrectly, as the goal is to discover unknown directories rather than verify a known one through brute-force enumeration.

Change the scan to -sS to perform a stealthy SYN scan instead of service detection.

Why it fails: An -sS scan performs port discovery but does not interact with the web server application layer. Since the goal is to identify directories, which are an application-level concern, switching to a transport-layer SYN scan will provide less information about the web application structure.

To increase the intensity of the scan to ensure all ports are covered.

Why it fails: Delta scans are designed for efficiency, not increased intensity. Increasing scan intensity usually involves full port scans or aggressive fuzzing, which are the opposite of the time-saving purpose of a differential scan. Their goal is to identify changes, not to exhaustively re-test the entire infrastructure.

To bypass signature-based detection systems by using randomized payloads.

Why it fails: Bypassing detection systems is an evasion technique rather than a vulnerability management process. Delta scans focus on the state of the target system's vulnerabilities, not on obfuscating the scanner's traffic to avoid being detected by network security monitoring tools or intrusion detection systems.

To perform an exhaustive search for zero-day vulnerabilities on all assets.

Why it fails: Zero-day detection is not the primary function of delta scans, as zero-day vulnerabilities are inherently unknown to the scanner's signature database. Delta scans simply identify status changes for known vulnerabilities, whereas zero-day detection requires behavioral analysis or advanced fuzzing techniques that go beyond delta comparisons.

Host Discovery

Why it fails: Host discovery is the initial phase where the scanner identifies live systems on the network. No vulnerability checks or CVE matching occur at this stage; it is purely about mapping the IP space to determine which targets are available for further testing.

Service Identification

Why it fails: Service identification determines what applications are running on open ports, such as identifying a version of Apache or OpenSSH. This provides the necessary input for the vulnerability detection phase, but the actual comparison against CVE databases happens after the software versions have been gathered.

Remediation Verification

Why it fails: Remediation verification occurs after the vulnerability has been identified and supposedly patched by the system administrator. The goal is to confirm that the vulnerability is no longer present, which is a separate post-scan process from the initial identification phase.

Wait until the full scan report is generated at the end of the month.

Why it fails: Waiting for a monthly report is unacceptable for critical, actively exploited vulnerabilities. The delay would leave the organization exposed to potential attack. Critical findings must be communicated through an out-of-band, expedited process to ensure the security team can prioritize immediate patching or mitigation steps.

Re-run the scan to verify the vulnerability is not a false positive.

Why it fails: While verification is important, the potential for an active exploit outweighs the need for secondary confirmation. In this scenario, time is critical. The tester should communicate the risk while performing additional verification, rather than pausing the remediation process solely to re-verify the finding.

Isolate the server from the network immediately without notifying anyone.

Why it fails: While isolation is an effective security measure, taking down production systems without notifying owners can cause significant operational disruption and service outages. Remediation requires coordination with system owners to balance security needs with business availability, ensuring the response is both effective and operationally acceptable.

The organization's public-facing bug bounty program policy.

Why it fails: Bug bounty policies are designed for external researchers and usually lack the specific internal scoping, sensitivity thresholds, and legal protections required for a professional penetration test. They are not a substitute for a formal, project-specific Rules of Engagement document for a internal security assessment.

The vendor's hardware specification sheets.

Why it fails: Hardware specifications provide technical details about system components but do not contain information about the legal or operational rules for a security assessment. Consulting these would be helpful for understanding the hardware, but it would not provide any guidance on the permitted testing scope.

The latest version of the Common Vulnerabilities and Exposures (CVE) list.

Why it fails: The CVE list provides definitions of known vulnerabilities but contains no operational or legal guidance for conducting a penetration test. It is a technical resource used for identifying vulnerabilities, not for governing the conduct or scope of a professional security assessment.

Configure the scanner to perform a SYN stealth scan on all 65,535 TCP ports for every host before authenticating.

Why it fails: A full-port SYN scan is unauthenticated and generates large amounts of traffic, increasing scan duration. It does not leverage credentials to inspect patch state or configuration, so it fails to meet the goal of reducing load while detecting missing patches. It may also trigger IDS/IPS alerts unnecessarily.

Limit the scan to a predefined list of common ports and disable all plugin families except 'Denial of Service'.

Why it fails: Restricting ports reduces coverage and disabling all but the DoS family removes patch and configuration checks entirely. This would miss missing patches and misconfigurations, directly contradicting the objective. It also unnecessarily runs intrusive DoS tests that can harm systems without providing useful vulnerability data.

Set the scanner to use a very aggressive timing template to maximize parallelism across all hosts.

Why it fails: Aggressive timing increases packet volume and concurrency, which can overwhelm network devices, cause packet loss, and actually lengthen scan times due to retransmissions. It does not improve patch or configuration detection and risks disrupting production services, making it a poor choice for reducing load and duration.

Immediately report the SQL injection as a confirmed critical finding based on the scanner's time-based evidence.

Why it fails: Reporting without independent validation risks a false positive. Time-based blind SQL injection can be mimicked by network latency, server load, or application timeouts. A single five-second delay is not conclusive; the tester must reproduce it under controlled conditions to confirm the vulnerability before reporting it as critical.

Re-run the scanner with the same payload multiple times and compare the response times to confirm the delay is consistent.

Why it fails: Repeating the scanner's automated payload does not eliminate other causes of delay, such as server-side rate limiting or transient network congestion. Manual validation with controlled payloads and baseline comparisons is needed. Simply re-running the scanner may reproduce the same ambiguous timing without proving the injection point.

Submit the login form with a benign username and password to check if the application returns a different error, then conclude the vulnerability is a false positive.

Why it fails: A benign submission only establishes a baseline and does not test the injection point. The absence of a database error does not disprove time-based blind SQL injection, which by design does not return error details. Concluding false positive based on a benign request ignores the need for specific conditional payload testing.

Reduce parallel checks per host

Why it fails: This option is similar to limiting concurrent checks per host, which focuses on a single host's load. It does not govern how many hosts are scanned in parallel. While it could reduce per-host stress, it wouldn't stop several printers from being scanned simultaneously, so it doesn't address the core issue.

Scan window size

Why it fails: The scan window size affects TCP window scaling and can influence throughput, but it does not control the number of hosts scanned concurrently. Adjusting it might impact performance but won't prevent multiple printers from being hit at once, making it ineffective for the described goal.

Max concurrent checks per host

Why it fails: This setting limits the number of checks performed in parallel on a single host, not the number of hosts scanned simultaneously. While it can reduce load on a specific device, it does not directly control how many hosts are targeted at once, so it would not prevent multiple printers from being scanned concurrently.

Disable all plugin families except those that perform denial-of-service testing to quickly identify weak points.

Why it fails: Denial-of-service plugins are specifically designed to stress or crash services, which is the opposite of avoiding disruptions. Running only these plugins would likely cause outages and provide an incomplete vulnerability picture. They should be avoided entirely on production networks unless explicitly authorized in a controlled test window.

Set the scanner to use a random port order and maximum timing template to evade detection.

Why it fails: Maximum timing template increases scan speed and packet volume, which can overwhelm network devices and trigger timeouts. Random port order may help evade simple IDS but does not reduce load. This setting prioritizes stealth over safety and is inappropriate for a sensitive production network where avoiding disruption is the primary concern.

Increase the maximum number of concurrent hosts and checks per host to finish faster.

Why it fails: Increasing concurrency raises network and target load, which can cause packet loss, service timeouts, or even crashes on fragile systems. This directly opposes the goal of avoiding disruptions. Higher concurrency is suitable for non-production or robust environments, but not for sensitive production networks where stability is paramount.

Check the CVE details in the National Vulnerability Database (NVD).

Why it fails: Consulting the NVD provides information about the vulnerability, such as affected versions and severity, but it does not confirm that the specific target is vulnerable. The scanner may have misidentified the version or the vulnerability might be mitigated. Therefore, this action alone does not verify exploitability.

Review the scanner's plugin documentation to understand the detection logic.

Why it fails: Understanding how the scanner detects the vulnerability can help assess false positives, but it does not prove the vulnerability exists on the target. The detection logic might be based on version banners that are spoofed or inaccurate. Manual verification is still required to confirm exploitability.

Re-run the scan with a different scanner to confirm the finding.

Why it fails: Using another scanner might provide corroboration, but it does not directly verify exploitability. Different scanners may have different detection methods, and a match could still be a false positive. This approach also consumes additional time and resources without conclusively proving the vulnerability can be exploited.

The age of the vulnerability in the CVE database

Why it fails: The age of a CVE does not determine its current criticality. Older vulnerabilities may still be actively exploited if patches are not applied. Prioritization should be based on current exploitability and impact, not the date of disclosure.

The number of other vulnerabilities on the same host

Why it fails: The quantity of vulnerabilities on a host does not directly indicate the criticality of a specific vulnerability. A single critical flaw is more urgent than many low-severity issues. Focusing on count can lead to misprioritization and neglect of the most dangerous findings.

The scanner's confidence level in the finding

Why it fails: While confidence level can affect whether a finding is a false positive, it is not a primary factor for criticality. Once a vulnerability is confirmed, criticality is based on severity and impact. Confidence helps validate findings but does not change the inherent risk.