Operating Systems practice questions

Shut down the file server and domain controller to protect critical systems from potential encryption.

Why wrong: Shutting down critical infrastructure like file servers and domain controllers is premature and highly disruptive, impacting business operations unnecessarily when these systems are not confirmed to be compromised. Furthermore, powering off these servers would destroy valuable volatile memory data, such as active network connections, running processes, and logged-in users, which could be vital for understanding the broader scope of the attack if they were indeed targeted or compromised. The immediate priority is containing the *known* infection.

Power off the three infected workstations immediately to contain the encryption process.

Why wrong: Powering off the infected workstations immediately, while seemingly containing the encryption, would destroy critical volatile memory data. This includes running processes, network connections, open files, and cached credentials, all of which are invaluable for forensic investigators to determine the initial compromise vector, the malware's behavior, and potential command-and-control communications. Preserving this evidence is paramount for a thorough incident response.

Apply the latest SMB vulnerability patch to the file server and domain controller to block the propagation vector.

Why wrong: Applying patches to the file server and domain controller, while a good long-term security practice, does not address the immediate threat of active ransomware on the three workstations. The encryption process on the already infected machines would continue locally, and patching does not prevent lateral movement from systems already compromised and potentially exploiting other vulnerabilities or credentials. Containment of the active threat takes precedence over preventative patching at this stage.

Burp Suite

Why wrong: Burp Suite is a web application security testing tool.

Nessus

Why wrong: Nessus is a general vulnerability scanner for networks and systems.

OpenVAS

Why wrong: OpenVAS is also a general network vulnerability scanner.

Vulnerability scanner

Why wrong: A vulnerability scanner, such as Nessus or OpenVAS, is a diagnostic tool used to identify security weaknesses, including missing patches, misconfigurations, and known vulnerabilities, within a network or system. While it provides critical insights into an organization's security posture by detecting unpatched software, it does not possess the functionality to deploy or apply those patches. Its role is solely assessment and reporting, not remediation.

Configuration management tool

Why wrong: A configuration management tool, like Ansible, Puppet, or Chef, primarily focuses on maintaining a desired state for systems and deploying software or configurations consistently. While it could be leveraged to push certain updates, it lacks the specialized features of a dedicated patch management system, such as robust patch testing environments, dependency checking, or integrated rollback capabilities specific to security updates. Its general-purpose nature makes it less efficient for the comprehensive and continuous process of security patch deployment.

Security information and event management (SIEM) system

Why wrong: A SIEM system aggregates and correlates security logs and event data from various sources across an IT environment to detect anomalies, identify potential threats, and generate alerts. Its core function is to provide centralized visibility into security incidents and compliance, enabling rapid response to detected issues. However, a SIEM is purely an observation and alerting platform; it does not have any native capabilities to initiate, manage, or automate the deployment of security patches to endpoints.

Remove the server from the network immediately.

Why wrong: Removing the server from the network immediately, while seemingly secure, is often impractical and detrimental in a financial institution. Such a drastic action would likely disrupt critical business operations, halt ongoing compliance audits, or prevent essential regulatory reporting, leading to significant financial and legal repercussions. This approach prioritizes security over availability and business continuity without exploring less disruptive mitigation strategies.

Accept the risk and document the exception.

Why wrong: Accepting the risk and merely documenting an exception is an insufficient response, particularly given a 72-hour remediation policy for vulnerabilities. This approach fails to actively mitigate the identified security weakness, leaving the financial institution exposed to potential breaches, data loss, and severe regulatory penalties. Risk acceptance is typically reserved for low-impact risks or when all other mitigation options are exhausted and formally approved at a high organizational level, which is not the case here.

Apply a custom patch developed by the manufacturer.

Why wrong: Applying a custom patch developed by the manufacturer is highly improbable and unrealistic for an end-of-life (EOL) operating system. When an OS reaches EOL, the manufacturer has officially ceased all support, including the development of new security patches or custom fixes. Even if an unofficial patch were somehow created, it would lack vendor backing, potentially introduce new vulnerabilities or system instability, and would not be a reliable, long-term solution for a critical financial system.

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

Why wrong: 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 wrong: 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 wrong: 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 verbose output to reduce clutter.

Why wrong: 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 wrong: 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 wrong: 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.

Running a full antivirus scan on the workstation

Why wrong: Running a full antivirus scan on the workstation is primarily a detection and remediation step, not an immediate containment action for an active ransomware infection. While it might identify some malicious files, it is unlikely to stop an ongoing encryption process and could consume critical system resources, potentially accelerating the encryption or alerting the attacker to the detection, prompting further malicious actions or deletion of forensic artifacts. The primary goal in an active ransomware scenario is to prevent further spread, which scanning alone does not guarantee.

Disabling the user's Active Directory account

Why wrong: Disabling the user's Active Directory account primarily restricts network access and authentication for that user. While it can prevent the user from logging into other systems or accessing network shares, it does not stop ransomware that has already executed on the local workstation from continuing its encryption process or attempting to spread laterally using existing local privileges or cached credentials. The ransomware's local operations are largely independent of the user's AD account status once execution has begun, making this an ineffective immediate containment strategy.

Rebuilding the workstation from a known good image

Why wrong: Rebuilding a workstation from a known good image is a crucial step in the recovery phase of an incident response, aiming to restore the system to a clean state. However, it is not an immediate containment action. Attempting to rebuild a system while it is actively infected and potentially connected to the network risks further compromise or data loss, and it fails to address the immediate threat of the ransomware spreading to other systems. Containment must precede recovery to prevent wider impact and ensure the source of infection is isolated.

Creating a forensic image of the infected systems for later analysis.

Why wrong: While creating a forensic image is essential for preserving evidence and supporting post-incident analysis, it does nothing to stop the malware from continuing to communicate or spread across the network. Containment must occur first to halt active propagation; imaging is a preservation step, not a containment action. In this scenario, it is a wrong answer because it fails to address the immediate threat.

Identifying and patching the vulnerability exploited by the malware.

Why wrong: Identifying and patching the exploited vulnerability is part of eradication and recovery, not immediate containment. Patching requires vulnerability analysis, patch availability, and deployment, during which malware can continue spreading; it also does not remediate systems already compromised. Thus, it is not an appropriate initial containment action for an active outbreak.

Notifying law enforcement agencies about the incident.

Why wrong: Notifying law enforcement is a legal and procedural obligation that may be required by policy, but it is not a technical containment action. It has no effect on malware execution, communication, or spread, and should occur in accordance with the incident response plan after containment is initiated. Consequently, it is incorrect in the context of immediate incident containment.

Change passwords for affected accounts

Why wrong: Changing passwords for affected accounts is a containment and recovery measure, not an evidence preservation step. Password resets modify authentication logs and Kerberos/Authentication tokens, potentially destroying the very artifacts needed to trace an attacker's lateral movement or account hijacking. In incident response, credential rotation should be performed only after forensic data is captured, so that the evidence of the compromise remains pristine for legal or investigative review.

Disconnect the system from the network

Why wrong: Disconnecting the system from the network is a vital containment action to stop ongoing data exfiltration, but it is not the immediate priority in the preservation phase. Network isolation abruptly terminates live connections, causing volatile evidence such as active TCP/UDP sessions, ephemeral ports, and in-memory network buffers to be lost forever. It may also trigger remote kill-switches or anti-forensic routines, so it should be executed only after volatile data and forensic images have been collected.

Kill malicious processes

Why wrong: Killing malicious processes is a classic mistake because it destroys the volatile memory footprint of the malware, including injected code, decrypted payloads, API calls, and encryption keys. Terminating a process may also trigger self-deletion or anti-forensic mechanisms, erasing the very evidence needed to determine how data was exfiltrated. Instead, a memory dump should be collected first; only after forensic preservation should the process be safely stopped as part of containment.

Deploying patches directly to all production systems simultaneously

Why wrong: Deploying patches directly to every production system at once bypasses the validation and staged rollout that illuminate unknown side effects, meaning a faulty patch could immediately disable systems organization-wide. This approach violates change management policies, makes rollback exceedingly difficult because no pilot environment exists, and leaves the helpdesk overwhelmed if issues arise. Even in emergency scenarios, a controlled rollout to a subset of high-risk systems is safer than simultaneous deployment, because it preserves the ability to pause and reassess before broader exposure.

Disabling all security controls to avoid conflicts

Why wrong: Disabling security controls like endpoint detection, antivirus, or host firewalls during patch installation removes the very defenses that would catch malicious activity while systems are in a transient and potentially vulnerable state. It also violates the principle of defense-in-depth, and any perceived conflict between controls and patches is best addressed by testing the patch in a staging environment rather than weakening the security posture. Many organizations have compliance mandates (e.g., PCI DSS, HIPAA) that require those controls; turning them off could result in audit findings, fines, or unexpected exposure to active threats.

File system for malicious executables

Why wrong: Searching the file system for malicious executables is a common malware detection technique, but it does not directly identify lateral movement that occurs via legitimate login mechanisms or built-in administrative tools. An attacker often leverages existing binaries (e.g., PowerShell, psexec, or WMI) to move laterally, so the absence of newly dropped executables does not rule out lateral movement. While useful for post-compromise detection, it is secondary to logon events for this specific hypothesis.

Registry hives for persistence

Why wrong: Registry hives are more relevant to persistence detection, such as Run or RunOnce keys that re-establish access after a reboot, rather than detecting in-progress lateral movement. Attackers may use registry modifications to survive reboots, but that is a separate stage of the attack lifecycle. While registry data can support a comprehensive hunt, it is not a direct artifact for identifying user logins or remote access patterns associated with lateral movement.

Blocking the ransomware's command-and-control IP at the firewall

Why wrong: While blocking a ransomware C2 IP at the firewall can momentarily disrupt command-and-control, this measure is quickly circumvented because attackers routinely use domain generation algorithms, fast-flux DNS, or multiple fallback addresses to change their infrastructure. Moreover, it fails to address the underlying infection, the initial entry vector, or any laterally spread malware, so the ransomware remains active and capable of continuing its encryption or exfiltration. Consequently, it is only a stopgap containment tactic, not a complete containment or eradication step.

Isolating the affected network segment

Why wrong: Isolating the affected network segment (e.g., via VLAN segregation or disconnecting switches) is a rapid containment action that physically halts east-west propagation and buys time, but it is not a complete containment solution by itself. Attackers often have pre-positioned remote access, compromised credentials, or alternate paths that bypass the isolated segment, and the isolation does nothing to remove the malware already present or prevent reinfection from a different vector. Furthermore, continuing isolation can severely impact business operations, so it must be followed by proper eradication and recovery steps rather than being viewed as a final answer.

Isolate the infected systems from the network

Why wrong: Isolating infected systems from the network is a valid short-term containment tactic that limits lateral movement, but it does nothing to remove the ransomware or recover already encrypted files. Network isolation only buys time for the incident response team to determine the scope of the breach and begin eradication. It may also disrupt business operations if critical servers are disconnected, and it does not address the underlying vulnerability or compromised credentials that allowed the attack. In a formal incident response plan, isolation is a Phase 1 step, not the final remediation.

Block the ransomware's C2 domain at the firewall

Why wrong: Blocking the ransomware's C2 domain at the firewall is another short-term containment measure that severs the malicious program's ability to receive commands or exfiltrate data. However, modern ransomware often uses domain generation algorithms (DGA), hardcoded fallback IP addresses, or multiple redundant C2 servers, so one block is insufficient. This action also fails to decrypt files, remove resident malware, or restore systems to a known-good state. It is a defensive countermeasure, not a recovery or eradication step, and must be paired with a comprehensive root-cause investigation.

Isolate the affected network segment

Why wrong: Isolating the affected network segment (e.g., VLAN segmentation or unplugging switches) is a short-term containment tactic that limits lateral movement and contains the blast radius, but it does not eliminate the attacker's foothold or the vulnerability. The compromised systems remain infected and unpatched, and the attacker may have already established persistence that is unaffected by the isolation. This is a stopgap measure to buy time, not a final fix.

Disable compromised user accounts

Why wrong: Disabling compromised user accounts stops the attacker from using stolen credentials through normal authentication, but it ignores other persistence mechanisms such as newly created backdoor accounts, scheduled tasks, or service modifications. The root vulnerability remains unpatched, so the attacker can simply re-exploit the same flaw to regain access even without valid credentials. This is a reactive containment step, not a comprehensive remediation strategy.

Block malicious IPs at the firewall

Why wrong: Blocking malicious IPs at the firewall disrupts communication with known command-and-control (C2) servers or attacking hosts, but attackers easily rotate IPs, leverage cloud services, or use DNS over HTTPS to evade such blocks. Compromised systems remain intact and unpatched, so the attacker can pivot through new infrastructure or re-attract from an alternate source. This is an ephemeral, reactive measure that fails to address the underlying vulnerability.

avml

Why wrong: AVML is a memory acquisition tool for Linux, but LiME is more commonly recommended for live systems with minimal impact.

WinPmem

Why wrong: WinPmem is for Windows memory acquisition, not Linux.

dd

Why wrong: dd is used for disk imaging, not memory acquisition.

The number of times a vendor has released a patch for the vulnerability

Why wrong: The number of vendor patch releases is irrelevant because a vendor may issue multiple patches for a single vulnerability due to regressions, additional fix revisions, or rolling support, none of which change the underlying severity or exploitability. Patch count is a maintenance statistic, not a risk metric.

The color of the vulnerability in the scan report

Why wrong: The color of a vulnerability in a scan report is merely a visual representation of the severity band derived from a scoring system, not an independent criterion. Colors can vary by scanner and are not a decision factor in themselves; they simply summarize other metrics.

Pay the ransom to recover data quickly.

Why wrong: Paying the ransom provides no technical guarantee that the attacker will supply a working decryption key, and even if a key is delivered, it may only partially restore files, leaving some data permanently lost. Furthermore, it funds the criminal infrastructure and may mark the organization as a willing target for future extortion, and in many jurisdictions paying ransom to sanctioned entities can carry legal penalties. This action should never be the immediate response during an active outbreak.

Contact law enforcement for guidance.

Why wrong: Contacting law enforcement is an important post-incident step for notification and legal compliance, but it does not provide the immediate, granular technical guidance needed to halt an ongoing ransomware encryption spree. Law enforcement agencies typically do not offer real-time response capabilities, and by the time they respond, the malware may have already propagated across the network. Therefore, this action should be deferred until after the network shares are disconnected and affected workstations are isolated.

Reimage all affected systems immediately.

Why wrong: Reimaging affected systems immediately is counterproductive because it destroys volatile and non-volatile forensic evidence, including the ransomware binary, artifacts of the initial infection vector, and any indicators of compromise that could be used to identify other affected hosts. Without a forensic image or memory dump, the security team may fail to discover the root cause, allowing the same vulnerability to be re-exploited after reimaging. Reimaging should only be performed after thorough evidence collection and when the system is ready for secure restoration.