Incident Response practice questions

Block the foreign IP address at the firewall and wait for more alerts before acting.

Why it fails: Blocking the foreign IP at the firewall only restricts traffic from a single source address, which is easily bypassed by an attacker using a VPN, proxy, or dynamic IP rotation. Additionally, if the attacker has already authenticated, they may hold an active session or token that will continue to work regardless of firewall rules. Waiting for more alerts before acting gives the adversary more time to move laterally or exfiltrate data, delaying necessary containment of the compromised account.

Reset the user password and close the alert because the new password will stop the attack.

Why it fails: A password reset only changes the credential for future logins, but it does not invalidate already-issued session cookies, OAuth access tokens, or Kerberos tickets that the attacker may be using to maintain authenticated access. Many applications and services cache tokens that remain valid for hours or days, allowing the threat actor to continue operating under the user's identity even after the password changes. Closing the alert immediately also prevents the SOC from completing a proper investigation, such as checking for other affected accounts or indicators of compromise, and fails to escalate the incident for further review.

Reimage the user’s laptop immediately to remove any possible malware before taking other steps.

Why it fails: Reimaging the laptop assumes the attack originated from malware on the endpoint, but the alert pattern of repeated failed logins followed by a successful one from a foreign IP indicates compromised credentials rather than a local infection. An immediate reimage is a destructive response that will erase volatile evidence such as active network connections, temporary files, and memory artifacts that could confirm how the account was abused. It also does not remediate the compromised identity itself, so the attacker could still authenticate from another device unless the account is disabled and sessions are revoked first.

Isolation: Removing malicious files from the system.

Why it fails: Removing malicious files is an eradication activity, not isolation. Isolation focuses on containment—cutting off the system's access to the network and other resources—whereas eradication involves actively deleting malware, disabling adversary accounts, and patching vulnerabilities. While isolation may prepare a system for eradication, the action of file removal itself is part of the remediation phase and does not address the immediate goal of preventing spread.

Volatile Data Capture: Creating a forensic copy of the hard drive.

Why it fails: Creating a forensic copy of the hard drive is the definition of disk imaging, not volatile data capture. Volatile data capture specifically targets transient data stored in memory (RAM), like running processes and network sessions, which disappears upon power-off. Imaging preserves the non-volatile data on persistent storage and does not capture the live system state, making it a separate and complementary step in the forensic process.

Run a comprehensive antivirus scan on the server.

Why it fails: A comprehensive antivirus scan is a detection and eradication activity, not a containment measure. During the scan, the server remains connected to the network, so the data exfiltration continues unabated, and the scan's intensive I/O activity may trigger malware countermeasures that destroy volatile evidence. Prioritizing the scan over containment delays the critical action of stopping the breach and may alert the attacker, worsening the incident.

Notify the Chief Information Security Officer (CISO) of the incident.

Why it fails: Notifying the CISO is a required step in incident response, but it does not stop the active data exfiltration. The immediate priority per NIST is containment to minimize the impact of the incident; every moment spent on reporting before isolating the server allows the attacker to transfer more sensitive financial data. Notification should occur concurrently with or immediately after the containment action, not as a substitute for isolating the server at the switch level.

Power off the server to prevent further damage.

Why it fails: Powering off the server would prevent further file-level damage, but it is an overly aggressive action that sacrifices volatile forensic data. Memory contents, active network connections, running malicious processes, and unencrypted data in RAM are all lost on shutdown, severely hampering the investigation. In a financial incident, you should use logical network isolation at the switch first to contain the threat while preserving the system state, unless there is an immediate physical safety hazard.

Immediately disable the account and wait for the employee to return.

Why it fails: This is premature containment, not triage. Disabling the account without first validating the alert—such as correlating the sign-in IP, device, and time with the user's normal behavior—may block a legitimate session and cause business disruption. It also violates standard incident response phases (identification before containment), and prevents you from gathering additional log evidence or interviewing the user while the context is still fresh.

Close the alert as a false positive because the user is on vacation.

Why it fails: Vacation status alone does not validate the sign-in; it only indicates the legitimate user is not physically at work. An attacker who has obtained the user's credentials through phishing or credential stuffing can sign in from anywhere, and the alert may reflect that malicious activity. You must review the authentication logs for anomalies like impossible travel, impossible login times, or unusual ASN/IP reputation before dismissing it.

Reimage the user’s workstation before checking any logs.

Why it fails: Reimaging is a final remediation step, not a first triage action, and it destroys volatile and forensic evidence on the endpoint—including Prefetch files, $UsnJrnl records, browser cache, and memory artifacts—that could reveal the attack vector and scope. Additionally, if the sign-in came from a compromised token, stolen credentials via a VPN, or another endpoint, reimaging the local workstation does not address the root cause and could give a false sense of security.

Begin the eradication phase by immediately reimaging the workstation.

Why it fails: Reimaging the workstation is an eradication and recovery activity that must not be performed before containment because it destroys all local evidence, including the initial infection vector and any attacker-created artifacts. It also fails to address other systems on the network that may already be compromised, allowing the threat to persist and spread while you rebuild this one host. Moreover, aggressive recovery steps should be deferred until law enforcement or incident responders have had the opportunity to collect forensic data, so early reimaging is both technically and procedurally inappropriate.

Conduct a full forensic analysis of the workstation's hard drive.

Why it fails: A full forensic analysis of the hard drive is an evidence-collection and investigation step that should occur only after the workstation has been isolated from the network. Before containment, the attacker can continue exfiltrating data or issuing commands while you spend hours imaging the disk, and a dead-box analysis of storage alone will miss volatile memory and active network connections. Proper forensic procedure follows the order of volatility, which means capturing memory and network state first, but those steps also assume the host is already under your control rather than still communicating with an adversary.

Update the firewall rule to block all outbound traffic to the malicious IP.

Why it fails: While updating a firewall rule can help block further connections to the malicious IP, it does not address the already compromised workstation, which may still be able to use other protocols or paths to communicate out. Isolating the workstation is more immediate and comprehensive.

Pen test report: Independent evidence that a SaaS provider's controls operated effectively during the last year.

Why it fails: A penetration test report is wrong as evidence of controls operating effectively during the last year because it is a point-in-time assessment of a defined scope (e.g., network, web app) at a specific moment. A pen test evaluates exploitable vulnerabilities and demonstrates a security weakness or its absence, but it does not test the consistent operation of processes like access reviewing, patching, or monitoring. To prove controls worked continuously over 12 months, you need a SOC 2 Type II (or similar) attestation, not a single pentest snapshot.

BCP: A signed agreement that defines how customer data is handled and what the vendor must do if an incident occurs.

Why it fails: A Business Continuity Plan (BCP) is an internal operational document that outlines how an organization will continue or restore critical business functions during a disruption, such as a natural disaster or cyberattack. It does not contain agreed terms for handling customer data or contractual incident-notification obligations between vendor and client; those conditions live in a Data Processing Agreement (DPA). Confusing the two is dangerous because a BCP lacks force of law, while a DPA creates enforceable responsibilities for data handling and breach response.

Return the workstation to the user since the outbound connection was blocked.

Why it fails: Blocking one outbound connection does not remove persistence or confirm the system is clean. The exhibit shows script-based activity and a scheduled task, both of which can remain active even after network containment. Returning the device now would risk reinfection or continued compromise.

Delete only the scheduled task and reconnect the host to monitor for more alerts.

Why it fails: Removing one artifact is too narrow when the evidence suggests a broader compromise. The PowerShell payload created a script file and a scheduled task, so there may be additional persistence, credential theft, or payload changes. Reconnecting the host early increases the chance of further impact.

Close the incident because memory capture has already preserved the evidence.

Why it fails: Preserving evidence is only one step in the process. The team still needs eradication and recovery actions before the incident can be closed. The host remains compromised until the malicious code and persistence mechanisms are removed and exposed credentials are addressed.

Run a full antivirus scan on the workstation

Why it fails: Running a full antivirus scan is not a containment action; it only inspects files already on disk and does nothing to interrupt the live network connection that is exfiltrating data. Modern malware can evade signature-based scanners, especially if it is polymorphic or zero-day, so the scan may come back clean even while the machine remains compromised. Furthermore, the scan itself consumes significant CPU and I/O resources, and every minute spent scanning allows the attacker to continue sending sensitive data to the remote host. The correct sequence is to isolate the host first, then run the scan as part of the eradication phase.

Notify the user that their workstation may be compromised

Why it fails: Notifying the user before containment is risky because it can alert an insider who is complicit, or cause an innocent user to log out, close programs, or reboot the machine, which may destroy volatile memory evidence that would be critical for later forensic analysis. It also adds a human interaction delay to a technically urgent situation, leaving the malicious outbound connection active. Incident response policies typically require the analyst to contain the threat first and inform the user after the network connection has been severed, ideally through the proper management channel to avoid compromising the investigation.

Check the firewall logs to confirm the destination IP

Why it fails: Checking the firewall logs to confirm the destination IP is a legitimate investigative step, but performing it before containment leaves the workstation actively communicating with the attacker, so the ongoing exfiltration continues while the analyst works. Log analysis takes time and may not reveal the full context of what the malicious process is sending; it only tells you the destination, not the content. Additionally, the attacker may be actively monitoring the session and could take countermeasures such as deleting logs or escalating privileges on other machines. Containment should always precede detailed log review; once the host is isolated, the analyst can safely examine logs without the clock ticking on data loss.

Delete the suspicious PowerShell process from the console and close the alert.

Why it fails: Terminating the PowerShell process from the EDR console may stop the current execution, but it does not remove any fileless payloads, scheduled tasks, WMI event subscriptions, or registry Run keys the script may have created. With the alert closed and no isolation in place, the endpoint remains on the network, allowing any residual malware to continue beaconing or move laterally. This action also discards the live process memory that could reveal the encoded script's decrypted form, so it destroys volatile evidence without achieving containment.

Reimage the workstation immediately to return it to a clean state.

Why it fails: Reimaging the workstation immediately is a destructive recovery step that wipes the disk and, in effect, destroys the very artifacts needed to determine the root cause, scope, and indicators of compromise. While a clean build may be the eventual remediation, doing it before isolating and collecting forensic data can obscure whether the infection spread to other systems or originated from a network share. It also eliminates the opportunity to validate whether the EDR alert was a true positive versus a false positive, making containment decisions based on incomplete information.

Power the workstation off and disconnect the SSD to preserve data.

Why it fails: Powering off the workstation and disconnecting the SSD preserves the disk state but sacrifices the contents of RAM, which may contain the encoded script's decrypted payload, injected shellcode, active network connections, and encryption keys if full-disk encryption is in use. This volatile data is often the only source to confirm the attacker's technique and intent, and a hard shutdown prevents live triage of running processes. EDR-based isolation is preferable because it severs the network path while keeping the host powered, so first responders can acquire memory and conduct a live analysis before deciding on any hardware changes.

Run a full antivirus scan on the workstation.

Why it fails: While scanning may be part of the investigation, it is not the first priority. The system is actively communicating with a C2 server, and delaying containment could allow data theft or additional compromise. Containment should come before remediation.

Review firewall logs to see if the traffic is being blocked.

Why it fails: Reviewing firewall logs is a passive, investigative step that does not interrupt the ongoing communication with the C2 server. The analyst already knows the traffic is malicious from the intrusion alert, so the priority is to contain the live threat before collecting logs; delaying action allows the attacker to continue issuing commands and potentially encrypt or steal data. Log analysis should follow containment, not precede it.

Inform the user to shut down the workstation.

Why it fails: Telling the user to shut down the workstation would stop the network traffic, but it does so at the cost of destroying volatile forensic evidence, including running processes, open sockets, and memory artifacts, making root-cause analysis difficult. Additionally, instructing a non-technical user introduces delay and the risk of improper handling, whereas the analyst can perform a controlled network isolation that halts the C2 traffic while preserving the system state for later evidence collection.

Immediately delete the account to stop any further access attempts.

Why it fails: Deleting a user account is an irreversible administrative action that destroys the user's mapped access rights, group memberships, and associated ACLs; it also severs any attribution chain needed for forensic investigation. At triage stage, the analyst lacks evidence that the account is truly compromised rather than a misconfigured MFA or a scripted logon. Deleting also interrupts legitimate business operations and can trigger data recovery and identity restoration efforts. The correct immediate step is to gather more context, not to destroy the identity asset.

Assume the account is compromised and notify all users to change their passwords.

Why it fails: Assuming compromise and forcing a company-wide password reset is a classic over-reaction to a single account's anomaly. The event is localized to one finance user, so a mass reset creates broad operational friction and password fatigue without addressing the actual source IP or authentication behavior. Worse, it may tip off an actual attacker and cause them to change tactics before the analyst has correlated logs. Triage requires evidence-based scoping: first confirm whether the failed attempts came from a known baseline, an internal service account, or a legitimate remote user with a stale VPN session.

Close the alert because one successful login means the activity was normal.

Why it fails: A single successful login does not validate the preceding 38 failures as normal; in a brute-force or credential-stuffing attack, the one success is precisely the final event. Attackers often use distributed source IPs and timing offsets to evade simple lockout policies, so the analyst must inspect sign-in timestamps, federated identity provider events, and the user's historical geographic pattern. Closing the alert based on a single success ignores the possibility of account takeover that will be followed by data exfiltration. The alert requires correlation with anti-malware, EDR, or cloud identity analytics to determine if post-authentication behavior is anomalous.

Uninstall the word processor from every workstation.

Why it fails: Uninstalling the word processor from every workstation is a broad, irreversible change-management action that does not interrupt the already-running encoded PowerShell process or terminate the established outbound connection to the suspicious domain. It also alters the system state and may destroy volatile forensic evidence needed for attribution. Proper containment isolates the specific compromised endpoint first, preventing lateral movement while preserving the integrity of the investigation.

Wait to see whether more alerts appear before responding.

Why it fails: Waiting is contrary to the containment phase of incident response. The combination of encoded PowerShell and communication with a rare external domain is a strong indicator of active compromise; delay allows the adversary to complete reconnaissance, move laterally via SMB or PsExec, or exfiltrate data. The existing EDR alert is already sufficient to trigger a hold-and-contain action, and additional telemetry can be collected after network isolation without risking further spread.

Send a notice to all users reminding them not to open attachments.

Why it fails: A mass email reminder to users is a security-awareness action that addresses potential future behavior but does nothing to halt the active malicious process on the compromised host. The endpoint is already infected, and the attacker's beacon will continue to receive commands, allowing the host to be used as a pivot for lateral movement. Operational containment through EDR network isolation must take precedence; user education is a complementary post-incident activity, not a first-response measure.

Security Information and Event Management (SIEM)

Why it fails: A SIEM excels at centralizing log collection and generating security alerts through correlation rules, but it does not natively execute response actions against those findings. Analysts must still investigate the raw logs, manually validate threats, and carry out containment or remediation steps through separate tools. While a SIEM can feed data into another automation layer, its core function remains visibility and detection, not autonomous response, so it would not alleviate the analyst's manual workload.

Endpoint Detection and Response (EDR)

Why it fails: Endpoint Detection and Response (EDR) tools monitor host-level activity and can automate certain response actions like quarantining a file or isolating an endpoint from the network. However, these automated responses are confined to endpoint processes, lacking the broader orchestration across identity, network, cloud, and other security controls that the scenario demands. EDR is a component within a response ecosystem, not a platform that coordinates and automates an entire multi-tool incident response workflow.

Cloud Access Security Broker (CASB)

Why it fails: A Cloud Access Security Broker (CASB) enforces policies for sanctioned cloud applications, such as access controls, data loss prevention, and shadow IT discovery, by sitting between users and cloud providers. Its automation features are tailored to cloud-specific policy enforcement—not to orchestrating enterprise-wide incident response actions across networks, endpoints, and other infrastructure. Because the analyst's overload concerns general security monitoring and response, a CASB addresses a narrow cloud governance niche rather than the broader automation gap.

Host-based antivirus on each virtual machine.

Why it fails: Host-based antivirus (AV) on each VM detects and remediates malware within the guest OS by scanning file signatures and monitoring process behavior, but it has no visibility into the cloud provider's control plane. It cannot record management actions such as VM power-state changes, security-group modifications, or IAM role updates, because those events occur in the cloud API layer outside the guest. Therefore, AV is a data-plane safeguard and does not satisfy the requirement for an administrative audit trail.

A guest operating system screen saver policy.

Why it fails: A guest OS screen saver policy—such as locking the console after a timeout—is a local endpoint control designed to prevent unauthorized interactive access to the VM's desktop. It does not generate logs of cloud management operations like instance launches, VPC peering, or identity policy changes, and it operates entirely within the guest session. Since the team's objective is to track who performed cloud-level changes, this policy provides no relevant audit data and cannot support security investigations.

A static public IP address for every virtual machine.

Why it fails: Assigning a static public IP address to every VM gives each instance a fixed, externally reachable address, but it creates no record of administrative actions or configuration changes. It also enlarges the attack surface by ensuring the VMs remain continuously exposed to the internet, which may require additional perimeter controls. Static IPs are a network addressing choice, not a logging mechanism, and thus they fail to provide the required visibility into management-plane activity.

Buy the gift cards immediately so the CEO is not delayed.

Why it fails: Acting on the email's urgency is exactly the psychological trigger used in gift card and Business Email Compromise scams; the attacker relies on the employee skipping verification to avoid 'delaying' the CEO. Even if the display name and signature match, the message can be spoofed or originate from a compromised account, so purchasing cards immediately converts untraceable funds to the attacker. Legitimate executives rarely demand urgent gift card purchases via email, and most organizations' policies require confirming financial requests through a known, separate channel, making this action both financially and procedurally dangerous.

Forward the email to coworkers so they can watch for the same request.

Why it fails: Broadly forwarding the email to coworkers exposes them to the same malicious links, attachments, or reply-to addresses and may spread phishing lures beyond the intended target. It also contaminates the incident response picture: security teams need original headers and metadata to trace spoofing, but forwarding strips or alters that evidence and can generate a second wave of requests from confused users. Instead of acting as an ad hoc distribution list, the employee should report the message through the approved security channel so the SOC can analyze it and alert the organization safely.

Reply to the sender and ask for more details in the same email thread.

Why it fails: Replying in the same email thread is not a valid verification because the attacker may control the 'CEO's' mailbox, or a spoofed domain can make the response appear to come from inside the organization. This interaction confirms that the address is active and can prompt the attacker to double down or send follow-up phishing attempts, and it bypasses the organization's detection controls because the exchange remains hidden from security monitoring. Only out-of-band contact—such as calling the CEO on a previously known number or using an authenticated collaboration tool—can establish whether the request is real.

Restart sshd and monitor the system for another login attempt.

Why it fails: Restarting sshd only restarts the SSH daemon process; it does not clean the malicious script, remove the cron persistence, or undo the SSH configuration changes (e.g., added authorized_keys entries or altered sshd_config). Monitoring alone cannot remediate an active compromise; the attacker retains persistence and remote access. This action is reactive, not an eradication step.

Manually delete the cron entry and reverse the SSH change on the live server.

Why it fails: Manually editing a live compromised host is risky because attackers often plant multiple backdoors, tamper with system binaries (e.g., sshd, ps, netstat) to hide their presence, and maintain alternate persistence mechanisms. Removing only the visible cron entry and SSH setting leaves the system in an untrusted state, and touching the filesystem may destroy volatile evidence needed to fully understand the attack. In incident response, eradication must follow evidence collection and proceed from a trusted baseline, not ad-hoc on a potentially rootkitted system.

Increase the SIEM retention period and keep the current server online.

Why it fails: Extending SIEM retention provides future log data but does nothing to eliminate the attacker's existing persistence or restore the integrity of the compromised host. Keeping the server online allows the adversary to continue exploiting the system, move laterally, or exfiltrate data. The only reliable way to restore trust is to rebuild the host, so this is not an eradication action.

Wait for more alerts before taking any action to avoid disrupting the user

Why it fails: Adopting a passive wait-and-see posture is dangerous because the EDR alert already indicates a potential compromise. Each minute the workstation remains on the network allows an adversary to install persistence, move laterally, or exfiltrate sensitive data. Incident response principles require immediate containment upon a validated alert, not waiting for more alerts, which would only expand the scope of the incident and increase remediation costs.

Immediately reinstall the operating system without collecting evidence

Why it fails: Reinstalling the OS without collecting forensic evidence destroys the very artifacts needed to determine the root cause and scope of the intrusion. Memory dumps, disk images, logs, and prefetch files may reveal the initial access vector, attacker tools, and lateral movement techniques. Early reimaging also fails to address threats like firmware implants that survive reinstallation, and it forfeits the opportunity for intelligence to improve defenses and prevent future incidents.

Disable the user's account in the directory service and close the ticket

Why it fails: Disabling the user account in the directory service only prevents future interactive logons but has no effect on a malicious process already running under that user's context. It does not terminate the process, block the host's network communications, or remove persistence mechanisms, so the compromise remains active. Closing the ticket prematurely also ignores the need for endpoint containment and forensic investigation, leaving other systems at risk.

Increase the backup schedule from nightly to hourly.

Why it fails: Increasing backup frequency from nightly to hourly improves recovery point objectives, reducing data loss in a disaster or ransomware event. However, backups operate in the background and simply copy data to secondary storage; they provide no analysis of access patterns. Suspicious bulk reads by a valid account would still go unnoticed because the control does not generate security alerts or audit events.

Rename the share to a less obvious name.

Why it fails: Renaming the share to something less obvious is a form of security through obscurity. It might reduce casual discovery, but it does not authenticate, authorize, or monitor access, and it will not stop an attacker who enumerates network shares or already possesses valid credentials. Moreover, it produces no audit trail, so abnormal usage cannot be detected or investigated.

Disable SMB signing so the file transfer runs faster.

Why it fails: Disabling SMB signing to improve transfer speed removes integrity and authenticity protections from SMB sessions, exposing traffic to potential tampering or man-in-the-middle attacks. While the performance gain may be real, this change is a security regression and has no relationship to detecting bulk reads. It would not flag abnormal file access; in fact, it could make exfiltration easier for an attacker.

Reboot immediately to prevent any further damage from the suspected malware.

Why it fails: Rebooting the system prematurely is a common but destructive reaction: it clears RAM, kills active processes, and resets kernel objects, which can destroy the only copies of malware payloads, in-memory encryption keys, or command-and-control channel state. Volatile data such as the ARP cache, active TCP connections, and process arguments exist only in memory and vanish instantly with a restart. Instead of containing the threat, a reboot gives persistent malware a fresh start to hide or escalate, and it forfeits the primary evidence needed to determine the infection's origin and scope.

Copy suspicious files to a shared drive and continue normal operations.

Why it fails: Copying suspicious files to a shared drive contaminates the evidence chain by changing file system metadata (creation, modified, and access timestamps) and may inadvertently spread the infection if the share is reachable by other hosts. This approach also keeps the affected system running, allowing malware to continue network communication, credential theft, or lateral movement while the analyst works. A proper response requires a forensically sound bit-for-bit image to an isolated storage device, preserving metadata and avoiding network exposure.

Run a full disk cleanup to remove temporary files and reduce risk.

Why it fails: Running a full disk cleanup on a potentially compromised finance workstation is an anti-forensic act: it deliberately deletes temporary folders, prefetch files, browser caches, and thumbnails that frequently contain the initial infection vector, attacker tooling, or signs of data staging. Utilities like Disk Cleanup also perform write operations across the filesystem, altering modification times and overwriting unallocated space where deleted artifacts may reside. This destroys the very remnants that a malware investigation depends on to establish a timeline, identify the malware, and recover stolen data.

Shut down the server immediately to stop all malicious activity

Why it fails: Shutting down the server immediately stops the visible malicious activity but discards volatile evidence from memory, such as encryption keys, running malware processes, and open network connections. A hard power-off may also corrupt the file system and trigger self-protection mechanisms that destroy more artifacts. Incident response favors isolation over shutdown because a live system allows forensic imaging and analysis that can identify the ransomware strain and support decryption—critical for minimizing data loss.

Restore the server from backup before taking any other action

Why it fails: Restoring from backup before containing the threat leaves the root cause active; the malware or attacker will simply re-encrypt restored files, and the process may overwrite the very evidence needed to identify the entry vector. Early restoration can also use a backup that itself is compromised, reintroducing the infection. Proper order is to isolate the server first, then collect forensics, and only then restore from clean backups after confirming the source is neutralized.

Wait for users to report more symptoms before responding

Why it fails: Waiting for user reports sacrifices the golden hours of containment, allowing ransomware to spread across the network, encrypt additional shares, and reach backup systems. Attackers move quickly and lateral movement may be silent; by the time users notice, the blast radius has expanded exponentially. Incident response requires proactive monitoring and immediate alert triage—not passive observation—to contain the threat while it is still localized.