Incident Handling and Response practice questions

Preparation

Why it fails: Preparation involves establishing the security posture, training personnel, and acquiring necessary tools before an incident occurs. While it ensures the organization is ready to respond, it does not involve the active analysis of an ongoing breach or the determination of scope for a specific active threat.

Containment

Why it fails: Containment focuses on stopping the spread of the attack and limiting further damage. While identifying the scope is necessary before fully containing a threat, the actual process of containment involves isolation or disconnection, which occurs after the incident has been identified and the extent is understood.

Lessons Learned

Why it fails: Lessons learned occurs after the incident is resolved to improve future responses and update security policies. It focuses on evaluating the effectiveness of the response process itself rather than actively investigating the current incident, identifying the attacker's path, or assessing the impact of the active security breach.

Establishing a standard incident response team hierarchy

Why it fails: Establishing roles and responsibilities is part of the Preparation phase. While team structure may be reviewed during post-incident activities, the primary goal is not to redefine the hierarchy, but to evaluate the effectiveness of the existing response process and identify gaps in the execution of the plan.

Validating the integrity of restored systems

Why it fails: Validating restored systems is part of the Eradication or Recovery phase. While ensuring integrity is critical, this activity happens before the formal post-incident phase. The focus during post-incident review is on analyzing the incident's impact and improving documentation, rather than verifying the technical state of individual restored systems.

Isolating infected systems from the production network

Why it fails: Isolating systems is a fundamental step of the Containment phase. It occurs early in the incident response process to prevent the spread of the attack. By the time the team reaches the post-incident activity phase, the systems should already be contained, eradicated, and restored to operational status.

Hard drives, memory, cache, registers

Why it fails: This order is reversed. Hard drives are the least volatile and should be captured last, while registers are the most volatile and must be captured first. Collecting in this order would result in the loss of critical, volatile information stored in memory and registers during the imaging process.

Memory, hard drives, cache, registers

Why it fails: This sequence is incorrect because it mixes volatile and persistent media. Cache and registers are more volatile than memory and must be captured first. Placing hard drives before cache ensures the loss of data that exists only in CPU registers, which is crucial for reconstruction of the attack.

Hard drives, registers, cache, memory

Why it fails: This order ignores the fundamental principle of volatility. Starting with hard drives is safe, but skipping to registers and then memory is chaotic and risks system state changes. Data must be gathered in strict order of volatility to ensure the most transient information is secured before any modification.

Review the SIEM logs to determine the exact files that were transferred.

Why it fails: Reviewing logs to determine the files transferred is part of the investigation phase, but it does not stop the ongoing exfiltration. The first action should be to contain the incident to prevent further data loss. Log analysis can be conducted after containment, and the logs will still be available. Prioritizing analysis over containment allows the attacker to continue stealing data.

Contact the employee to verify whether the data transfer was authorized.

Why it fails: Contacting the employee is not the first action because the employee is on vacation and may be unreachable, delaying containment. While verification is important, the immediate priority is to stop any ongoing data loss. Waiting for confirmation could allow the exfiltration to continue, causing further damage. Containment should precede verification when unauthorized activity is strongly suspected.

Capture a forensic image of the workstation's memory and disk before taking any other action.

Why it fails: Capturing a forensic image is important for evidence preservation, but it is not the first action when data exfiltration is actively occurring. The priority is to stop the data loss, which requires containment. Forensic imaging can be performed after containment, or in a way that does not disrupt containment. Delaying containment to image could result in significant additional data loss.

lsof -i

Why it fails: lsof -i lists open files associated with network connections, which can be useful, but it is not as comprehensive as netstat -anp for showing all connections and listening ports with process IDs. The netstat command is more commonly used and provides a clearer view of the network state. lsof -i may miss some connections or not show listening ports in the same way.

ps aux

Why it fails: ps aux lists all running processes with detailed information, but it does not show network connections. While it is useful for identifying suspicious processes, it does not capture the network state. The question specifically asks for network connections and listening ports, so ps aux is not the correct tool for that task.

ifconfig -a

Why it fails: ifconfig -a displays network interface configuration, such as IP addresses and MAC addresses, but it does not show active connections or listening ports. It is useful for understanding the network configuration but not for capturing the current network activity. The responder needs to see connections, not just interface settings.

Reboot the workstation immediately

Why it fails: Rebooting will clear volatile memory, destroying critical evidence such as the decrypted command string or active socket connections. Forensic best practices dictate that the system state must be preserved for analysis before any destructive actions like reboots are performed, as memory artifacts are essential for identifying the payload.

Delete the PowerShell process

Why it fails: Terminating a process is an insufficient containment measure because the attacker may have already established other persistence mechanisms or secondary backdoors. The malicious process could also be a child of another service, leading to immediate respawning. Full network isolation is required to ensure the host is contained.

Update the antivirus definitions

Why it fails: Updating antivirus is a long-term remediation step, not an immediate containment action. During an active incident involving encoded command execution, the priority is to stop the adversary's access. Relying on antivirus signatures is reactive and unlikely to stop a custom script that is already running in memory.

Integration with the social media monitoring platform

Why it fails: Social media monitoring is generally unrelated to technical incident response automation. While PR teams might use it during a breach, integrating it into the automated incident response tool would not assist in the technical tasks of containment or eradication, making it a low priority for security incident response.

Integration with external threat intelligence feeds

Why it fails: While threat intelligence is useful for contextualizing an attack, it is secondary to the operational requirement of having validated, reliable playbooks. An automated tool with intelligence but without proper operational playbooks is ineffective, as it cannot take correct, decisive action to stop the adversary in real-time.

Unlimited cloud storage for log retention

Why it fails: While storage is important for forensics, it is not a requirement for the operational effectiveness of an automated response tool during an incident. The tool's ability to act on data is more critical than the volume of data stored, as immediate action is required to contain threats.

Analyzing the memory dump for malware signatures

Why it fails: Analyzing a memory dump is an Identification or investigation activity. Eradication is the process of removing the threat from the environment. Once the threat is identified, the focus shifts to neutralizing it, not continuing the analysis, which would have happened in the earlier identification and forensic investigation phases.

Drafting an incident report for executive leadership

Why it fails: Drafting an incident report is a task for the post-incident activity or documentation phase. While reporting is important for stakeholders, it does not contribute to the actual removal of the adversary's access or the restoration of the secure state of the systems, which is the sole focus of eradication.

SQL Injection; Containment

Why it fails: The error log refers to an XSS attempt, not SQL injection, which would involve database queries. Furthermore, the event indicates a blocked attempt, meaning the immediate containment of a breach is not required; rather, the event must be identified and analyzed to determine if further action is needed.

Cross-Site Request Forgery; Eradication

Why it fails: This is not a CSRF attack, as the payload is clearly XSS script injection. Eradication is also incorrect because the attack was blocked, and no system infection has occurred. The incident requires identification and analysis, not the removal of a persistent threat or malware from the web servers.

Buffer Overflow; Preparation

Why it fails: This is not a buffer overflow, which involves memory corruption at the process level. Additionally, this event is occurring in real-time and must be handled via the incident response process, not the Preparation phase, which is for pre-incident planning and establishing the security framework before any attacks occur.

A list of all employee hardware serial numbers

Why it fails: While asset inventory is useful for investigations, it is not a legal or regulatory requirement for breach notification. Compliance hinges on the handling and reporting of data breaches, not on the tracking of individual hardware assets. Therefore, this document does not assist with legal or regulatory compliance requirements.

The corporate employee handbook

Why it fails: The employee handbook defines internal corporate policies and behavior expectations. It does not contain the technical or legal procedures required for managing a data breach or ensuring regulatory compliance. Relying on an employee handbook during a security incident would lead to a lack of structure and potential regulatory failure.

The server room floor plan

Why it fails: A physical floor plan of the server room is irrelevant to data privacy and breach notification compliance. While it might be useful for physical security, it offers no guidance on how to fulfill legal duties when sensitive information is compromised, which is the primary focus of security incident compliance.

Preparation

Why it fails: Preparation involves establishing policies, tools, and training before an incident occurs. Isolating a compromised server is a reactive step taken during an active incident, not part of pre-incident readiness. Preparation would include having an isolation playbook ready, but the act of isolating is not preparation itself.

Recovery

Why it fails: Recovery focuses on restoring normal operations, such as bringing the server back online after it has been cleaned and verified. Isolating the server is the opposite of recovery; it takes the system out of production to prevent further harm. Recovery would happen later in the incident lifecycle.

Eradication

Why it fails: Eradication involves removing the threat, such as deleting malware or closing vulnerabilities. Isolation does not remove the attacker or the malware; it only restricts their ability to communicate. Eradication would occur after containment, when the analyst cleans the system or rebuilds it.

Detection and Analysis

Why it fails: Detection and Analysis is the phase where the incident is identified and investigated. While the delayed detection occurred during this phase, the root cause was inadequate preparation. The finding is not about improving analysis techniques but about ensuring the necessary data is available beforehand. Thus, the corrective action targets preparation.

Containment, Eradication, and Recovery

Why it fails: This phase deals with limiting damage, removing the threat, and restoring systems. The issue described is about detection delays due to missing log integration, which is unrelated to containment or recovery actions. Improving these later phases would not address the root cause of the delayed detection.

Post-Incident Activity

Why it fails: Post-Incident Activity is the phase where the lessons-learned meeting takes place, but the finding itself is about improving preparation. The meeting is a mechanism to identify improvements, and here the improvement is to preparation. Selecting this phase would be circular, as it is the phase conducting the review, not the phase being improved.

Eradication

Why it fails: Eradication is the removal of the malicious component and the root cause. While the antivirus quarantined the trojan, the analyst has not confirmed removal of persistence mechanisms or verified the root cause. The scenario describes detection, not the deliberate elimination of the threat, so Eradication is premature here.

Containment

Why it fails: Containment involves limiting the damage and preventing further spread, such as isolating the host from the network. The scenario states the endpoint is still running and no containment actions have been taken. The analyst is only validating the alert, so labeling this Containment skips the critical Identification step that precedes any containment action.

Recovery

Why it fails: Recovery focuses on restoring systems to normal operation and monitoring for recurrence. The endpoint was never taken offline or remediated, so there is nothing to recover. The analyst is still determining whether an incident occurred, which places the activity firmly in Identification rather than Recovery.

Disconnect the server from the network, then capture memory after confirming no active sessions remain.

Why it fails: Disconnecting the network preserves some evidence but, more importantly, the delay while confirming no active sessions allows memory-resident artifacts to change or be lost. Memory capture should occur before significant state changes. Waiting reduces the fidelity of the volatile data and risks the adversary or normal processes overwriting the very artifacts the responder needs.

Shut down the server immediately to prevent lateral movement, then image the disk on a write blocker.

Why it fails: Shutting down destroys volatile memory, including active network connections, decrypted keys, and in-memory malware. Disk imaging on a write blocker preserves persistent data but cannot recover what was only in RAM. Because the scenario specifically asks to preserve the most volatile evidence, an immediate shutdown contradicts the order of volatility and loses critical artifacts.

Run a full antivirus scan and collect the resulting log before capturing memory.

Why it fails: Running an antivirus scan modifies the system state and can delete or quarantine artifacts, contaminating evidence. It also consumes time and may trigger adversary anti-forensic behavior. The scan output is not a substitute for a raw memory image, and performing it first violates the principle of capturing the most volatile data before less volatile sources.

Immediately power off the host to sever the C2 channel and prevent further data exfiltration.

Why it fails: Powering off severs the channel but destroys volatile memory, active connections, and in-memory malware, severely degrading the investigation. It may also trigger dead-man switches or encrypted payloads that activate on reboot. Because the scenario explicitly values preserving evidence, an immediate power-off is too destructive and forfeits valuable forensic artifacts.

Change the host's IP address and update DNS records to redirect the adversary to a honeypot.

Why it fails: Redirecting traffic to a honeypot can be useful for threat intelligence but does not reliably contain the adversary, who may detect the change or use other channels. It also risks alerting the attacker and causing them to accelerate their objectives. This approach is more deception than containment and does not preserve the host's state for evidence collection.

Block the C2 IP at the perimeter firewall and leave the host online to observe further adversary behavior.

Why it fails: Blocking only the known C2 IP may stop one channel but leaves the host online, allowing the adversary to use alternate infrastructure or fallback domains. It also risks continued lateral movement within the VLAN. While it preserves evidence, it fails to adequately limit the adversary's access, which is the primary containment goal in this scenario.

Reimage all affected endpoints and restore data from the most recent backups.

Why it fails: Reimaging and restoring from backups are Recovery-phase activities, not Post-Incident Activity. While they are essential to restoring operations, they occur before the formal lessons-learned review. Performing them does not fulfill the phase's goal of analyzing and improving the response process, so this is not an appropriate Post-Incident Activity task.

Isolate the compromised network segment to prevent the ransomware from spreading further.

Why it fails: Isolating a network segment is a Containment-phase action taken during the active incident to limit spread. By the time the organization conducts a formal lessons-learned review, containment has already occurred. Treating isolation as a Post-Incident Activity misplaces it in the lifecycle and does not contribute to the analytical and improvement goals of the phase.

Eradicate the ransomware binaries and remove persistence mechanisms from infected hosts.

Why it fails: Eradicating malware and removing persistence are Eradication-phase tasks that happen before recovery and post-incident review. The scenario is set after a major incident where eradication has presumably concluded. Including this as a Post-Incident Activity confuses the phase sequence and does not address the review-and-improve objective of the phase.

Chain of custody, by documenting each piece of evidence collected.

Why it fails: Chain of custody concerns documenting who handled evidence, when, and how to maintain its integrity for legal use. The scenario describes collecting volatile data, not logging custody transfers. While chain of custody matters, it does not explain why the analyst prioritized live state over copying binaries, so it is not the principle being applied here.

Least privilege, by limiting the analyst's access to system resources.

Why it fails: Least privilege restricts user and process permissions to the minimum necessary. The scenario does not describe permission restrictions; it describes the sequence of evidence collection. The analyst's choice to gather volatile data first is unrelated to access control, so least privilege is not the principle at work in this situation.

Defense in depth, by using multiple tools to examine the system.

Why it fails: Defense in depth layers security controls so that failure of one does not compromise the whole. The analyst is not deploying layered controls; they are sequencing evidence collection. The decision to capture volatile state before static binaries reflects the order of volatility, not a layered defensive strategy, so this option does not fit the scenario.

Implement a security awareness training program that teaches employees to recognize phishing emails.

Why it fails: Security awareness training is valuable, but it is not the most effective technical control for preventing macro-based malware. Users can still be tricked, and training alone does not block the execution of malicious macros. While it reduces risk, it is less reliable than technical controls that enforce policy. The question asks for the most effective action, which should be a technical control that directly mitigates the vector.

Deploy an endpoint detection and response (EDR) solution to detect and block malicious macro execution.

Why it fails: An EDR solution can detect and block malicious activity, but it is not as deterministic as disabling macros by default. EDR relies on behavioral detection, which can sometimes miss novel or obfuscated attacks. While EDR is a valuable layer, the most effective prevention is to eliminate the attack surface by disabling macros unless explicitly trusted. EDR is a detective and responsive control, not a preventive one for this specific vector.

Configure email filtering to block all emails with macro-enabled attachments.

Why it fails: Blocking all macro-enabled attachments can be effective, but it may also block legitimate business documents and is not foolproof because attackers can use other file types or techniques to deliver macros. It is a useful control, but disabling macros at the application level is more comprehensive and prevents execution even if the email bypasses filtering. Email filtering is a preventive measure but does not address the root cause of macro execution.

Conduct a post-incident review to document lessons learned.

Why it fails: Conducting a post-incident review is part of the post-incident activity phase, which occurs after the incident is resolved. Eradication is about removing the threat and preventing recurrence. The post-incident review is a separate phase that evaluates the response and identifies improvements. It is not performed during eradication.

Restore the server from a known good backup taken before the infection.

Why it fails: Restoring from a backup is part of the recovery phase, not eradication. Eradication focuses on removing the threat and its root cause. Recovery involves bringing systems back into production, often by restoring from backups. While restoration can be a way to eradicate malware, it is typically considered a recovery step because it returns the system to a functional state. The question specifically asks for eradication actions.

Monitor network traffic for signs of re-infection.

Why it fails: Monitoring network traffic is part of the detection and analysis or post-incident monitoring, not eradication. While monitoring is important to ensure the threat is gone, it is not an eradication action. Eradication involves active removal of the threat. Monitoring is a passive detective control that can be used to verify the success of eradication but is not the eradication itself.

The analyst used domain administrator credentials, which violates the principle of least privilege.

Why it fails: Using domain administrator credentials on a potentially compromised system is risky and could expose those credentials, but the most direct violation is the failure to contain the workstation before eradication. Least privilege is a supporting principle; the primary incident handling error is the order of operations, allowing potential spread.

The analyst failed to preserve the chain of custody for the workstation's hard drive.

Why it fails: Chain of custody applies to evidence collected for legal proceedings, typically involving proper documentation and handling. While the analyst's actions may compromise evidence, the immediate and most direct violation is failing to contain the system before attempting eradication. Chain of custody is a downstream concern and not the primary principle breached here.

The analyst should have escalated to senior management before taking any action on the workstation.

Why it fails: Escalation is important, but incident response procedures often authorize initial containment actions by first responders. The critical error is not the lack of escalation but the sequence of actions: deleting files while the system remained networked. Escalation alone would not have prevented the spread; containment would have.