Software Troubleshooting practice questions

OpenVAS

Why it fails: OpenVAS is an open-source vulnerability manager that executes network-level scans to identify known CVEs and security weaknesses across distributed endpoints. It relies on the Greenbone Community Feed to detect active exploits and misconfigurations, making it a general-purpose vulnerability scanner rather than a specialized tool designed for local system hardening and compliance verification.

Nessus

Why it fails: Nessus is a commercial, network-based vulnerability scanner developed by Tenable that primarily identifies missing patches, open ports, and software exploits. While it supports compliance auditing through custom policy templates, its core architecture is optimized for remote vulnerability assessment rather than dedicated, host-level configuration compliance auditing.

Qualys

Why it fails: Qualys is an enterprise-level, cloud-native vulnerability management platform that provides broad visibility into global IT assets. While it offers policy compliance modules as part of its larger suite, its primary design centers on continuous vulnerability lifecycle management, asset discovery, and threat prioritization across hybrid cloud environments.

Check the Run registry keys (HKLM\Software\Microsoft\Windows\CurrentVersion\Run)

Why it fails: Checking the Run registry keys (HKLM\Software\Microsoft\Windows\CurrentVersion\Run) is ineffective for detecting scheduled tasks. These registry keys are designed to launch programs automatically when a user logs on or the system starts, not for time-based or event-triggered executions managed by the Task Scheduler service. Scheduled tasks utilize a distinct persistence mechanism, storing their configurations in XML files and relying on the Task Scheduler service for execution, making Run keys an irrelevant location for this type of artifact.

Examine the System event log for driver loading events

Why it fails: Examining the System event log for driver loading events is not relevant for identifying scheduled task creation. The System log primarily records events related to system components, hardware, device drivers, and operating system services, such as driver installations or failures. Scheduled tasks, however, operate at a higher abstraction layer, managed by the Task Scheduler service, and do not directly involve driver-level operations or log their creation within the System event log.

Analyze the application event log for error messages

Why it fails: Analyzing the Application event log for error messages is unlikely to reveal the creation of a scheduled task. The Application log is dedicated to events generated by applications or programs, including errors, warnings, and informational messages specific to their operation. While a malicious application might log its own activities, the *creation* of a scheduled task is a system-level action that is specifically logged in the Security event log, not typically within the Application log.

Install a network-based intrusion detection system to monitor the server.

Why it fails: Installing a network-based intrusion detection system (NIDS) at this stage is a proactive security enhancement, but it does not address the immediate need to investigate the already reported suspicious connections. An IDS would primarily monitor future traffic for known attack signatures or anomalies, offering little insight into the historical or current nature of the specific suspicious communications that have already occurred or are ongoing. This action is a long-term control, not an immediate incident response investigation technique.

Isolate the EMR server from the network and run a full forensic analysis.

Why it fails: Isolating the EMR server from the network and immediately initiating a full forensic analysis is a drastic containment and recovery step that is premature without further investigation. While isolation is crucial for containing confirmed threats, doing so without understanding the nature of the suspicious traffic could unnecessarily disrupt critical hospital operations if the connections are legitimate. A full forensic analysis is resource-intensive and typically follows initial identification and containment, not precedes it.

Block all outbound traffic from the EMR server to the internet immediately.

Why it fails: Blocking all outbound traffic from the EMR server to the internet immediately is an overly aggressive containment measure that could severely disrupt legitimate hospital operations. EMR systems often require outbound connectivity for updates, integrations with external services, or even legitimate vendor support. Implementing such a broad block without first understanding the nature of the suspicious traffic risks causing significant availability issues and impacting patient care unnecessarily.

Disable the user account.

Why it fails: Disabling the user account primarily restricts future authentication attempts by that specific user. However, it does not terminate active processes or established network connections that the malware may have already initiated under that user's context or, more commonly, under a system account with elevated privileges. The malicious payload would continue to execute and potentially communicate, as its runtime environment is unaffected by the account's disabled status.

Kill the svchost.exe process.

Why it fails: Killing a generic svchost.exe process is a highly risky and often ineffective action. svchost.exe is a legitimate Windows process that hosts numerous system services, and indiscriminately terminating it can lead to system instability, crashes, or critical service outages. Furthermore, sophisticated malware often injects into multiple legitimate processes or establishes persistence mechanisms that would remain active even if one specific svchost instance were terminated.

Block the remote server IP at the firewall.

Why it fails: Blocking the remote server IP at the firewall is a beneficial defensive measure, but it is insufficient as an initial containment strategy for an already compromised workstation. While it prevents future outbound communication to that specific Command and Control (C2) server, it does not address the active malicious processes running locally on the infected machine. The malware could still operate internally, attempt lateral movement, or utilize alternative C2 channels or domain names not covered by the IP block.

Disable verbose output to reduce clutter.

Why it fails: Disabling verbose output merely changes the level of detail presented in the scan report, making it potentially easier to read by suppressing less critical or redundant information. However, it does not alter the underlying scanning methodology, the depth of the probes performed against target systems, or the logic used for vulnerability identification. Therefore, reducing output clutter has no impact on the accuracy of vulnerability detection or the reduction of false positives or negatives.

Increase scan frequency to monthly.

Why it fails: Increasing scan frequency to monthly improves the timeliness of vulnerability detection, allowing organizations to identify newly emerging threats or configuration drift more quickly. However, the frequency of scans does not inherently improve the accuracy of the individual findings themselves. If the scanning methodology lacks depth, such as being uncredentialed, simply running it more often will still yield the same quality of potentially inaccurate or incomplete results.

Use a different vulnerability scanner.

Why it fails: While different vulnerability scanners possess unique signature databases and detection capabilities, simply switching to an alternative tool does not guarantee improved accuracy without addressing fundamental scanning methodologies. If the new scanner is still configured to perform uncredentialed scans, it will face the same limitations in assessing internal system states and confirming patch levels. Therefore, a different tool may still produce a similar rate of false positives or miss critical vulnerabilities without authenticated access.

Wait for the vendor to release a patch before taking any action

Why it fails: Waiting for a vendor patch leaves the critical vulnerability unaddressed, significantly increasing the organization's exposure to potential exploitation. This passive approach prolongs the risk window, allowing attackers more time to discover and leverage the flaw. Proactive measures, such as implementing compensating controls, are essential to mitigate immediate threats and reduce the attack surface while awaiting a permanent fix.

Remove the affected component from all systems immediately

Why it fails: Immediately removing a critical component from all systems is often an impractical and highly disruptive measure that can severely impact business operations and service availability. While it eliminates the vulnerability, the operational cost and potential for service outages typically outweigh the benefits as a primary response. Feasible compensating controls are generally preferred to maintain functionality while reducing risk.

Increase monitoring of the affected systems but take no other action

Why it fails: Merely increasing monitoring of affected systems without implementing active mitigation steps is insufficient for addressing a critical vulnerability. Enhanced monitoring can help detect exploitation attempts, but it does not prevent them or reduce the underlying risk posed by the unpatched flaw. Active measures, such as applying a workaround or isolating the system, are necessary to actually reduce the attack surface and potential impact.

Only scanning ICMP echo replies

Why it fails: ICMP echo replies only confirm that a host is reachable on the network and responding to ping requests; this protocol carries no application or package-layer data whatsoever, so it can never be used to enumerate installed software versions or identify missing patches, regardless of how the scan is otherwise configured.

Changing server hostnames randomly

Why it fails: Randomizing server hostnames changes only a cosmetic network identifier used for DNS and inventory labeling; it does not alter what packages are installed, what permissions the scanner account holds, or what protocol the scan uses, so it has no effect on the accuracy of vulnerability findings.

Using a higher scan intensity

Why it fails: Using a higher scan intensity increases the rate of concurrent connections, timeouts, and service probing aggressiveness. This may cause the scanner to receive incomplete or ambiguous responses from overloaded targets, leading it to misidentify services and flag false vulnerabilities. Intensity affects performance and network tolerance, not the precision of the detection logic, so it cannot reduce false positives. In fact, aggressive scanning can introduce more extraneous findings by interpreting transient network errors as vulnerabilities.

Scanning from multiple IP addresses

Why it fails: Scanning from multiple IP addresses distributes the scan load and can help bypass rate limits or network path restrictions, but it does not alter the scanner's detection logic or how it interprets responses. False positives arise from plug-in logic and target response characteristics, which are independent of the source address. Using multiple sources may even introduce variability, because different paths or network segments can yield inconsistent responses, worsening false positives. It has no effect on reducing the number of false findings.

Scanning only during business hours

Why it fails: Scanning only during business hours changes when the scan runs but has no effect on the scanner's detection mechanisms. False positives are produced by plug-ins misinterpreting target responses or lacking context, which is unrelated to the time of day. In fact, business hours might see live user activity or dynamic services that could complicate responses, potentially increasing noise. The accuracy of a scan depends on its configuration, not its schedule, so this does not reduce false positives.

The file reading its own content.

Why it fails: An executable reading its own content is commonly seen in legitimate software for integrity checks, resource extraction, or digital signature verification. This action does not modify the system, create persistence, or communicate externally, so it is not inherently malicious. In a sandbox, it may be an anti-tampering technique, but without other suspicious behaviors, it is insufficient to classify the sample as malware.

Opening a text file that was already present.

Why it fails: Opening a text file that already exists on the system is typical benign behavior, as many programs read configuration files, documentation, or data samples during normal operation. This action involves no writes to autostart locations, no modification of system settings, and no external communication. Without additional malicious context, such a file read is considered neutral and does not indicate compromise.

Eliminate the need for patch management

Why it fails: Credentialed scanning identifies which patches are missing with far greater accuracy, but it is still a detection mechanism, not a remediation mechanism; patch management, the actual process of deploying fixes, remains a separate and still-necessary operational function afterward.

Reduce network bandwidth usage

Why it fails: Authenticating into each host to enumerate installed packages, registry keys, and configuration files typically generates more queries and data transfer than an unauthenticated network probe, so credentialed scanning tends to increase, not reduce, bandwidth and system resource usage during the scan.

Avoid detection by the target system

Why it fails: Logging into a target with valid credentials is inherently visible to the host's authentication logs and endpoint monitoring, the opposite of stealth; credentialed scans are the least evasive scan type precisely because they authenticate openly rather than attempting to avoid detection.

Manual badge checks at the office door

Why it fails: Manual badge checks are a physical security control designed to prevent unauthorized personnel from entering a physical facility. They operate entirely outside the CI/CD pipeline and have no mechanism to inspect, analyze, or restrict vulnerable software dependencies or code libraries.

DNS MX record rotation

Why it fails: DNS Mail Exchanger (MX) records specify the mail servers responsible for accepting email messages on behalf of a domain. Rotating or modifying these records is an administrative task for email routing and has no bearing on application security, dependency management, or pipeline vulnerability scanning.

Non-credentialed scan

Why it fails: A non-credentialed scan probes target systems from the network perspective without administrative privileges. While useful for mapping the external attack surface and identifying exposed services, it cannot query the local registry, package manager, or file system to verify specific patch levels or internal configuration settings. This limitation leads to a high rate of false negatives regarding local vulnerabilities.

External scan

Why it fails: An external scan originates from outside the organization's security perimeter, simulating what an internet-based attacker can see. It is primarily designed to evaluate firewall rules, perimeter defenses, and publicly accessible services rather than auditing internal host configurations. It lacks the network positioning and access rights required to perform a comprehensive patch and vulnerability assessment on internal assets.

Passive scan

Why it fails: A passive scan monitors network traffic via a SPAN port or network TAP to identify active hosts, protocols, and potential vulnerabilities based on observed packet headers and payloads. Because it does not actively query or interact with the target hosts, it cannot inspect local file systems, registry keys, or software version metadata. This makes it incapable of reliably verifying patch levels or deep system configurations.

Change the rule to trigger only on network connections from rundll32.exe

Why it fails: Restricting the rule to trigger solely on network connections severely narrows the detection scope, leaving the organization blind to offline or local malicious activities. Attackers frequently use rundll32.exe to execute local payloads, dump credentials, or perform privilege escalation without initiating outbound network traffic, which this modification would fail to detect.

Disable the rule entirely

Why it fails: Deactivating the correlation rule completely eliminates visibility into a highly abused native Windows binary, creating a critical blind spot in the organization's defensive posture. While this action stops the influx of false positives, it leaves the environment entirely vulnerable to Living-off-the-Land (LotL) attacks that leverage rundll32.exe for stealthy execution.

Increase the severity threshold of the rule

Why it fails: Adjusting the severity or priority level of the alert does not resolve the underlying issue of high false-positive rates; it merely changes how the alert is categorized in the analyst's queue. The noisy, non-malicious events will continue to trigger, contributing to ongoing alert fatigue and potentially burying actual high-severity incidents under a flood of misclassified notifications.

File hash

Why it fails: A file hash, such as an MD5, SHA-1, or SHA-256 signature, is a cryptographic representation of a file's static contents. While file hashes are vital host-based indicators of compromise used to identify malicious binaries on endpoints, they do not represent network-level communication telemetry like IP addresses or port numbers.

Email indicator

Why it fails: Email indicators of compromise specifically encompass elements found within email headers and bodies, such as sender addresses, subject lines, attachment names, and malicious URLs embedded in the message. Although phishing emails are common delivery vectors for malware, raw IP addresses observed during active runtime execution are classified as network indicators rather than email-specific metadata.

Domain name

Why it fails: Although domain names are also categorized as network-based indicators of compromise, they represent human-readable alphanumeric strings resolved via DNS, such as malicious C2 domains. Because the specific artifact identified in this scenario is a raw IP address rather than a fully qualified domain name (FQDN), this classification is technically inaccurate.

To change the desktop wallpaper

Why it fails: While desktop background configurations are indeed managed via the registry, they are specifically located under the Control Panel\Desktop subkey, such as the Wallpaper string value. Modifying a standard startup or Run key would not alter the visual desktop background directly, making this an incorrect interpretation of the alert's intent. Instead, such modifications are indicative of execution rather than cosmetic customization.

To disable Windows Defender

Why it fails: Disabling or tampering with Windows Defender is typically achieved by modifying policies under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender or stopping the associated system services. While this is a common defense evasion tactic, it relies on entirely different registry hives and keys than the Run keys targeted for startup execution. Therefore, a Run key modification alert would not directly indicate the disabling of antivirus defenses.

To update the system time

Why it fails: System time synchronization and time zone configurations are managed by the Windows Time service and its corresponding parameters located under HKLM\SYSTEM\CurrentControlSet\Services\W32Time. Modifying user or machine Run keys has no functional impact on the system clock or network time protocol settings. Analysts would look for changes in system services or specific time-provider registry keys to investigate unauthorized time modifications.

A DNS MX record report

Why it fails: Mail exchange records do not describe application dependencies.

A password complexity screenshot only

Why it fails: Password settings are unrelated to supplied libraries.

A building floor plan

Why it fails: Physical layout does not identify software components.

Uninstall the operating system and reimage.

Why it fails: Uninstalling the operating system and reimaging an infected system is a highly destructive action that eradicates critical forensic evidence necessary for root cause analysis and threat intelligence gathering. This step is typically performed much later in the incident response lifecycle, during recovery, after proper containment and evidence collection have occurred. Furthermore, it does not immediately isolate the system from the network if the OS is still running during the uninstallation process.

Pull the power cord from the infected system.

Why it fails: Pulling the power cord from an infected system results in an uncontrolled shutdown, leading to the immediate loss of all volatile data residing in RAM, which is crucial for forensic investigation. This abrupt power loss can also corrupt file systems or operating system files, hindering subsequent analysis and recovery efforts. While it isolates, it does so at a significant cost to evidence integrity.

Delete the infected user's account.

Why it fails: Deleting an infected user's account primarily revokes that user's access privileges but does not inherently disconnect the compromised system from the network or stop malicious processes already running under other contexts. The malware may persist, operate under a different account, or leverage system-level privileges, rendering account deletion ineffective for immediate network containment. This action also removes potential audit trails associated with the account.

Increase only the port range

Why it fails: Increasing only the port range for a vulnerability scan primarily expands the scope of network services probed, but it does not enable the scanner to inspect the internal state of the operating system or installed applications. While more open ports might reveal additional network-accessible services, this approach fails to provide critical information regarding patch levels, system configurations, or software versions that are not externally exposed. Therefore, it will not reliably improve the accuracy of findings related to internal system vulnerabilities.

Disable host firewalls permanently

Why it fails: Permanently disabling host firewalls is a severe security misconfiguration that significantly elevates the risk profile of Windows servers by exposing all services directly to the network. This action is entirely unnecessary for effective vulnerability scanning, as authenticated scans can operate through properly configured firewalls that permit specific, secure communication channels. Such a drastic measure creates an unacceptable attack surface, making systems vulnerable to a wide array of network-based exploits.

Trust the unauthenticated result as complete

Why it fails: Trusting unauthenticated scan results as complete for Windows servers is a critical oversight, as these scans are inherently limited to external observations and publicly exposed service banners. They lack the necessary access to query the operating system's registry, file system, or installed package managers to accurately determine patch status, internal configuration flaws, or application-specific vulnerabilities. Consequently, unauthenticated scans frequently report a low number of findings, creating a false sense of security by missing a significant portion of actual risks.

Shut down the system

Why it fails: Powering down or shutting down an infected machine destroys volatile data stored in RAM, such as running processes, active network connections, and unencrypted cryptographic keys. While it stops the attack, it severely compromises subsequent forensic investigations and malware analysis.

Reimage the system

Why it fails: Reimaging involves wiping the storage media and deploying a clean operating system template, which is a core activity of the eradication and recovery phases. Performing this step during containment is premature, as it destroys all forensic evidence before the incident scope is fully understood.

EventID: 4688 (Process Creation) AND ParentImage: '*reg.exe*'

Why it fails: Windows Security Event ID 4688 tracks process creation events. Filtering for a parent image of reg.exe identifies child processes spawned by the registry console tool, which does not directly capture the actual modification of registry keys or values. This approach fails to detect registry changes made via APIs, PowerShell, or other non-child-process-spawning methods.

EventID: 4657 (Registry modification) AND ObjectName: '*\RunOnce*'

Why it fails: While Windows Security Event ID 4657 monitors registry modifications, searching for \\RunOnce targets a distinct, one-time execution key rather than the standard persistent Run key. Additionally, Event ID 4657 uses the ObjectName field to log the key path, whereas Sysmon-style rules or specific schema mappings might expect TargetObject, leading to potential parsing failures.

EventID: 1 (Process Creation) AND CommandLine: '*reg.exe*'

Why it fails: Sysmon Event ID 1 logs process creation, and while monitoring reg.exe execution in the command line can identify manual registry manipulation, it does not guarantee a modification occurred to the specific persistence keys. This broad approach generates significant noise and high false-positive rates because legitimate administrative scripts frequently execute reg.exe for benign queries.