Incident Response and Cyber Investigation practice questions

The total estimated cost of the ransom payment requested by the threat actor.

Why it fails: Ransom payment decisions are typically handled by executive leadership, legal counsel, and insurance providers rather than incident responders during containment. Responders focus on stopping the spread, and ransom negotiations are a strategic business decision that does not inform the technical containment strategy for technical infrastructure isolation.

The volatility of the data residing in the system's volatile memory (RAM).

Why it fails: While capturing RAM is important for forensic analysis, it is secondary to the immediate goal of stopping lateral movement. If the system is currently active in spreading ransomware, isolating the network path is more effective than prioritizing memory capture, which may result in further data encryption if delayed.

The availability of the most recent offline backup for the database server.

Why it fails: Backup availability is a recovery consideration rather than a containment factor. During the active phase of an incident, the priority is to halt the adversary's actions. Even if backups exist, the responder must still ensure the environment is safe before attempting a recovery process to prevent immediate re-infection.

The total volume of data in gigabytes compared to the storage capacity.

Why it fails: While data volume is important for logistical planning, it has no bearing on the integrity of the evidence. A smaller, tampered dataset is less useful than a larger, authentic one. Integrity is about the authenticity and state of the bits, not the physical size of the evidence storage.

The operating system version and kernel patch level of the source system.

Why it fails: OS versioning is useful for analysis and finding exploits, but it is not a primary factor for determining evidence integrity. While it provides context for how the system handles files, the core integrity relies on the preservation and verification methods used during the acquisition and storage process itself.

`lsof -i`

Why it fails: `lsof -i` lists open Internet files (network connections) and the processes using them. It is excellent for mapping network connections to processes, but it does not list all open files, such as regular files or directories. The scenario requires listing all open files and the processes that have them open, so this command is too narrow in scope.

`netstat -tulpn`

Why it fails: `netstat -tulpn` lists listening ports and the associated process IDs, which helps identify which processes are listening on network ports. However, it does not show open files for those processes. In this scenario, the handler needs to correlate network listeners with open files, so this command alone is insufficient, though it is a useful complementary tool.

`ps aux`

Why it fails: `ps aux` displays a snapshot of all running processes with details such as user, CPU, and memory usage. However, it does not show which files or network sockets each process has open. While useful for identifying suspicious processes, it does not provide the file-to-process mapping needed to detect a backdoor that may be listening on a port and accessing files.

The LSASS process is protected as a Process Light (PPL) and cannot be accessed even by administrators without a signed driver.

Why it fails: LSASS runs as a Protected Process Light (PPL) only when Credential Guard or other protections are enabled. By default, LSASS is not a PPL, and administrators with SeDebugPrivilege can access it. This option incorrectly assumes PPL is always active, which is not the case on a standard Windows 10 system without additional hardening.

Windows Defender Credential Guard is enabled by default on Windows 10 and blocks all attempts to read LSASS memory.

Why it fails: Credential Guard is not enabled by default on Windows 10; it must be explicitly configured and requires specific hardware and software prerequisites. Therefore, its presence is not the default state and unlikely to be the cause unless the organization has deliberately enabled it. This distractor confuses default settings with optional security features.

The attacker enabled Credential Guard, which virtualizes LSASS and prevents direct memory access by non-protected processes.

Why it fails: Credential Guard does protect LSASS by isolating secrets in a virtualized environment, but it is not enabled by default on Windows 10 and would not typically be enabled by an attacker. Moreover, if Credential Guard were active, the error would likely differ, and the handler would be aware of its configuration. This is not the most likely cause of a simple access denied error when attempting to dump LSASS.

Drafting an incident communication plan for notifying public regulatory bodies.

Why it fails: While communication plans are essential for public relations and legal compliance, they do not facilitate the technical forensic investigation. This activity falls under the 'Management' or 'Policy' preparation, not the technical preparation required to capture and analyze the digital artifacts left behind by a sophisticated cyber threat actor.

Conducting a comprehensive risk assessment of all internal business applications.

Why it fails: Risk assessments are useful for prioritizing security controls, but they do not directly assist in the forensic investigation phase. While this is good security practice, it is not a specific preparation task for ensuring that forensic evidence is preserved or analyzed correctly during a live incident response operation.

Purchasing cybersecurity insurance to cover potential ransomware payout costs.

Why it fails: Cyber insurance is a financial risk management tool, not an operational forensic preparation step. It does not help in identifying, analyzing, or preserving the digital evidence required to understand how an attack occurred. Responders need technical tools and established procedures, not insurance policies, to conduct a thorough cyber investigation.

The server is likely compromised by a kernel-mode rootkit acting as a listener.

Why it fails: PID 4 in Windows is the System process, which manages core kernel-level operations including file sharing through the SMB protocol. While rootkits can hide within the System process, seeing standard SMB connections on port 445 is insufficient evidence to conclude a rootkit infection without additional behavioral indicators of compromise.

A remote adversary is using the SMB protocol to exfiltrate data from the system.

Why it fails: While SMB can be used for exfiltration, this output alone does not indicate malicious activity. Seeing established connections to internal IPs is common in enterprise environments. The analyst must check for anomalous data volume or unauthorized user accounts before concluding that exfiltration is occurring via the file sharing service.

The system is currently scanning the network for vulnerabilities using SMB exploits.

Why it fails: The output shows connections as 'ESTABLISHED' with remote hosts, indicating the local machine is acting as a server, not a scanner. If the machine were scanning, the output would likely show a high volume of 'SYN_SENT' connections to various remote IP addresses, which is not present in this data.

The 'dd' command to copy /dev/mem directly to a remote storage server.

Why it fails: Using 'dd' on /dev/mem is unreliable on modern Linux kernels due to memory protection features and access restrictions. It often results in incomplete dumps or system crashes, making it an inferior choice compared to specialized tools designed to interact safely with the kernel to extract volatile memory contents.

The 'cat' command to pipe the contents of /proc/kcore into a file.

Why it fails: While /proc/kcore provides a view of system memory, it is not a forensically sound method for acquisition. The operating system may modify the representation of this file in real-time, and it does not capture the full state of physical memory required for a comprehensive forensic analysis of the system.

Installing a commercial agent to automate the imaging process via a GUI.

Why it fails: Installing new software during an investigation is discouraged as it alters the system state, potentially overwriting evidence. Incident responders should prefer tools that can be run from a trusted, external source or loaded via a module without leaving a significant footprint on the disk or modifying critical configuration files.

System event logs for all workstations in the local network.

Why it fails: While workstation logs are useful for internal lateral movement analysis, they are not the primary source for investigating a web-based attack. Collecting logs from every workstation is inefficient and distracts from the immediate priority of analyzing the web server and the application-layer traffic that directly correlates to the incident.

Email gateway logs showing internal-to-external communication patterns.

Why it fails: Email gateway logs are relevant for phishing investigations but are not directly related to web-based attacks. Unless the web attack was initiated via a link in an email, these logs do not provide actionable information regarding the exploitation of the web server or the application itself.

Detection and Analysis

Why it fails: The Detection and Analysis phase focuses on identifying the incident and determining its scope. The primary output here is an incident report detailing what happened and what systems were affected, rather than a strategic review of how the organization can improve its overall IR capabilities for the future.

Containment, Eradication, and Recovery

Why it fails: This phase is dedicated to stopping the attacker and restoring business functions. While responders might note operational difficulties, the formal 'lessons learned' process occurs after the recovery is complete, as it requires a comprehensive retrospective that cannot be conducted while the team is under pressure to restore services.

Preparation

Why it fails: Preparation occurs before an incident happens. While lessons learned from previous incidents are used to improve preparation, the actual creation of a lessons learned report is a concluding task for a specific incident, not a task that happens during the pre-incident preparation and planning phase of the lifecycle.

To detect unauthorized software installations performed by administrative users.

Why it fails: Administrative installations are typically performed via different processes or installers. Monitoring PowerShell child processes of a web server is not a standard way to track software installation, and this approach would likely result in an overwhelming number of false positives for legitimate automated web server management scripts.

To prevent the web server from being used as a staging ground for brute force.

Why it fails: Brute force attacks typically involve repeated authentication attempts to login endpoints, which appear as network traffic or application login failures. These attacks do not necessarily involve the IIS worker process spawning PowerShell, so this rule would be ineffective at detecting a brute force attack against a web application.

To ensure that all PowerShell scripts are signed and authorized by the organization.

Why it fails: While code signing is a valid policy, this specific rule checks for the parent process and command line arguments, not the script signature. It is a behavioral detection rule designed to catch malicious activity, not a policy enforcement rule designed to verify the digital signatures of legitimate administrative scripts.

Immediately delete the registry key to stop the persistence mechanism.

Why it fails: Deleting the key immediately destroys the forensic context, such as the path to the malicious executable, which is critical for understanding the attack's scope. Proper response requires preserving the state of the system first to allow for a full investigation before remediating the specific persistence point identified.

Reimage the affected workstation to ensure total eradication of the malware.

Why it fails: Reimaging is a valid remediation step, but it should only happen after analysis and containment have been performed. Jumping straight to reimaging skips the critical identification of the root cause and the intelligence gathering required to detect if other systems in the environment have been compromised by similar means.

Change all user and service account passwords on the local system.

Why it fails: While credential rotation is part of the recovery process, it is not the first step when a persistence mechanism is found. The responder must first understand how the persistence was placed to prevent the attacker from simply resetting the persistence mechanism or using other credentials to regain access after password changes.

These binaries are encrypted on the disk, preventing antivirus from scanning them.

Why it fails: System binaries are not encrypted in a way that prevents AV scanning. Antivirus tools can read these files easily; the challenge is that the files themselves are known-good, trusted binaries, and the antivirus engine does not recognize that the intent of the execution is malicious in the given context.

The tools operate entirely in volatile memory and never touch the disk.

Why it fails: While some LotL techniques are fileless, many use existing binaries stored on the disk. The difficulty is not the lack of files, but the fact that the files themselves are legitimate, trusted Microsoft utilities, meaning the antivirus does not trigger an alert on the binary's presence or its execution.

Antivirus software is only capable of detecting malware written in assembly language.

Why it fails: Modern antivirus solutions detect malware written in a variety of languages, including high-level languages like C# and Python. The limitation in detecting LotL is not the language of the tool, but the fact that the tools being used are standard OS utilities that are excluded from security alerts.

Take a forensic image of the hard drive using a hardware write-blocker.

Why it fails: Disk imaging is a time-consuming process that often requires a system shutdown or at least significantly alters the system's state. It is not the first step in a live response, as volatile evidence stored in memory (RAM) would be lost or modified during this long acquisition process.

Power down the system immediately to preserve the current state.

Why it fails: Powering down a system is the most destructive action an investigator can take. It results in the immediate loss of all volatile memory (RAM), where the most critical evidence of modern cyberattacks resides. This action should only be taken as a last resort for containment in extreme scenarios.

Run an antivirus scan to identify and delete the malicious process.

Why it fails: Running antivirus tools during an investigation modifies the system state and can inadvertently delete evidence or alert the attacker to your discovery. The goal of incident response is to analyze and contain, not to blindly execute antivirus scans that could destroy the evidence needed for a proper investigation.

To identify hidden partitions created by rootkits for persistence.

Why it fails: vssadmin manages Volume Shadow Copies, which are snapshots of file system data. They do not show hidden partitions or disk structure modifications. While they can reveal files left behind in snapshots, they are not the correct tool for identifying malicious partition manipulation at the physical disk level.

To check for unauthorized changes to the system's BIOS/UEFI firmware.

Why it fails: Shadow copies store file system data from the OS volume. They do not have access to firmware, BIOS, or UEFI settings. Monitoring firmware integrity requires specialized hardware-level tools, and vssadmin is completely irrelevant for inspecting the low-level integrity of the system's boot hardware components.

To list all currently active network sockets on the host.

Why it fails: The vssadmin tool is strictly for managing Volume Shadow Copy Service (VSS) snapshots. It has no capabilities for querying network connections or socket activity. An investigator should use 'netstat' or 'Get-NetTCPConnection' to view network sockets, not this utility, which is limited to storage snapshots.

Because antivirus signatures are always outdated and will miss the actual threat.

Why it fails: While it is true that signatures may be outdated, this is not the reason why eradication must be comprehensive. Even with perfect antivirus, an APT actor may have established persistence through non-malware means, such as creating new privileged user accounts or modifying SSH authorized_keys files.

Because the attacker will likely sue the organization if any artifacts remain.

Why it fails: The primary concern in incident response is the security of the organization, not the threat of litigation from the adversary. Eradication is focused on preventing further unauthorized access, data exfiltration, or damage, and legal considerations in this context usually involve regulatory reporting, not lawsuits from attackers.

Because the cleanup process must generate new forensic evidence for police.

Why it fails: Eradication is an operational phase, not a forensic collection phase. While documentation is important, the goal is to secure the network. If anything, the act of cleaning up can destroy evidence, so the team must ensure forensic preservation is complete before starting the eradication process.

List of scheduled tasks from the Task Scheduler library

Why it fails: Scheduled tasks are stored in the registry and file system, making them non-volatile. They are useful for identifying persistence mechanisms, but they do not reveal active network connections or running processes. In the scenario, the handler needs to capture volatile evidence first; scheduled tasks can be collected later without loss of data.

Contents of the Windows Security event log

Why it fails: The Windows Security event log is stored on disk and is not considered volatile. While it contains valuable information such as logon events and process creation (if auditing is enabled), it does not provide a real-time view of active network connections or currently running processes. Collecting it is important but not a priority for capturing volatile network state.

Contents of the `C:\Windows\Prefetch` directory

Why it fails: Prefetch files are stored on disk and contain metadata about executed programs, but they are not volatile in the same sense as active network connections or running processes. They can provide historical evidence of execution, but they do not show what is currently running or connected. Therefore, they are not a priority for immediate volatile data collection.

PowerShell operational log, event ID 4104

Why it fails: Event ID 4104 in the PowerShell operational log records script block logging, which captures the content of scripts executed. While it can reveal the malicious script's code, it does not provide the full command line used to invoke PowerShell or the parent process information. Therefore, it is not the best source for understanding how PowerShell was launched.

Windows System event log, event ID 7045

Why it fails: Event ID 7045 in the System log records service installation. It is useful for detecting new services, but it does not capture process creation details like command lines or parent processes. In this scenario, the attacker used PowerShell, not a service, so this log is irrelevant to the investigation.

Windows Security event log, event ID 4688

Why it fails: Event ID 4688 logs process creation, but by default it does not include the full command line unless audit policy is configured to enable command line logging. Even then, it may not capture the parent process command line. In many environments, this setting is disabled, so relying solely on 4688 may not provide the required details for this scenario.

NIST SP 800-61

Why it fails: NIST SP 800-61 is a guide for incident handling lifecycle phases such as preparation, detection, containment, eradication, and recovery. It does not catalog adversary tactics and techniques. The responder needs TTP mapping, not process guidance. While useful for structuring the response, it will not identify which techniques the executable represents or which actors use them.

The Diamond Model of Intrusion Analysis

Why it fails: The Diamond Model relates adversary, capability, infrastructure, and victim in a single event. It is useful for pivot analysis and campaign tracking but does not enumerate techniques or provide mappings to threat groups. The responder seeking to identify known TTPs from a binary's behavior needs a technique catalog, which the Diamond Model does not supply.

The Cyber Kill Chain

Why it fails: The Cyber Kill Chain describes seven stages of an intrusion, from reconnaissance through actions on objectives. It helps explain where an attack is in its lifecycle but does not provide a granular, searchable matrix of techniques. The responder needs technique-level detail, which the Kill Chain does not offer. It is a model, not a TTP database.

Terminate the svchost.exe process immediately to stop the beaconing.

Why it fails: Terminating svchost.exe could cause system instability or a blue screen, and it destroys volatile evidence needed to understand the injection. The goal is to investigate the anomalous parent-child relationship, not to disrupt it before collecting memory and process details. Immediate termination also tips off the attacker, potentially triggering destructive actions.

Run a full antivirus scan on the workstation to detect and remove the malware.

Why it fails: A full antivirus scan may take hours and could miss fileless injection, as the malicious code resides only in memory. It also might delete artifacts before they are collected. The immediate priority is to determine if the anomaly is malicious by examining the process, not to remediate blindly.

Check the Windows Event Log for service creation events around the same time.

Why it fails: While event logs are valuable, service creation events may not capture the injection into an existing svchost.exe process. The anomalous parent indicates the process was likely started by something other than services.exe, so memory analysis is more direct. Logs alone may not reveal the injected code or its capabilities.

The system's cron job definitions under /etc/cron.d

Why it fails: Cron definitions show scheduled tasks and the accounts that run them, but they do not log interactive or scripted SSH sessions that are not scheduled. An attacker's outbound SSH session is unlikely to appear in cron unless it was deliberately scheduled. This makes cron a poor primary source for attributing a live SSH connection to a user.

The bash command history file for each user under /home

Why it fails: Bash history records commands typed interactively by users, but it does not reliably capture the source user of a network connection and can be disabled, truncated, or modified by an attacker. It also excludes non-interactive sessions. For attributing an outbound SSH connection to a specific account, the authentication and session logs are far more authoritative than shell history.

The kernel ring buffer output from the dmesg command

Why it fails: The kernel ring buffer contains hardware, driver, and boot messages. It does not normally record user-level SSH session details or account names. While it may show network interface events, it cannot attribute an outbound SSH connection to a user account. dmesg is the wrong data source for authentication attribution.