Incident Response and Management practice questions

DDoS

Why it fails: DDoS targets network resources, not user accounts.

Ransomware

Why it fails: Ransomware typically involves encryption and ransom notes, not just lockouts.

Phishing

Why it fails: Phishing involves deceptive emails, not account lockouts directly.

Disk storage

Why it fails: Disk storage is non-volatile: data persists across reboots and power loss, placing it last in the order of volatility. It is tempting because disks hold the bulk of forensic evidence, but that abundance does not make them volatile; RAM and cache must be captured first.

Swap space

Why it fails: Swap space holds data paged out of memory, so it persists on disk and survives reboots, placing it below RAM and cache in volatility. It is tempting because swap contents can reveal credentials and process remnants, but that evidentiary value does not make it the most volatile source.

RAM

Why it fails: RAM is volatile but less than CPU registers.

Isolate the infected systems from the network

Why it fails: 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 it fails: 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.

avml

Why it fails: AVML (Acquire Volatile Memory for Linux) is also a Linux memory acquisition tool, but LiME is more established and commonly referenced in CySA+.

WinPmem

Why it fails: WinPmem is for Windows systems.

FTK Imager

Why it fails: FTK Imager is for disk imaging.

Delete old logs to free space for new logs

Why it fails: Deleting historical log data directly violates the core forensic principle of evidence preservation. Removing older logs destroys the historical context and timeline necessary to determine the initial entry point or lateral movement of an attacker. Analysts must always preserve existing data and expand storage capacity rather than purging potential evidence.

Perform a packet capture (pcap) and store it on write-protected media

Why it fails: Capturing raw network packets provides an immutable, detailed record of the network traffic associated with the breach. Storing this packet capture (pcap) on write-protected or write-once-read-many (WORM) media ensures the integrity of the evidence by preventing accidental alteration or malicious tampering. This establishes a verifiable chain of custody suitable for legal proceedings and deep forensic analysis.

Copy the log files to a USB drive and analyze them

Why it fails: Copying files directly to a standard USB drive without using a hardware write-blocker can alter critical file system metadata, such as last-accessed timestamps. Furthermore, analyzing evidence directly on a writable destination drive risks accidental modification or contamination of the data. Forensic best practices dictate creating a bit-stream image of the media and working only on a verified copy.

Isolate the affected network segment

Why it fails: 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 it fails: 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 it fails: 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.

Malware

Why it fails: While malware represents malicious code designed to compromise system confidentiality, integrity, or availability, it is a tool or vector rather than the threat actor category itself. In this scenario, the primary focus is on the human actor initiating the unauthorized activity from within the organization, making malware an incorrect classification for the source of the threat.

Data breach

Why it fails: A data breach is an incident outcome where sensitive, protected, or confidential data is copied, transmitted, viewed, or stolen by an unauthorized individual. Although an insider threat can certainly cause a data breach, the term describes the consequence of the security failure rather than the specific classification of the threat actor responsible for the action.

Ransomware

Why it fails: Ransomware is a specific subcategory of malware designed to encrypt files on a system, rendering them unusable until a ransom is paid to the attacker. This term describes a technical payload and extortion methodology, which does not align with a scenario focused on classifying the internal human actor who initiated the unauthorized behavior.

Block the source IPs on the firewall.

Why it fails: While blocking source IPs on a local firewall is a standard response for targeted attacks, it is highly ineffective against large-scale DDoS attacks. The sheer volume of distributed source IPs will quickly exhaust the firewall's state table and processing memory. Furthermore, this approach does not prevent the incoming traffic from saturating the organization's internet bandwidth before it even reaches the firewall.

Increase server bandwidth to absorb the traffic.

Why it fails: Increasing server bandwidth is a reactive, costly, and unsustainable measure that fails to address the root cause of a volumetric DDoS attack. Attackers can easily scale their botnets to generate traffic volumes that far exceed any temporary bandwidth upgrades. Additionally, this approach does not protect upstream network infrastructure or application-layer resources from being overwhelmed.

Deploy additional load balancers.

Why it fails: Deploying additional load balancers can help distribute legitimate application-layer traffic across multiple backend servers, but it cannot mitigate a massive volumetric network-layer DDoS attack. The incoming flood of traffic will still saturate the external network link and can easily overwhelm the load balancers themselves. Without upstream filtering, adding more load balancers merely shifts the bottleneck without resolving the resource exhaustion.

avml

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

WinPmem

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

dd

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

The file has a suspicious import table

Why it fails: A suspicious import table is a static indicator, not a behavior observed during malware execution.

The file's PE header indicates it is packed

Why it fails: A packed PE header is a static indication of obfuscation, not a runtime behavior.

The file creates a scheduled task

Why it fails: Creating a scheduled task is a host-based indicator, not a behavioral IOC in the dynamic analysis sense, which emphasizes network activity.

Imaging the suspect's hard drive using dd without a write blocker

Why it fails: Utilizing the dd utility directly on a source drive without a hardware or software write blocker risks modifying metadata, such as access times, or allowing the operating system to write temporary files to the evidence medium. This alters the original state of the digital evidence, compromising its integrity and potentially rendering it inadmissible in a court of law.

Rebooting the suspect's computer to ensure no hidden processes are running

Why it fails: Rebooting the target system immediately destroys highly volatile data stored in RAM, such as active network connections, running processes, uncommitted logs, and cryptographic keys. In digital forensics, the order of volatility dictates that memory must be captured before any state changes, making a reboot a destructive action that permanently erases critical evidence.

Deleting suspicious files to prevent further damage

Why it fails: Deleting files prematurely destroys vital evidence, including file metadata, timestamps, and the actual payloads needed for root-cause analysis and attribution. Containment actions, such as isolating the host from the network, must be executed in a manner that preserves the system state rather than destroying data that could help identify the scope of the insider threat.

The file size of the malware sample

Why it fails: File size is not a reliable indicator because polymorphic malware, packing, or compilation variations can alter size without changing functionality. YARA rules can technically match on file size using the `filesize` keyword, but it is a weak, non-specific characteristic that produces false positives and cannot uniquely identify a malware family. An incident responder would use size only as a rough filter, not as a primary identification rule.

Behavior observed in a sandbox, such as registry changes

Why it fails: YARA is a static analysis tool; it inspects raw bytes of files, not runtime behavior. Behavioral indicators like registry modifications are captured via dynamic analysis (e.g., sandbox reports, EDR telemetry) and are not part of YARA's rule language. While YARA can match strings that appear in memory dumps, it does not directly observe or correlate system-level actions like registry changes.

The domain name of the remote server

Why it fails: While a domain name observed during dynamic analysis can be an immediate indicator, it is often a weak long-term Indicator of Compromise (IOC). Malware frequently utilizes Domain Generation Algorithms (DGAs) or legitimate compromised domains that are quickly taken down or rotated. This ephemeral nature means detection rules based solely on specific domain names quickly become outdated and ineffective against evolving threats or new variants.

The hash of the initial malware sample

Why it fails: The hash of an initial malware sample is a static indicator that is easily defeated by polymorphic or metamorphic malware. Even minor changes to the file, such as recompilation or packing, will result in a completely different hash. Consequently, relying on a specific file hash for detection is unreliable for identifying new variants or for long-term threat intelligence, as it lacks behavioral context.

The IP address of the remote server

Why it fails: An IP address observed during dynamic analysis is generally a volatile indicator of compromise. Command and Control (C2) servers frequently rotate IP addresses, utilize fast-flux networks, or leverage cloud services that dynamically assign IPs. This makes IP-based detection rules prone to rapid obsolescence and high false positives, as the same IP might be reassigned to legitimate services or the C2 infrastructure shifts.

Rebuild the email server from backup.

Why it fails: Rebuilding the email server from backup is a recovery action, not a containment one, and it destroys the very volatile evidence needed to investigate the breach. Backups may also be compromised or may not include the attack artifacts, and the process does not revoke the attacker's access if other credentials or persistence mechanisms remain. This step should be deferred until forensic evidence is collected and containment is achieved.

Notify all customers immediately.

Why it fails: Notifying all customers immediately is a post-incident step governed by breach notification regulations and public relations considerations, not a containment action. Doing so before confirming the scope of the breach can lead to legal penalties and unnecessary panic, and it does nothing to stop the attacker's activity. Notification should occur after the incident is contained and a thorough analysis has been completed.

Apply all available patches to the email server.

Why it fails: Applying patches to the email server addresses the underlying vulnerability but does not disconnect an active attacker who already has access. Patching often requires a reboot, which would wipe volatile memory and destroy forensic evidence, and it may tip off the attacker that they have been discovered. This is a long-term remediation measure that belongs after data collection and containment, not before.

Reset the user's password and require a change at next logon.

Why it fails: Resetting the password may lock out the attacker, but if the account is not disabled, the attacker could still use existing sessions or tokens. Password reset alone does not terminate active sessions. It also may alert the attacker if they are monitoring. Disabling the account is a stronger containment measure. Resetting the password is more appropriate during eradication after containment.

Delete the user's mailbox to prevent further data theft.

Why it fails: Deleting the mailbox destroys evidence and may violate legal hold requirements. It also does not contain the incident because the attacker could have already exfiltrated data. Mailbox deletion is a destructive action that should never be taken during incident response without proper authorization and evidence preservation. It would hinder the investigation and potentially lead to spoliation of evidence.

Immediately terminate all active sessions for the user.

Why it fails: Terminating active sessions is a good containment step, but it is not one of the two best actions here because it may not be sufficient if the account remains enabled. The attacker could simply re-authenticate. Disabling the account is more comprehensive. While session termination is useful, it is secondary to disabling the account and capturing memory. It also may not cover all session types, such as API tokens.

Search for the IP address on VirusTotal and Shodan.

Why it fails: VirusTotal and Shodan are external reputation lookups; they cannot confirm whether this internal host actually communicated with the address, nor reveal the internal context (process, user, payload) that SIEM correlation, endpoint telemetry and log analysis provide. Reputation checks suit proactive threat intelligence enrichment, not validating a live internal alert.

Escalate the alert to the incident response team for containment.

Why it fails: Escalation for containment jumps ahead of validation; NIST SP 800-61 requires analysis to confirm the alert before response actions. Escalating to the incident response team is correct after triage confirms a genuine incident requiring coordinated handling, not while the alert remains unverified.

Contain the host immediately by disconnecting it from the network.

Why it fails: Containment belongs to the containment, eradication and recovery phase; isolating during detection and analysis destroys volatile evidence and may tip off an attacker. Immediate disconnection is correct once an incident is confirmed and active exfiltration or lateral movement is underway.

Reboot the server to clear the ransomware from memory.

Why it fails: Rebooting a compromised system destroys critical volatile evidence stored in RAM, such as encryption keys, active network connections, and running malware processes. Furthermore, many modern ransomware strains configure themselves to persist across reboots, meaning the system may resume encryption immediately upon startup, potentially with elevated privileges or in safe mode.

Kill the ransomware process using task manager.

Why it fails: Attempting to manually terminate the ransomware process via Task Manager is highly unreliable because sophisticated malware often employs watchdog processes that immediately restart the malicious thread. Additionally, some ransomware variants are designed with anti-tampering mechanisms that trigger immediate, destructive payloads or mass file deletion if their primary process is abruptly terminated.

Create a full disk image of the server before any action.

Why it fails: While acquiring a forensic disk image is a critical step in the preservation phase of incident response, performing it before containment allows the active ransomware to continue encrypting files and spreading across the network. Because disk imaging is a time-consuming process that can take hours, containment must always take priority over evidence collection to minimize ongoing operational damage.

Disk → RAM → Swap → CPU registers → Network connections → Archived media

Why it fails: Incorrect: Starts with disk, which is persistent and least volatile among the early items. Volatile data like RAM and CPU registers should be captured first.

Network connections → CPU registers → RAM → Swap → Disk → Archived media

Why it fails: Incorrect: Network connections are placed first, but they are less volatile than RAM and CPU registers. The sequence should start with memory.

CPU registers → RAM → Swap → Disk → Network connections → Archived media

Why it fails: Incorrect: While CPU registers and RAM are correctly first, network connections are placed after disk, which violates the order of volatility because network connections are more volatile than disk.

The creation timestamp of the file

Why it fails: File creation timestamps are highly unreliable indicators of compromise because adversaries can easily manipulate them using "timestomping" techniques to match legitimate system files. Relying on metadata like MACB (Modified, Accessed, Created, Born) timestamps in YARA rules would result in fragile signatures that fail to detect modified or newly compiled variants of the malware.

The file size of the executable

Why it fails: Executable file size is an ineffective metric for YARA rule creation because minor code modifications, compiler optimizations, or the addition of padding bytes can drastically alter the file size without changing the malware's core functionality. Writing rules based on specific byte counts or file sizes will lead to high false-negative rates when encountering polymorphic variants.

The packer used to obfuscate the executable

Why it fails: While identifying a packer like UPX or Themida can indicate obfuscation, writing YARA rules targeting the packer itself is problematic because legitimate software developers also use packers to protect intellectual property. Furthermore, malware authors can easily switch packers or use custom crypters, rendering packer-based signatures obsolete and prone to high false-positive rates on benign packed binaries.

The network connection over port 443

Why it fails: Outbound port 443 traffic indicates command-and-control or exfiltration, not persistence; it dies when the host reboots. It is tempting because beaconing to a remote IP is a classic network IOC, and it would be the right answer if the question asked which indicator reveals active communication with attacker infrastructure.

The remote IP address

Why it fails: A remote IP address identifies attacker infrastructure for blocking or hunting, but it grants no survival mechanism across reboots. It is tempting because IPs are easily actioned as firewall blocks, and it would be correct if the question asked which IOC enables immediate network containment of the campaign.

The dropped DLL file hash

Why it fails: A file hash identifies one specific DLL sample and changes with any recompilation, so it cannot indicate persistence behaviour. It is tempting because dropped artefacts are tangible evidence, but the Run registry key is the mechanism that executes the malware at logon, making that registry modification the persistence IOC.