Enterprise Environment Incident Response practice questions

Immediately disconnect the network cable to prevent further C2 communication.

Why it fails: Disconnecting the network cable effectively stops C2 traffic but destroys all volatile data currently residing in RAM. This approach results in the loss of critical artifacts such as decrypted malicious payloads, resident memory-only malware, and active session tokens which are essential for conducting a comprehensive forensic root cause analysis.

Perform a remote shutdown of the host to ensure the system is in a known safe state.

Why it fails: Shutting down the host triggers the OS to clear page files and volatile memory buffers, permanently destroying evidence of the malicious process. Forensic best practices dictate that volatile memory must be captured using a trusted, statically linked tool before any system state changes occur, as shutdown processes wipe critical forensic artifacts.

Update the host's antivirus signature and run a full system scan.

Why it fails: Running an antivirus scan alters the file system metadata and changes memory state, potentially corrupting forensic evidence. Furthermore, sophisticated malware often uses anti-forensic techniques to detect scan activity and terminate or obfuscate its presence, rendering the resulting scan report unreliable for an incident response investigation and forensic reconstruction.

The process is running under the SYSTEM account, which indicates privilege escalation.

Why it fails: The SYSTEM account is the default execution context for many legitimate services and host processes. The presence of svchost.exe running as SYSTEM is entirely normal and expected behavior for the Windows operating system; therefore, it does not inherently indicate privilege escalation or any form of malicious compromise on its own.

The command line arguments are malformed and missing necessary system flags.

Why it fails: The provided command line arguments, including the -k netsvcs flag, are standard for svchost.exe. These arguments correctly point to the service group that the process is intended to host. The syntax is syntactically correct and consistent with how Windows services are invoked by the Service Control Manager during normal system operation.

The process ID (PID) is unusually high, suggesting it was recently spawned by an attacker.

Why it fails: Process IDs are assigned by the operating system based on availability and sequence, not by the nature of the process or its origin. A PID of 4920 is a perfectly valid and common ID on a busy Windows server and holds no inherent meaning regarding the legitimacy of the process itself.

It provides a backup for internal systems in case of a total network outage.

Why it fails: While OOB channels can serve as a backup during outages, the primary security rationale is to prevent unauthorized monitoring by an adversary. In an incident context, availability is secondary to the confidentiality of the response strategy and the need to prevent the attacker from monitoring the investigation progress.

It is required by industry regulations like PCI-DSS and HIPAA for all incidents.

Why it fails: While many frameworks recommend secure communications, OOB is not a specific, named regulatory mandate for all incident types. The necessity of OOB communication is driven by the threat model and the assumption of compromise, rather than specific regulatory compliance requirements which typically focus on data protection and disclosure.

It allows the team to invite third-party forensics firms to join the call.

Why it fails: While OOB channels can facilitate third-party involvement, their primary purpose is security. Inviting external parties is a logistical benefit, but the fundamental security requirement for OOB is to protect the integrity and confidentiality of the internal response effort from an adversary who likely already has access to the internal network.

The administrator is performing routine maintenance on the server.

Why it fails: Legitimate maintenance would not involve installing services from a temporary folder using a binary named svchost.exe. This behavior is a classic signature of malware masquerading as a system service. Furthermore, administrative tasks would typically be documented and follow established change control processes, rather than using obfuscated PowerShell commands.

The server has been compromised by an automated worm spreading via SMB.

Why it fails: While worms exist, the manual-like execution of PowerShell commands following the service installation suggests an interactive session. A worm would typically automate the entire infection chain without needing to drop encoded scripts for post-exploitation tasks, making an interactive, hands-on-keyboard adversary a much more likely conclusion in this scenario.

The PowerShell command was an automated log cleanup task.

Why it fails: Log cleanup tasks would not typically involve adding group members, which is what the PowerShell command structure implies. Moreover, using an encoded command to perform routine administrative tasks is poor practice and highly atypical for standard system management, making it far more likely to be an attempt to bypass security logging.

Analyze the MFT for recent PowerShell script file modifications.

Why it fails: Master File Table analysis only reveals file system changes, which is ineffective here since the PowerShell command is running in memory. The attacker is using an obfuscated in-memory execution strategy that avoids creating persistent script files on the disk, rendering traditional file system forensic analysis insufficient for recovering the payload.

Capture and analyze the system's prefetch files for execution history.

Why it fails: Prefetch files provide evidence of application execution and file access, but they do not contain the specific content of scripts executed in memory. They indicate that the PowerShell process was launched, but they lack the forensic granularity required to reconstruct the malicious obfuscated commands used during the runtime execution phase.

Examine the Windows Event Logs for PowerShell script block logging.

Why it fails: While Script Block Logging (Event ID 4104) is a powerful detective tool, it is not a memory forensics technique. It relies on the pre-existence of logging policies being enabled before the attack. Relying solely on logs can fail if the attacker disabled the logging service or cleared the event logs.

Block all traffic to the specific destination IP addresses.

Why it fails: Attackers use Content Delivery Networks (CDNs) for domain fronting, which share IP addresses with many legitimate services. Blocking the IP would result in collateral damage to legitimate business traffic, as the CDN hosts thousands of unrelated websites. This is a blunt instrument that fails to address the underlying protocol discrepancy.

Restrict DNS queries to only known internal domain names.

Why it fails: Domain fronting typically involves the attacker making a connection to a legitimate, high-reputation domain that is often allowed in egress policies. DNS filtering does not stop the connection because the DNS query is technically valid for the fronted domain. It provides no defense against the subsequent encrypted tunnel.

Enable Geo-IP blocking to prevent traffic to foreign countries.

Why it fails: Many CDNs use global infrastructure, meaning fronting traffic may appear to originate from domestic data centers. Geo-IP blocking is ineffective against attackers who use the infrastructure of globally distributed cloud providers to mask their true origin, as the traffic will still appear to be coming from an allowed region.

Excessive failed logins using the local Administrator account.

Why it fails: Failed logins are typically a sign of brute-force password guessing, not lateral movement. Once an attacker has moved laterally, they have likely already compromised valid credentials and are authenticating successfully. Failed logins usually indicate a credential-harvesting stage, not the post-compromise movement phase that follows successful authentication.

Increase in standard daily outbound web traffic metrics.

Why it fails: Outbound web traffic is typically associated with command-and-control (C2) communication or data exfiltration, not lateral movement. While these are parts of an incident, they are distinct from the movement phase, which occurs internally between systems within the same network segment or across segmented internal boundaries.

Preparation.

Why it fails: Preparation involves establishing the tools, training, and processes required for incident response before an event occurs. It is focused on readiness and resource availability rather than the reactive investigation of a specific, ongoing security incident or the determination of root cause for a compromised system or network component.

Containment, Eradication, and Recovery.

Why it fails: Containment, Eradication, and Recovery focus on stopping the threat, removing the malicious artifacts, and restoring systems to normal operations. While these phases happen after detection, they assume that the identification and analysis of the threat have already been completed to allow for focused and effective remediation of the issues.

Post-Incident Activity.

Why it fails: Post-Incident Activity occurs after the threat has been neutralized and the system is recovered. It focuses on lessons learned, updating security policies, and improving future response efforts based on the findings from the incident. It does not focus on identifying the root cause of an ongoing security breach.

Instruct users to run a provided batch file that collects system information and emails it to the incident response team.

Why it fails: User-executed batch files are unreliable and may be tampered with. Email transmission is insecure and can alter metadata. Volatile data collection order is not guaranteed, and user involvement introduces delays and potential errors, compromising evidence integrity.

Remotely execute a PowerShell script that collects memory, network connections, and running processes, then writes the output to a network share.

Why it fails: Remotely executing a PowerShell script can alter system state and may not capture volatile data in the correct order. Writing directly to a network share can introduce latency and potential loss of volatile data. Additionally, the script itself may overwrite evidence or leave artifacts, compromising integrity.

Use a commercial forensic suite to create a full disk image of each endpoint, then extract volatile data from the images.

Why it fails: Full disk imaging captures non-volatile data but misses volatile information like memory and network connections. The imaging process itself can overwrite volatile data. This approach is also time-consuming and impractical for hundreds of endpoints during an active incident.

NTDS.dit database file

Why it fails: NTDS.dit contains Active Directory data, including password hashes. While it is valuable for understanding what credentials were compromised, it does not directly show Kerberos ticket manipulation or persistence. Collecting it may be part of a broader investigation, but it is not the priority for identifying the specific persistence mechanism.

LSASS process memory dump

Why it fails: LSASS memory can contain cached credentials and Kerberos tickets, but it is volatile and may not persist after a reboot. While useful for extracting credentials, it does not provide a historical record of ticket manipulation. For persistence via Kerberos, event logs are more reliable and prioritized.

Registry hives (SYSTEM, SAM, SECURITY)

Why it fails: Registry hives store configuration and some credential data, but they do not record Kerberos ticket requests or manipulation. They might reveal other persistence methods, but for Kerberos-specific persistence, they are less relevant than event logs or memory analysis.

windows.dlllist

Why it fails: windows.dlllist lists loaded DLLs for a process, which can help identify malicious DLLs but does not detect process hollowing. Hollowing involves replacing the main executable image, not necessarily loading additional DLLs. Thus, dlllist would not show the discrepancy between the in-memory executable and its on-disk version.

windows.malfind

Why it fails: windows.malfind scans for hidden and injected code by looking for memory regions with unusual permissions (e.g., PAGE_EXECUTE_READWRITE) and no file backing. While it can detect injected code, it does not compare the in-memory executable image with the on-disk file. Process hollowing may leave such regions, but malfind alone is not designed to identify the discrepancy between memory and disk.

windows.psscan

Why it fails: windows.psscan scans for processes by traversing pool tags and can find hidden or terminated processes. It does not compare memory images with disk files. While it is useful for finding processes that are not linked in the active process list, it will not reveal whether a legitimate process has been hollowed out and replaced with malicious code.

Get-Process | Select-Object Id,ProcessName,Path

Why it fails: This lists processes with their IDs and image paths, but it does not associate them with network connections. Without connection endpoints, the responder cannot determine which process is responsible for each network session, so it fails the volatile data collection objective described.

netstat -ano

Why it fails: The -ano switch displays all connections and listening ports in numeric form with the owning process ID, but it does not display the executable path. It is useful for PID correlation, yet the scenario explicitly requires the executable path for each connection, which netstat alone cannot provide.

Get-NetTCPConnection -State Established | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess

Why it fails: This PowerShell cmdlet returns TCP connection state and owning process ID, but it does not resolve the executable path associated with each OwningProcess. The responder would need a second step to map PIDs to image paths, so this does not satisfy the requirement in a single reliable command on the live host.

Use WinPmem to capture memory via a remote PowerShell session.

Why it fails: WinPmem is a memory acquisition tool, but using a remote PowerShell session requires network access and authentication, which may not be available on a locked system. Additionally, remote execution could introduce network artifacts and may not capture memory reliably if the session is unstable. It also requires administrative privileges that might not be accessible in a locked state.

Use Magnet RAM Capture via a physical USB device and autorun script.

Why it fails: Magnet RAM Capture is a legitimate tool, but autorun scripts are disabled by default on modern Windows systems for security reasons. Even if enabled, executing from a USB device would require user interaction or administrative rights, which are not available on a locked system. This approach is unreliable and may not execute as expected.

Use the built-in Task Manager to create a memory dump of the suspicious process.

Why it fails: Task Manager can create process dumps, but it requires an interactive session. On a locked system, you cannot access Task Manager. Furthermore, a process dump captures only a single process's memory, not the entire system memory, which is necessary for a comprehensive forensic analysis of malware that may have multiple components or kernel-level activity.

Tunneling C2 over DNS

Why it fails: DNS tunneling would involve encoding data in DNS queries and responses, typically using port 53. The scenario specifies port 443, so DNS tunneling is not applicable. While DNS tunneling can evade detection, it does not match the observed traffic characteristics.

Using a fast flux network

Why it fails: Fast flux is a technique where the IP address associated with a domain name is rapidly changed to evade detection. The scenario describes traffic to a single unknown external IP, not a rapidly changing set of IPs. Therefore, fast flux is not the most likely technique here.

Domain fronting

Why it fails: Domain fronting involves using a legitimate content delivery network (CDN) to mask the true destination of traffic. While it can hide C2, the scenario describes consistent beaconing to an unknown external IP, which is more indicative of a direct connection or a beaconing pattern. Domain fronting would typically show connections to a CDN's IP, not an unknown IP.

The Security event log for event ID 4698 (A scheduled task was created)

Why it fails: Event ID 4698 indicates that a scheduled task was created, but it only logs the task name and the user who created it, not the full command line or the account under which it runs. It is useful for identifying when the task was created but does not provide the operational details needed. Relying on it alone would leave gaps in understanding the persistence.

The file system path C:\Windows\System32\Tasks

Why it fails: The C:\Windows\System32\Tasks folder contains files that represent scheduled tasks, but these files are not always human-readable and may be in a binary format. They do not directly provide the command line or user account in a clear manner. The registry TaskCache key is more direct and reliable for obtaining the full configuration.

The Task Scheduler event log (Microsoft-Windows-TaskScheduler/Operational.evtx)

Why it fails: The Task Scheduler operational log records task start, stop, and action events, but it does not always contain the full command line or the user account details. It may show that a task ran but not the exact parameters. While useful for timeline analysis, it is not the primary source for task configuration.

Immediately shut down the server to prevent further attacker actions.

Why it fails: Shutting down the server would destroy volatile evidence such as memory-resident malware, active network connections, and running processes. It also causes downtime for critical applications. The goal is to capture volatile data first, not to power off. Only after volatile evidence is secured should a decision about shutdown be made, and often a reboot is not necessary for forensic acquisition.

Disconnect the server from the network to isolate it.

Why it fails: Disconnecting the server from the network would prevent remote attacker access but also disrupt business operations and could alert the attacker. It also prevents the team from capturing live network connections and remote forensic data. Isolation may be necessary later, but it is not a step to capture volatile data and could cause more downtime than required.

Run a full antivirus scan to remove any malware.

Why it fails: Running an antivirus scan modifies the system by quarantining or deleting files, which can destroy evidence. It also consumes resources and may not detect advanced threats. The priority is to capture volatile data without altering the system state. Antivirus remediation should only occur after evidence collection and analysis, and even then, with caution.

Scanning for known malicious strings

Why it fails: Scanning for known malicious strings can help identify indicators, but it is not a robust technique for detecting injected code. Attackers often encode or encrypt their payloads, and strings may not be present in plaintext. This method is more useful for initial triage but may miss sophisticated injections.

Examining the Master File Table (MFT) for alternate data streams

Why it fails: The MFT records file metadata and can reveal alternate data streams, but it does not show in-memory code injection. Fileless malware often does not touch the disk, so the MFT would not contain evidence of the injected code. This technique is not suitable for memory forensics.

Checking the Windows event logs for process creation events

Why it fails: Event logs may show the creation of the legitimate process, but they do not reveal that its memory was hollowed or injected. Event logs are not memory forensics artifacts and cannot show the contents of process memory. They are useful for correlating activity but not for identifying injected code.

It removes sensitive PII from logs to ensure regulatory compliance.

Why it fails: Normalization is focused on data structure and consistency, not data scrubbing or privacy. While log management systems might have data masking features, the primary purpose of normalization is to enable programmatic analysis, correlation, and searchability, rather than providing the security controls required to fulfill PII-related regulatory compliance obligations.

It compresses log files, reducing storage costs for long-term retention.

Why it fails: Compression is a separate function related to storage optimization. While normalized logs might be indexed differently, the act of normalization itself often increases the size of the ingested data due to the addition of consistent metadata fields and structured tagging, which is necessary for effective automated correlation and threat hunting.

It automatically blocks malicious traffic detected within the log streams.

Why it fails: Normalization is a data processing step, not an active defense mechanism. While an SIEM might trigger alerts based on normalized data, the normalization process itself is passive and does not interact with network traffic or endpoints to perform real-time blocking, which is the function of firewalls or EDR systems.

Identification

Why it fails: The identification phase is focused on detecting and confirming the scope of an incident. It involves analyzing logs, alerts, and suspicious activity to define what happened. It does not involve the remediation or restoration of services, which are critical components of the later stages of the incident response lifecycle.

Containment

Why it fails: Containment is the phase focused on limiting the damage and preventing the threat from spreading further within the environment. It is a temporary stop-gap measure and does not involve the full remediation, patching, or restoration activities required to return systems to a trusted and secure operational state.

Lessons Learned

Why it fails: Lessons learned occurs after the incident is resolved. It is a retrospective process focused on improving future response procedures by identifying what went well and what could be improved. It does not involve the technical act of restoring systems or verifying the security status of the environment post-incident.

Increase the minimum password length requirement to 20 characters.

Why it fails: While strong passwords are a good security policy, they do not prevent Pass-the-Hash attacks. PtH works by using the already-hashed version of the password stored in memory; the actual password complexity is irrelevant to the attack, as the attacker never needs to crack the underlying password to succeed.

Regularly scan for and remove all local user accounts.

Why it fails: Removing local accounts does not stop PtH, as the attack often targets domain-level accounts that are logged into the compromised machine. Furthermore, removing local accounts can break essential system functionality and administrative capabilities, creating operational instability without providing a meaningful reduction in the risk of lateral movement via hash reuse.