Select Two (Multi-Select) Questions

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

Why it fails: The Winlogon Shell value is a legitimate autostart location and can be abused, but it is less commonly used by commodity malware than the Run keys because it is well-monitored and changes are visible. It remains a valid secondary check, yet it is not among the two most common persistence points to inspect first.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Why it fails: The Tcpip\Parameters key stores network configuration such as DNS servers, hostname, and IP settings. While malware can modify DNS settings to redirect traffic, this location is not a standard autostart point and does not cause code to execute at boot, so it is not a primary persistence location to inspect during this phase.

HKEY_CLASSES_ROOT\Installer\Products

Why it fails: The Installer\Products key tracks installed MSI-based applications and their product codes. It is a legitimate Windows Installer database and is not an autostart mechanism; inspecting it will not reveal malware persistence unless the malware was installed as an MSI package, which is not the typical case in this scenario.

Printer spooler logs

Why it fails: Printer spooler logs record print job submission and queue events on print servers, carrying no HTTP requests, session identifiers or application errors. They are tempting because they are host-based logs an investigator might collect, but auditing them yields nothing about the web application's request handling or authentication flow.

Hardware router logs

Why it fails: Hardware router logs capture interface, routing and ACL events at layer 3, not HTTP requests, cookies or application exceptions. They are tempting because network telemetry can corroborate an intrusion timeline, but they cannot show what the web application itself logged during the incident.

Monitoring network traffic for signs of re-infection

Why it fails: Monitoring network traffic is part of the recovery or post-incident monitoring phase. It helps ensure the malware has been successfully removed and does not attempt to communicate again. It does not actively remove the malware, so it is not an eradication action.

Restoring the system from a known good backup

Why it fails: Restoring from a backup is typically part of the recovery phase. It returns the system to a known good state after the malware has been eradicated. While it can remove the malware, it is not considered an eradication step per se; eradication focuses on removing the malware from the current system.

Disconnecting the infected workstation from the network

Why it fails: Disconnecting the infected workstation from the network is a containment action. It prevents the malware from spreading to other systems but does not remove the malware from the infected host. Eradication involves eliminating the malware and its artifacts from the system.

Increased usage of SNMP

Why it fails: SNMP is used for network device monitoring and management on UDP 161/162, unrelated to RDP session establishment. It is tempting because unusual SNMP activity can signal device compromise, and SNMP monitoring is correct when investigating router or switch configuration changes.

High volume of HTTPS traffic

Why it fails: RDP lateral movement generates traffic on TCP 3389, not HTTPS on 443, so this volume indicates web browsing or tunnelled command-and-control instead. It is tempting because attackers tunnel RDP over HTTPS, and HTTPS analysis is correct when hunting exfiltration or web-based command channels.

Reboot the system to clear temporary files.

Why it fails: Rebooting clears volatile memory, running processes and network state, irreversibly destroying evidence that cannot be recovered from disk. It is tempting as a first response to suspected compromise, since restarting often restores service, but memory capture and live triage must precede any restart.

Modify file permissions to prevent further access.

Why it fails: Altering permissions changes file metadata, corrupting timestamps and access records that establish what happened and when, weakening evidential integrity. It is tempting as containment to stop further tampering, but preservation demands write-blocking or forensic copies, not permission edits on the original media.

Delete all temporary logs to save space.

Why it fails: Deleting temporary logs destroys volatile evidence such as session data and process artefacts before acquisition, breaching chain-of-custody and spoliation rules. It is tempting during storage pressure, where clearing temp files is routine housekeeping, but forensic preservation requires imaging and hashing that data first.

The email uses standard corporate branding

Why it fails: Standard corporate branding is what legitimate mail mimics and what attackers forge, so its presence proves nothing; phishing indicators concern mismatched domains, urgency and suspicious links. It is tempting because branding checks are the right choice when verifying a known sender's genuine marketing template.

The email is sent during business hours

Why it fails: Business-hours delivery is normal mail behaviour and reveals nothing about sender authenticity or intent, so it cannot indicate phishing. It is tempting because timing anomalies occasionally accompany bulk campaigns, making send-time analysis the right choice when correlating delivery patterns during forensic investigation.

Increasing the DHCP lease time

Why it fails: Extending DHCP lease time keeps existing addresses bound to hosts, which preserves attacker connectivity rather than isolating it. It is tempting because longer leases reduce churn and administrative load in stable environments, and that would be the right choice when minimising DHCP traffic is the operational goal.

Installing new hardware across the network

Why it fails: Procuring and deploying new hardware is a remediation or re-architecture activity, not containment of an active incident. It is tempting because rebuilding infrastructure can eliminate persistence, and hardware replacement would be correct during recovery or when hardware is confirmed compromised beyond cleaning.

CCleaner

Why it fails: CCleaner removes temporary files and registry entries; it captures no volatile memory, so running processes, network connections and injected code are lost. It is tempting because it is a familiar Windows cleanup utility, but that is its actual purpose — disk hygiene on healthy endpoints, not forensic acquisition.

Windows Update

Why it fails: Windows Update installs operating system patches; it neither acquires nor preserves RAM contents, so running processes and network artefacts remain uncaptured. It is tempting as a routine maintenance task on a live workstation, but patching is its actual purpose — remediating vulnerabilities, not volatile evidence collection.

The private health records of the affected users.

Why it fails: Private health records are unrelated to the incident's technical facts and would breach data-protection obligations if copied into a triage report. It is tempting because affected-user details genuinely belong in victim-notification or HR welfare processes, where such data is lawfully handled.

The names of all employees who have access to the building.

Why it fails: Building-access rosters do not describe the incident itself, so they add nothing to triage. It is tempting because access lists genuinely belong in post-incident scoping or insider-threat investigations, where identifying who could reach the affected area is the correct step.

HKEY_CLASSES_ROOT\CLSID

Why it fails: CLSID holds COM class registration data, not autostart entries, so it does not directly show persistence. It is tempting because COM hijacking abuses CLSID entries, and it would be relevant when investigating COM-based code execution rather than registry Run-key persistence.

HKEY_CURRENT_USER\Control Panel\Desktop

Why it fails: Control Panel\Desktop stores wallpaper, screen saver and input settings, not autostart entries, so it does not reveal persistence. It is tempting because malware can alter desktop configuration, and it would be relevant when investigating visual or user-interface tampering rather than persistence.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Why it fails: MountPoints2 records per-user mounted removable and network volumes, not autostart execution, so it does not indicate persistence. It is tempting because it is a per-user key abused for tracking, and it would be relevant when investigating USB or mapped-drive access.

Normal spanning-tree convergence

Why it fails: Normal spanning-tree convergence is expected healthy behaviour, indicating the topology is settling correctly rather than being manipulated. It is tempting because attackers can abuse STP to become root bridge, and abnormal root-bridge elections would be the genuine indicator of switch compromise to look for.

Decreased CPU usage on the switch

Why it fails: A compromised switch typically shows elevated CPU from traffic flooding, mirroring or looping, so decreased CPU usage contradicts the expected symptom. It is tempting because reduced load sounds like a fault, and high CPU or unusual traffic patterns would be the correct indicator of switch compromise.

Stable port security status

Why it fails: Stable port security status shows MAC-based port restrictions are holding, which is the desired state, not evidence of compromise. It is tempting because port security is a switch-hardening control, and violations, err-disabled ports or unexpected MAC counts would be the actual signs of a compromised switch.

Blocking the attacker's IP address at the firewall

Why it fails: Blocking an IP address is a containment measure, not eradication. While it can help prevent further communication, it does not remove the threat from the compromised system. Eradication focuses on eliminating the root cause and any malicious artifacts, not just blocking external access.

Restoring data from backups

Why it fails: Restoring data is part of the recovery phase, which occurs after eradication. Recovery aims to return systems to normal operation. Eradication must happen first to ensure that the threat is gone; otherwise, restored data could be compromised again. Thus, restoration is not an eradication activity.

Conducting a lessons learned meeting

Why it fails: A lessons learned meeting is part of the post-incident phase, after recovery. It is not an eradication activity. Eradication focuses on removing the threat and its root cause. Lessons learned is about improving future response, so it occurs later in the incident handling lifecycle.

The tool must run on a cloud-based server.

Why it fails: Incident response often occurs on isolated or degraded networks where cloud services are unreachable, so toolkit tools must run locally on the responder's own machine. Cloud hosting is tempting because it centralises updates and collaboration, and it suits distributed security teams doing routine monitoring with reliable connectivity.

The tool must be proprietary and expensive.

Why it fails: First-responder toolkits prioritise freely available, portable tools that can be legally carried and run without licensing delays during an incident. Proprietary, expensive software adds cost and procurement friction. It is tempting because commercial forensic suites offer polished, supported features, and they are the right choice for a funded lab doing routine corporate investigations.

The tool must be able to delete the malware.

Why it fails: First responders preserve and collect volatile evidence; deleting malware destroys the artefacts needed for analysis and attribution. Removal is tempting because eradicating the threat appears to resolve the incident, and it is the correct goal later during remediation, once evidence has been captured and scoped.

The host has a valid digital certificate for the destination domain.

Why it fails: A valid TLS certificate only confirms the domain's identity and encryption, not its intent. Malware operators frequently obtain legitimate certificates to make their C2 traffic appear trustworthy. Certificate validity is therefore not a reliable discriminator. Analysts should focus on behavioral patterns such as timing regularity and payload uniformity rather than the presence of a valid certificate.

The traffic uses HTTPS on port 443 to blend with normal web traffic.

Why it fails: Using HTTPS on port 443 is standard for legitimate web services and is not by itself suspicious. Attackers do abuse encrypted channels to evade inspection, but the mere use of port 443 is common and expected. Without additional indicators such as fixed timing, uniform payload sizes, or unknown destinations, encrypted web traffic alone does not distinguish C2 from normal browsing.

The destination IP address belongs to a cloud hosting provider.

Why it fails: Many legitimate services, including SaaS applications and CDNs, are hosted on cloud providers. Attackers do abuse cloud infrastructure, but the hosting provider alone is not indicative of malicious activity. This characteristic is too broad and would generate false positives. Analysts must correlate destination reputation with timing, payload, and process context before concluding it is C2.

Re-enabling user access to shared drives after verifying file integrity checksums.

Why it fails: Returning user access to shared drives is a recovery action performed once the environment is confirmed clean and stable. Verifying checksums supports recovery validation but does not contain anything; it restores business functionality. Doing this while the intruder might still be present would expose the data again, so it belongs after containment and eradication, not within the containment phase itself.

Restoring the file server from the most recent clean backup and returning it to service.

Why it fails: Restoring from backup and returning the server to production is a recovery activity that occurs after containment and eradication are finished. Performing it during containment would reintroduce the system to the network before the attacker's access path is eliminated, risking immediate recompromise. Recovery aims to return to normal operations, which is the opposite goal of containment, where limiting spread and preserving evidence take priority.

Applying the vendor security patch that fixes the vulnerability used to gain initial access.

Why it fails: Patching the exploited vulnerability is an eradication activity. It removes the root cause so the attacker cannot re-enter through the same vector, but it does not by itself stop an active intruder who may already hold credentials or alternate footholds. Eradication follows containment; the patch is applied after the threat is boxed in, not as the step that boxes it in.

Application server error logs

Why it fails: Application server error logs record exceptions, stack traces, and application-level failures. They can indicate that the application is overwhelmed, but they lack details about the incoming requests, such as source IPs or request rates. They are useful for diagnosing application health but not for tracing the attack's origin or pattern.

Operating system event logs

Why it fails: OS event logs contain system-level events such as service starts, authentication attempts, and hardware errors. They may show resource exhaustion due to the attack, but they do not capture the incoming HTTP requests or their sources. They are not the primary source for understanding the attack pattern or origin in a web DDoS scenario.

Database server logs

Why it fails: Database server logs primarily record queries, errors, and performance metrics. While a DDoS attack might cause database connection timeouts, these logs do not show the source of the HTTP flood or the attacking IP addresses. They are more relevant for investigating SQL injection or data exfiltration, not for identifying the origin of a network-layer or application-layer DDoS.

Immediately delete the malicious review from the database to stop the payload from executing.

Why it fails: Deleting the review removes the primary evidence of the stored payload and its injection vector. While it stops execution, it also prevents investigators from determining the exact script, the vulnerable parameter, and whether other records were modified. Evidence should be captured before any removal or sanitization.

Block all inbound HTTP requests containing angle brackets at the perimeter firewall.

Why it fails: Blocking angle brackets at the firewall is easily bypassed with encoding techniques and would break legitimate content that uses those characters. It does not address the stored payload already in the database or the lack of output encoding. Perimeter filtering at that level is not a reliable containment measure for stored XSS.

Disable the entire web application until the development team rewrites the review module.

Why it fails: Taking the whole application offline is a disproportionate response that disrupts business operations and may not be necessary once output encoding is applied. A targeted fix to the affected page and related input fields contains the incident while maintaining availability. Full shutdown should be reserved for cases where containment cannot be achieved otherwise.

Run a full malware scan on the database server.

Why it fails: Running a malware scan is not a containment action; it is a remediation step. It does not immediately stop the active network connection and could take a long time, during which data may continue to exfiltrate. Containment should focus on stopping the adversary's access first.

Disconnect the database server from the network immediately.

Why it fails: Disconnecting the server immediately would stop the traffic but could disrupt critical business operations and destroy volatile evidence. In a financial institution, database servers are often business-critical, so a more surgical containment is preferred. Additionally, abrupt disconnection may alert the attacker and prevent further observation.

Shut down the database service to prevent further data leakage.

Why it fails: Shutting down the database service would halt the exfiltration but also cause a denial of service for legitimate users and applications. It may also destroy volatile evidence in memory. This action is too disruptive and does not align with the principle of least disruption during containment.

Optical disc contents.

Why it fails: Optical disc contents persist until deliberately destroyed, so they are non-volatile and survive power loss, unlike registers, cache and RAM. It tempts because discs are removable and easily overlooked at a scene, and would be the right classification when cataloguing archival or long-term storage media.

Hard drive data.

Why it fails: Hard drive data survives power removal, making it non-volatile, whereas registers, cache and RAM lose contents immediately. It tempts because drives are the obvious place investigators look first, and would be the right category when imaging persistent storage for later forensic examination.

Printed log files.

Why it fails: Printed log files are fixed on paper and persist indefinitely, so they are non-volatile, unlike RAM, cache and running processes. It tempts because logs feel transient and operationally incidental, and would be correct when establishing a documented, court-admissible paper trail.

Operating system kernel logs

Why it fails: Kernel logs record hardware, driver and operating-system events, not the SQL statements reaching the database engine. They assist when investigating host-level compromise or crashes, whereas SQL injection response needs database query and error logs showing the injected input.

Database backup completion logs

Why it fails: Backup completion logs record job success, duration and archive locations, revealing nothing about injected SQL statements or the queries that executed them. They matter for recovery assurance after data corruption, not for tracing the attack's entry point during incident response.

Network interface statistics

Why it fails: Network interface statistics capture packet counts, errors and throughput, not the SQL text submitted to the database. They help diagnose connectivity or volumetric anomalies, but SQL injection forensics requires query and error logs recording the malicious statements themselves.