Incident Response practice questions

Treat the alert as a confirmed breach and begin password resets for all portal users.

Why wrong: The source and request pattern indicate authorized testing, not evidence of an actual breach.

Block the scanner IP permanently to prevent future alerts from the same host.

Why wrong: Blocking an approved scanner can break vulnerability management and does not solve the validation problem.

Quarantine the reporting server because IDS alerts always indicate active exploitation.

Why wrong: IDS alerts require context; many are benign tests, misconfigurations, or known maintenance activities.

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

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

Block the IP address at the firewall immediately.

Why wrong: Blocking the IP address may be premature without first escalating the incident and obtaining authorization. It could also be an attacker using a VPN or a spoofed address, and the IP might be shared by legitimate users.

Disable all user accounts that were targeted.

Why wrong: Disabling accounts without investigation could lock out legitimate users and might not be the most effective response. The incident response team needs to assess the situation before taking such disruptive action.

Capture a memory dump of all affected servers.

Why wrong: Capturing memory dumps is a forensic step that should occur later in the incident response process, typically after containment and with proper authorization, to preserve evidence without interfering with ongoing operations.

Isolation: Removing malicious files from the system.

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