Hard Difficulty Questions

Multiple POST requests without a corresponding GET request

Why it fails: Normal applications routinely issue POST requests without a preceding GET, such as API calls and form resubmissions, so this pattern is not diagnostic. CSRF is confirmed by a state-changing request bearing the victim's authenticated session that the user never initiated. This pattern would be correct for detecting automated scripting or crawler activity.

High volume of 401 Unauthorized errors

Why it fails: CSRF typically bypasses authentication, so 401 errors are unlikely.

A sudden change in the session cookie value

Why it fails: Session cookie values legitimately change on re-authentication, timeout or rotation, so this pattern indicates session handling rather than forgery. CSRF is confirmed by a state-changing request carrying the victim's valid session without the user initiating it. Cookie change would be the right indicator for session hijacking or fixation.

High volume of A records

Why it fails: A high volume of A queries is normal for busy resolvers and caching clients, so volume alone does not distinguish tunnelling. It is tempting because exfiltration generates traffic, but elevated A-record counts would be the correct indicator when diagnosing a cache-miss storm or a DDoS flood against authoritative servers.

Requests for PTR records

Why it fails: PTR records are standard for reverse lookups.

Queries to root hints

Why it fails: Root hint queries occur during normal recursive resolution when a resolver starts cold or its cache expires, so they are routine rather than malicious. It is tempting because tunnelling also touches authoritative infrastructure, but root-hint traffic would be the correct indicator when troubleshooting resolver recursion failures.

Reconfigure all servers to use a network time protocol server and restart them.

Why it fails: Reconfiguring and restarting servers during an active investigation can destroy volatile evidence and alter system state. While time synchronization is a good practice, it should be implemented after the investigation, not during. Restarting systems may also disrupt business operations and is not a valid method for correcting historical timestamps.

Exclude timestamps from servers with unsynchronized clocks to avoid confusion.

Why it fails: Excluding timestamps removes potentially critical evidence and creates gaps in the timeline, weakening the investigation. Even unsynchronized clocks can provide valuable sequence information if offsets are known. The handler should instead document and adjust for skew rather than discard data, which could undermine the completeness of the incident analysis.

Use the timestamps from the server with the most reliable clock as the single source of truth.

Why it fails: Relying on one server's clock assumes that it is accurate and that others can be adjusted relative to it, but without synchronization there is no reliable baseline. This approach can introduce errors if the chosen server is also skewed. A defensible timeline requires validating and normalizing all timestamps, not arbitrarily trusting one source.

condition: $a + $b

Why it fails: The + operator performs arithmetic or string concatenation on values, not logical disjunction, so it cannot combine two match conditions. YARA requires the OR keyword to satisfy either pattern. Addition would be the correct construct when summing numeric values or concatenating strings inside a condition, not for boolean matching.

condition: $a != $b

Why it fails: The != operator tests inequality between two string identifiers, returning true only when their match states differ; it cannot express disjunction. YARA's OR keyword combines match conditions. The != form would be relevant when you specifically need to assert that one pattern matched while another did not.

condition: $a && $b

Why it fails: The && operator requires both $a and $b to match, so files containing only one string are missed; the stem demands OR, which is written with the || operator. It is tempting because && is the natural conjunction for combining conditions, and would be correct if the rule needed files containing both strings simultaneously.

Using clear-text Telnet for all communication

Why it fails: Telnet is easily detectable and rarely used for hiding traffic.

Sending traffic exclusively during business hours

Why it fails: This makes traffic look like user activity, but is not a method for 'hiding' the traffic itself.

Disabling all logging on the source host

Why it fails: This is an anti-forensics technique, not a way to hide network traffic.

cat /var/log/auth.log

Why it fails: The auth.log file contains authentication events stored on disk, making it persistent rather than volatile. While it is valuable for understanding login activity, it will not change or disappear if the system is rebooted. The order of volatility dictates that disk-based logs are collected after memory, network connections, and running processes. Thus, this command should not be the first step in volatile data collection.

df -h

Why it fails: The df -h command displays disk space usage, which is persistent data stored on disk. It is not volatile and will remain unchanged after a reboot. While it can be useful for understanding storage, it does not capture the most volatile data such as memory or network connections. In the order of volatility, disk information is collected later, so running this first would be incorrect.

ps aux

Why it fails: The ps aux command lists running processes, which is volatile but less volatile than network connections or memory. Processes can persist across short intervals, but network connections and memory contents change more rapidly. According to the order of volatility, you should capture network state and memory before process listings. Therefore, while ps aux is important, it is not the first command to run in this scenario.

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.

net session

Why it fails: net session displays information about current SMB sessions, such as connected clients and open files, but it does not enumerate TCP/IP connections or their owning processes. It is limited to file-sharing sessions and cannot provide the comprehensive network connection data required for incident triage.

tasklist /svc

Why it fails: tasklist /svc lists running processes and the services they host, but it does not show network connections or listening ports. While useful for identifying suspicious processes, it lacks the network context needed to correlate a process with an active connection. It is not a substitute for netstat when investigating network-based attacks.

ipconfig /displaydns

Why it fails: ipconfig /displaydns shows the contents of the DNS resolver cache, which can reveal recently resolved domain names but does not list active network connections or associated process IDs. It is useful for identifying potentially malicious domains but fails to provide the connection-to-process mapping needed to identify a compromised service.

Export the data to a public cloud storage service

Why it fails: Exporting to a public cloud service moves potentially sensitive investigative data outside the organisation's controlled, access-restricted environment, breaching preservation and confidentiality duties. Public cloud export suits non-sensitive bulk archival or approved collaboration, not evidence subject to a legal hold.

Follow the standard 90-day retention policy

Why it fails: A legal hold suspends routine destruction, so applying the 90-day retention schedule would purge evidence and risk spoliation sanctions. Standard retention is correct for ordinary records with no litigation, audit or regulatory trigger; here the hold overrides it, requiring preservation until released.

Delete the data and generate an audit log

Why it fails: Deleting the data destroys the very evidence the hold compels you to preserve; an audit log records the deletion but cannot restore content, so spoliation still occurs. Deletion with logging suits routine end-of-life disposal of non-relevant data, not material under an active legal hold.

High volume of requests to the login page without POST data

Why it fails: Requests to the login page without POST data are ordinary GET retrievals, which reveal nothing about session fixation. It is tempting because fixation begins with the attacker obtaining a session ID from the application, but that ID is then forced onto the victim, so the log signature is a reused ID across authentication.

The same session ID is associated with two different IP addresses within a short timeframe

Why it fails: Session fixation keeps one attacker-chosen session ID valid across the victim's authentication, so the ID stays constant rather than appearing from two IP addresses. It is tempting because IP changes suggest hijacking, but that pattern fits session theft after the fact, not the pre-set-ID mechanism.

A sudden spike in failed login attempts

Why it fails: Failed login spikes indicate brute-force or credential-stuffing attempts, not session fixation, which succeeds without guessing credentials. It is tempting because login anomalies often signal authentication attacks, but session fixation requires the victim to authenticate successfully while retaining an attacker-supplied session ID.

Change the root password to lock out the attacker

Why it fails: Changing the root password alters system state and can overwrite credential artefacts, while the insider may retain other access paths or already have exfiltrated data. It is tempting as immediate lockout, and credential rotation is correct during later remediation, but evidence capture must precede any modification of the compromised host.

Delete the suspicious user account

Why it fails: Deleting the account destroys authentication logs, mailbox data and file ownership records that constitute evidence, and alerts any accomplice. It is tempting as rapid containment, and disabling an account is valid once evidence is captured; however, volatile and account-linked artefacts must be preserved before any identity change.

Reboot the compromised system to clear malicious memory

Why it fails: Rebooting clears volatile memory, destroying running processes, network connections and injected code that constitute primary evidence. It is tempting because restarting often restores service quickly, and rebooting is acceptable after memory capture; however, live forensic acquisition must happen first to preserve integrity.

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 handler has completed the initial triage checklist.

Why it fails: Completing triage is a procedural milestone, but it does not automatically warrant escalation. Triage helps determine severity and scope, and escalation should follow from those findings. Escalating merely because a checklist is complete could cause unnecessary management involvement or delay when the incident is low impact.

The malware sample has been identified as a known ransomware family.

Why it fails: Identifying the malware family is useful technical context, but it does not by itself determine business impact or urgency. Escalation criteria should be tied to severity, scope, and potential harm to the organization, not merely to the classification of the tool. A known family may be contained quickly or may be widespread; the handler needs impact data before escalating.

The incident has been assigned a ticket number in the incident tracking system.

Why it fails: Creating a ticket is an administrative step that documents the incident but does not indicate severity or business impact. Ticket creation is part of intake and tracking, not a trigger for management escalation. Escalation depends on the incident's potential harm, not on whether it has been logged in the tracking system.

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 HTTP User-Agent string used by the internal host

Why it fails: The User-Agent string is part of HTTP headers, but in HTTPS traffic, it is encrypted unless TLS inspection is performed. Even with inspection, User-Agent can be spoofed and is not a reliable indicator of exfiltration. It may help identify the client application, but it does not directly reveal the exfiltration channel or destination.

The total number of bytes transferred during the session

Why it fails: While a large data transfer might indicate exfiltration, many legitimate activities also transfer large amounts of data. Byte count alone does not distinguish malicious exfiltration from normal traffic. It is a supporting indicator but not the best artifact to identify the specific channel, especially without context about the destination or content.

The source IP address and port number of the internal host

Why it fails: While source IP and port can identify the internal host involved, they do not reveal the content or destination of the exfiltration. Many hosts could be using similar ports, and the port number alone does not indicate malicious activity. This information is too generic to pinpoint the exfiltration channel without additional context.

TCP RST flood denial-of-service attack

Why it fails: A TCP RST flood would typically involve a high volume of RST packets targeting a single victim to disrupt connections. Here, the RST packets are originating from an internal server and going to various external IPs, which is not the typical pattern of a DoS attack against the server itself. The server is the source, not the target, so a RST flood against it is unlikely.

TCP SYN scan with RST responses

Why it fails: A TCP SYN scan would involve the server sending SYN packets, not RST packets. The scenario states the server is not responding to SYN packets, so it is not initiating scans. RST responses would be sent by a target to a scanner, but here the server is the source of RSTs to many external IPs, which is inconsistent with a scan.

TCP SYN flood denial-of-service attack

Why it fails: A TCP SYN flood involves sending a large number of SYN packets to a target to exhaust its connection table. The scenario describes RST packets, not SYN packets, and the server is the source, not the target. Therefore, this is not a SYN flood. The absence of SYN responses from the server further rules out a SYN flood originating from it.

Add a static route to null0 for 203.0.113.45 on the internal router

Why it fails: Adding a static route to null0 on an internal router would blackhole traffic destined to the C2 server, but this action is typically performed on the internal network and may not affect traffic that is already routed to the perimeter. It is less precise than a firewall rule and may not be applied at the correct point in the network to block outbound connections effectively.

Enable deep packet inspection (DPI) to block all HTTPS traffic

Why it fails: Blocking all HTTPS traffic would disrupt legitimate business operations and is overly broad. It would not specifically target the malicious communication and could cause significant collateral damage. The goal is to block the specific C2 channel, not all encrypted traffic.

Create an inbound firewall rule to block traffic from 203.0.113.45

Why it fails: An inbound firewall rule would block traffic originating from the C2 server to your network, but the compromised system initiates outbound connections to the C2 server. The malware typically connects outbound, so blocking inbound traffic from the C2 server does not stop the initial connection or data exfiltration from the infected host.

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.

cat /proc/net/dev directly.

Why it fails: While this is direct, it does not provide the state of active TCP/UDP connections needed for incident response.

ss -antup using the local /usr/bin/ss binary.

Why it fails: Using local binaries is dangerous if the system is compromised, as the binaries themselves might be trojaned.

tcpdump -i any -w capture.pcap.

Why it fails: While useful, tcpdump consumes significant resources and may not show the current connection state as clearly as socket-listing tools.

The 'Elasticsearch' index prefix in system settings

Why it fails: This determines storage location, not the structure of incident report fields.

The 'Analyzer' timeout setting in the application.conf file

Why it fails: This setting controls the duration of external analysis tasks, not metadata field definitions.

The 'Cortex' connection string in the GUI settings

Why it fails: Cortex settings manage connections to analyzers, not the internal incident schema.