Hard Difficulty Questions

The files were stored in the paging file, which is volatile

Why it fails: Paging file contents are volatile and lost on shutdown, so they cannot explain deleted files on disk; the files were never paging-file residents. It is tempting because pagefile artefacts do aid memory forensics, and this would be correct if the evidence had been recovered from a hibernation or memory image.

The SSD controller performed wear leveling, moving data to unallocated blocks

Why it fails: Wear levelling relocates writes to fresh blocks, but TRIM, not levelling alone, zeroes deleted LBAs on a powered-off SSD. It is tempting because levelling genuinely complicates SSD recovery, and this would be correct if the deleted data had merely moved to unallocated blocks rather than reading as zeros.

The imaging tool incorrectly interpreted the data due to encryption

Why it fails: Encryption alters stored bytes but does not convert deleted file content to zeros; a misreading would yield ciphertext or unreadable data, not uniform nulls. It is tempting because encrypted SSDs do complicate acquisition, and this would be correct if the image showed scrambled, high-entropy sectors instead.

Check the Docker daemon logs for container start/stop events

Why it fails: The Docker daemon logs, typically written via systemd journal or /var/log/docker.log, record lifecycle events such as container start, stop, kill, and network connect/disconnect. They do not capture the commands executed inside a container, nor do they store the stdout/stderr generated by those commands. While such logs can confirm a container existed and when it ran, they are insufficient for reconstructing the user's in-container actions.

Use `docker inspect` on the container ID

Why it fails: docker inspect retrieves metadata about a container object, including its configuration, state, mounts, and network settings, but it does not expose a history of commands run inside the running container or any captured output. The Inspect command will show the Image, Cmd, and Entrypoint from the container's configuration, which are the processes defined at container creation, not the interactive bash or shell commands that may have been typed later. Therefore, while useful for inventorying the container's properties, it cannot answer the analyst's question about what actually occurred inside during execution.

Examine the container's image layers using `docker history`

Why it fails: docker history enumerates the image layers and displays the build instructions, such as RUN, COPY, and ENV directives, that created each layer. These instructions represent actions taken during the image build process on the authoring machine, not the runtime behavior of a stopped or deleted container. An analyst examining an image with docker history can learn how the image was assembled, but the transient commands executed after the container started, which modify only the ephemeral writable layer, are entirely invisible. Thus, it is not an appropriate method for discovering runtime command execution.

The server redirected the request to the root directory and returned the index page

Why it fails: An HTTP redirect is implemented via 3xx status codes such as 301, 302, or 307, so a redirected request cannot produce a 200 OK for the original URL. If the server had redirected the traversal payload to the root directory, the client would first receive a 3xx response, and only after following that redirect would it receive a 200 for the index page. The question indicates a 200 response to the traversal request itself, which a redirect cannot explain. Moreover, typical directory traversal exploitation does not trigger redirects; the server directly serves the requested file.

The server has a custom 404 page that returns a 200 status code

Why it fails: While some misconfigured web servers do return a 200 status code for custom 404 error pages, this option fails to account for the response body containing the targeted file, such as /etc/passwd. A custom 404 page would return a predefined HTML error page, not the contents of an arbitrary file referenced in the URL. Even if the server incorrectly labels not-found pages as 200, the response would not include the traversal target's data unless the server is also vulnerable and actually processed the traversal. Thus, a 200 status alone is not enough; the body must match the requested file, which points to traversal, not a custom error page.

The request was blocked by a web application firewall (WAF) which returned a 200 status

Why it fails: Web application firewalls (WAFs) typically block malicious requests by returning HTTP error status codes like 403 Forbidden or 406 Not Acceptable, or by dropping the connection entirely; a 200 OK response indicates the request passed the WAF and was processed by the application. If a WAF intercepted the request, it would not serve the contents of /etc/passwd; instead, it would return a block notification or error page. The presence of a 200 with file content means the request reached the backend server, which then exploited the traversal. Therefore, a WAF response cannot explain the observed behavior without contradicting standard WAF semantics.

Binary log

Why it fails: The binary log is designed for replication and point-in-time recovery, not query auditing, so it records events describing changes to data—such as INSERT, UPDATE, DELETE, and DDL—rather than read-only operations. In statement-based format it stores the SQL text of modifying statements, and in row-based format it stores the before/after images of changed rows, but pure SELECT exfiltration queries never appear. Thus an attacker using SELECT to download records leaves no trace in the binary log, making it a poor choice for detecting exfiltration.

Slow query log

Why it fails: The slow query log captures only queries whose execution time exceeds the long_query_time threshold, or those that fail to use an index when log_queries_not_using_indexes is enabled. An attacker can easily exfiltrate data with many fast, indexed, or short queries that complete in milliseconds, so none of them would meet the slow-query threshold and be recorded. It therefore provides at best a partial and biased picture of database activity, missing exactly the quick, batch-retrieval queries typical of automated exfiltration.

Error log

Why it fails: The error log records MySQL server operational issues such as startup/shutdown messages, crashes, access-denied errors, replication errors, and InnoDB recovery messages but contains no record of individual SQL statements or successful read operations. Because data exfiltration typically succeeds without generating errors, an attacker's SELECT queries would never be reflected in the error log. It is useful only for identifying anomalies in server state, not for tracing the actual data access that a forensic analyst needs.

A man‑in‑the‑middle attack

Why it fails: A man-in-the-middle (MITM) attack requires evidence of an active third party intercepting, decrypting, or modifying traffic between two endpoints. In this capture, we see only a SYN, SYN-ACK, and a single RST — there is no sign of ARP spoofing, SSL certificate tampering, or any redirected traffic. The RST is simply a TCP-level response, not an indication that session data was ever intercepted or altered. A MITM would generate a completely different sequence, typically with duplicated or modified packets and an established session, which is absent here.

A denial‑of‑service (SYN flood) attack

Why it fails: A SYN flood denial-of-service attack is characterized by a rapid, massive burst of SYN packets sent to a target, usually with spoofed source IPs, in order to exhaust the server's TCP half-open connection queue. The capture shows a single SYN/SYN-ACK/RST sequence, not thousands or millions of SYN packets, and the RST occurs after receiving the SYN-ACK — meaning this is the scanning host aborting a handshake, not a victim being overwhelmed. A true SYN flood would never reply with an RST from the sender as part of the attack, and the volume here is far too low. Thus, this packet sequence cannot represent a DoS flood.

A normal HTTPS session initiation

Why it fails: Normal HTTPS session initiation would follow the standard TCP three-way handshake: client sends SYN, server replies with SYN-ACK, and the client completes the handshake with an ACK. Instead, this capture shows the client responding with an RST (reset) after the SYN-ACK, which abruptly terminates the connection before any TLS handshake (ClientHello, CertificateExchange, etc.) could occur. An RST is an explicit abort signal, not a legitimate continuation of the connection setup. Therefore, this is not indicative of a normal HTTPS connection, which would require a completed TCP handshake and subsequent TLS negotiation.

The registry run key location

Why it fails: The registry run key location indicates a persistence mechanism that allows the malware to launch automatically on startup. However, this local artifact only helps with host-based detection and cleanup; it does not prevent the malware from communicating with its command-and-control server. An attacker can easily change the run key or use other persistence methods, making it a weak indicator for immediate network containment. The C2 IP address is far more actionable because it can be blocked at the egress firewall.

The sample's MD5 hash

Why it fails: The MD5 hash uniquely fingerprints this exact malware binary, which is valuable for searching threat intelligence feeds and detecting identical samples across endpoints. Yet from a dynamic analysis perspective, the hash reveals nothing about the malware's current network behavior, so it cannot be used to interrupt communication. Additionally, an MD5 hash is trivially changed by recompiling the binary, so it is not a stable target for blocking. The immediate response should focus on the observed C2 IP to sever the active channel.

The mutex name 'Global\MyMaliciousMutex'

Why it fails: The mutex 'Global\MyMaliciousMutex' is a synchronization object the malware creates to ensure only one copy runs, and its name can aid in threat hunting on infected hosts. However, detecting the mutex requires already having visibility into the host, and it does not stop the malware from communicating with its C2 server. Mutex names are also frequently randomized or per-sample, making them unreliable for network-level blocking. A firewall rule against the C2 IP is a direct and universal mitigation, whereas mutex detection is only a local signal.

Process hollowing

Why it fails: Process hollowing creates a suspended process, replaces its original executable image with malicious code, and then resumes the process. The injected payload is mapped as a private memory region with its own PE headers and is not part of the heap segments that malfind inspects. Malfind's heuristic identifies executable writable regions containing code-like patterns, but process hollowing's code resides in a section-backed mapping or a freshly allocated region rather than in heap allocations, so it would not be the technique directly diagnosed by malfind.

DLL injection

Why it fails: DLL injection typically forces a target process to load a DLL by calling LoadLibrary through a remote thread. The DLL is mapped as a MEM_IMAGE region with its own sections and proper file backing, not as a heap allocation. Volatility's malfind plugin specifically scans for private executable heap pages that often contain sprayed shellcode, so a legitimately loaded DLL would not exhibit the same heuristic signature. Instead, DLL injection is more reliably exposed by dlllist, ldrmodules, or the injects plugin.

Reflective DLL loading

Why it fails: Reflective DLL loading manually maps a DLL from memory into a process without using LoadLibrary, usually by allocating private memory via VirtualAlloc and copying image sections. Although the resulting allocation may be executable and writable—and thus could be flagged by malfind—it contains a complete PE structure rather than the repeated filler pattern characteristic of heap spraying. A reflective DLL is a stealthier image mapping that preserves the shape of a DLL, whereas heap spraying populates the heap with numerous small blocks of code. Therefore, while both are memory-resident, malfind's heap-oriented heuristics point specifically to heap spraying, not reflective DLL loading.

Foremost

Why it fails: Foremost is a file carving tool that relies on raw disk images to recover files based on magic header/footer signatures. It only sees the data that the operating system or a given image exposes, and it does not issue ATA commands to query or unlock the Host Protected Area (HPA) or Device Configuration Overlay (DCO). As a result, any data intentionally hidden in these hidden regions remains invisible to Foremost, making it unsuitable for this investigation.

WinPmem

Why it fails: WinPmem is a memory acquisition tool specifically designed to capture the contents of physical RAM for volatile memory analysis. It does not interact with disk hardware at the ATA interface level and has no functionality for detecting or reading hidden regions like HPA or DCO. While valuable for investigating memory-resident artifacts, WinPmem cannot access data hidden in disk areas that are hidden from the OS, so it is not the right choice here.

PhotoRec

Why it fails: PhotoRec is a file carving utility focused on recovering photos, videos, and other files from raw disk images or live filesystems. Like Foremost, it only processes the data visible to the filesystem or a supplied image and lacks the low-level ATA commands needed to detect the presence of HPA or DCO. Accordingly, PhotoRec would completely ignore any malicious data hidden in these protected disk regions, rendering it ineffective for this suspicion.

No, RAID 5 requires all disks to be present

Why it fails: The assertion that RAID 5 requires all disks to be present is incorrect because RAID 5 is specifically designed to tolerate a single disk failure without losing access to data. The storage controller or software RAID driver can service reads and writes by logically recreating the missing block from the surviving disks' data and parity on demand. After the failed disk is installed, the controller performs a background rebuild, but until then the array continues to function correctly in degraded mode with one disk absent.

Yes, but only if the failed disk is the parity disk

Why it fails: This answer reflects a misconception that RAID 5 includes a dedicated parity disk, but RAID 5 actually distributes parity blocks evenly across all member disks. Therefore, no single disk is exclusively the 'parity disk'; each disk contains a mix of data and parity for different stripe ranges. Since parity exists on every disk, the loss of any one disk—no matter which one—can be recovered using the combination of data and parity on the other two disks, so recovery is not conditional on which disk failed.

No, because RAID 5 does not support hot swapping

Why it fails: Hot swapping is a capability of the drive enclosure and controller to safely remove and replace a disk while the server is running; it is not a requirement for RAID 5's data reconstruction logic. Even if the system must be powered down to swap the drive, the RAID controller still uses the parity data on the surviving disks to reconstruct the missing drive's contents during the subsequent rebuild. Thus, the absence of hot-swap support has no bearing on the fundamental ability to recover data from the remaining disks after a single disk failure.

SQL injection

Why it fails: SQL injection exploits improperly sanitized input to alter SQL queries executed by the database, typically using tokens like UNION or single quotes, and yields database records, not operating system file listings. The pcap's 'cmd' parameter and resulting directory listing are characteristic of server-side command execution, which SQL injection cannot directly produce unless chained with xp_cmdshell or a similar database-specific feature, an unlikely and indirect mechanism. Therefore, this traffic pattern does not match classic SQL injection.

Directory traversal

Why it fails: Directory traversal abuses unvalidated file paths, sending sequences like ../../../etc/passwd to make the application read arbitrary files from the filesystem, returning file contents—not a dynamic command result. A webshell scenario, by contrast, passes an OS command through a parameter such as 'cmd' and returns the command's execution output, such as a directory listing. The observed command parameter and listing are functional evidence of remote code execution, not merely path manipulation.

Cross-site scripting (XSS)

Why it fails: Cross-site scripting works by injecting JavaScript or HTML payloads that execute in the victim's browser, targeting other users or the session context, not the web server's operating system. The captured traffic shows the server executing a command and returning a directory listing, which requires server-side interpretation of the 'cmd' parameter—something XSS cannot achieve because it runs client-side only. Therefore, XSS is not a plausible classification for this pcap.

File carving techniques do not work on RAID volumes

Why it fails: Carving can work if data is not overwritten, but rebuild increases overwrite.

The file system becomes corrupted after rebuild

Why it fails: RAID rebuild does not corrupt file system; it restores redundancy.

The RAID controller encrypts data, preventing direct disk access

Why it fails: RAID 5 does not inherently encrypt.

Brute force attack

Why it fails: A brute-force attack requires many repeated authentication attempts (typically thousands) to guess credentials or session tokens. This log entry shows a single GET request containing a carefully crafted encoded traversal sequence, so it exhibits none of the iterative volume or timing pattern of brute force. The payload is aimed at file-system access, not at password or session guessing, making the classification invalid.

Cross-site scripting

Why it fails: Cross-site scripting (XSS) works by injecting executable client-side scripts, such as <script> tags or event handlers, that run in a victim's browser when a page is rendered. The captured request contains no HTML tags, JavaScript, or HTML-escaped equivalents; instead, ..%5c.. is URL-encoded for a backslash and decodes to ..\.., a server-side path traversal attempt. Since the payload never reaches a browser as markup, the XSS classification does not apply.

SQL injection

Why it fails: SQL injection hinges on injecting SQL meta-characters (e.g., quotes, semicolons, UNION SELECT) into a query string to alter its logic or merge statements. This request contains no SQL keywords, quotation marks, or a malformed query fragment — the punctuation present is a URL-encoded backslash and a question mark. It is targeting the file system via a path escape, not a database back end, so the SQL injection verdict cannot be correct.

HKLM\SAM\SAM\Domains\Account\Users

Why it fails: The HKLM\SAM\SAM\Domains\Account\Users key is the core of the Security Accounts Manager database, storing user account SIDs, group memberships, and password hashes (often in the V value). It contains absolutely no plug-and-play device enumeration data, such as USB vendor IDs, product IDs, or serial numbers. While a forensic examiner may parse this hive to identify user accounts or recover login artifacts, it is irrelevant to tracing USB storage device history because USB device records are maintained by the System hive's Enum branch, not by the SAM hive.

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Why it fails: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 is a per-user registry key that caches shell namespace mount points for volumes and drives, represented by volume GUIDs like {abcdef01-1234-5678-9abc-def012345678}. It records drive-letter assignments and autoplay-related settings, but it does not store the device's USB vendor, product, or serial identifier—those fields live under SYSTEM\CurrentControlSet\Enum\USBSTOR. Additionally, this key can include non-USB volumes such as network shares and internal partitions, making it a weak and ambiguous indicator of USB device usage compared to the authoritative hardware enumerator.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Why it fails: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList contains a subkey for each user profile, keyed by the user's SID, with values such as ProfileImagePath, RefCount, and State that map SIDs to local user profile directories. It does not enumerate hardware or USB devices at all; its purpose is to maintain profile loading and cleanup data, and any USB-related artifact would be absent by design. Analysts may use this key to link a user SID to a profile folder when correlating user activity, but it cannot serve as a source for USB device usage history.

A user account was created for backupadmin on FS01

Why it fails: This option misidentifies the event's purpose. Event ID 4644 is a logon event, not an account creation event; user account creation is recorded under Event ID 4720 in the Security log. Nothing in a 4644 logon event would indicate that a new user named backupadmin was provisioned on FS01.

A service was installed under the backupadmin account

Why it fails: This option confuses a logon event with a system configuration change. Installing a service under a specific account generates Event ID 7045 (System log) or Event ID 4697 (Security log), not 4644. A 4644 explicit-credential logon simply shows that credentials were used to authenticate, not that a service was installed using those credentials.

The backupadmin account locked out due to multiple failed attempts

Why it fails: This option conflates a successful explicit-credential logon with an account lockout. A lockout due to repeated failed password attempts is logged as Event ID 4740, and a 4644 event indicates a single successful or attempted logon with explicit credentials, not a threshold of failures. The absence of preceding failure events would further rule out a lockout scenario.

Systemd service

Why it fails: Systemd services are managed through unit files with a .service extension, stored under /etc/systemd/system or /lib/systemd/system. While they are a common mechanism for starting persistent daemons or processes at boot, they are not appropriate for scheduling recurring tasks such as the one found in this investigation. The presence of an entry in /etc/cron.d would be characteristic of a cron job, not a systemd service, and systemd units would typically have distinct configuration keys like ExecStart or Restart. Even if a systemd timer could mimic cron's behavior, a .service unit alone does not define a schedule.

Init script

Why it fails: Init scripts, located in /etc/init.d/, are legacy SysV init shell scripts that start and stop services during system boot or runlevel changes. They are executed once when the system transitions to a runlevel, not on a recurring schedule. Finding a file in /etc/cron.d is not an init script, as those scripts usually have names matching a service and are symlinked into /etc/rc*.d. The presence of a cron entry with a time specification clearly points to cron, not an init script, which lacks the syntax for defining periodic execution intervals.

At job

Why it fails: At jobs, defined with the at command and stored in /var/spool/cron/atjobs or /var/spool/at, are used to execute a command once at a specific future time, not on a recurring schedule. Unlike cron jobs, at jobs do not use time fields that specify periodic intervals; they instead use a daemon that waits until the scheduled exact time and then runs the job. A file in /etc/cron.d is not an at job because at jobs are not stored in that directory, and their content would include a date/time specification, not the standard cron time columns. Forensic investigators would find at jobs in a spool directory, not under the /etc/cron.d system-wide cron configuration.

HTTPS tunneling

Why it fails: HTTPS tunneling, while encrypting the HTTP payload, does not randomize the User-Agent header—it merely hides it from a passive packet capture. A proxy log will typically record the TLS Server Name Indication (SNI) and the source/destination IPs, but the User-Agent sits inside the encrypted application data and is not part of the TLS handshake. Thus, even if the analyst is seeing decrypted/reassembled traffic, HTTPS only affects observability; it cannot explain why the client is sending different User-Agent values.

IP spoofing

Why it fails: IP spoofing is a Layer 3 technique that forges the source address in the IP header and would therefore change the apparent source IP, not the User-Agent. Moreover, an attacker carrying out a full TCP request/response session cannot reliably spoof the source IP because the three-way handshake would fail when SYN-ACK packets are sent to the nonexistent host. Proxy logs capture the actual socket-level client address from the established TCP connection, so the differing values the analyst observes are application-layer User-Agent headers, not altered network addressing.

Domain generation algorithm (DGA)

Why it fails: A Domain Generation Algorithm (DGA) creates numerous pseudorandom domain names to rotate command-and-control destinations and evade domain reputation lists, but it has no effect on HTTP header fields such as User-Agent. DGA activity appears in proxy logs as a high diversity of hostnames or FQDNs, whereas the repeated requests in this scenario show diverse User-Agent strings against the same destination. Therefore, DGA is the wrong answer because it explains domain flux, not HTTP-level header mutation.

It can detect malware by signature scanning

Why it fails: Plaso log2timeline is not a malware scanner, so it does not use signatures, hashes, or YARA rules to identify malicious code. Instead, it parses artifacts and extracts timestamps to build timelines. Although a timeline may expose suspicious patterns, the actual malware detection would be performed by specialized tools.

It generates a timeline only from Windows Event Logs

Why it fails: Plaso log2timeline is not limited to Windows Event Logs; it supports dozens of parsers for Unix syslog, macOS unified logs, web history, registry, and file system metadata. This multi-source coverage is fundamental to its timeline creation, allowing cross-platform analysis. A Windows-only focus would overlook these built-in capabilities.

It encrypts the timeline for secure storage

Why it fails: Plaso log2timeline's output is written to formats such as SQLite, CSV, or JSON; encryption is not a built-in or primary feature. If secure storage is required, the analyst would rely on full-disk encryption or separate encryption tools. Thus, this option misidentifies Plaso's core function, which is timeline generation, not data protection.

/var/log/syslog

Why it fails: /var/log/syslog is a general-purpose logging facility that aggregates kernel, daemon, and application messages; on most distributions SSH authentication activity is typically logged to /var/log/auth.log or /var/log/secure, not the default syslog file. Even if authentication messages appear in syslog, it records events such as successful or failed login attempts with timestamps and client IPs, not the static contents of user configuration files. Thus, unauthorized keys would never be listed in syslog; at most, it might show a connection that used a newly added key, but not the key itself.

/etc/ssh/sshd_config

Why it fails: /etc/ssh/sshd_config is the SSH daemon's configuration file, not a credential store. It controls directives such as PermitRootLogin, PubkeyAuthentication, and AuthorizedKeysFile, which defines the default path to the authorized_keys file (normally ~/.ssh/authorized_keys). While an investigator should inspect it to detect changes like enabling root login or redirecting AuthorizedKeysFile to an alternate location, the file does not contain the actual public key material that would appear after an attacker appends a key.

/etc/passwd

Why it fails: /etc/passwd is a structured database of local user accounts containing fields for username, UID, GID, home directory, and login shell, but it does not hold SSH keys; password hashes are kept in /etc/shadow for security. If an attacker created a new user for backdoor access, that user would appear in /etc/passwd, but the authorized_keys for that new user would reside in their home directory (e.g., /home/username/.ssh/authorized_keys). Therefore, /etc/passwd alone would not reveal key-based persistence, only the existence of potentially suspicious accounts that might warrant further examination.

Notifying all employees to preserve documents related to the lawsuit.

Why it fails: Issuing a legal hold notice to all employees is a foundational step in implementing the litigation hold; it does not alter, destroy, or risk losing any data. Rather, it instructs custodians to suspend normal retention practices and preserve potentially relevant ESI. While a hold notice alone may be insufficient without enforcement, the act of notification itself is compliant and expected under the duty to preserve.

Suspending routine deletion of emails older than 30 days.

Why it fails: Suspending the routine 30-day email purge is exactly the kind of action a legal hold demands, because it prevents the automatic destruction of messages that may be relevant to the lawsuit. An email older than 30 days could contain discoverable content, so stopping the scheduled deletion safeguards that ESI. This measure is a standard preservation protocol and does not violate the hold.

Taking a forensic image of the relevant servers.

Why it fails: Taking a forensic image of the relevant servers is a defensive and preservation-focused action; it creates a bit-for-bit copy of the storage media, capturing active files, metadata, and even deleted data that might later become evidence. Far from violating the hold, this imaging demonstrates an active effort to preserve the status quo and to establish a chain of custody for potential litigation. It is a best practice when a hold is issued, not a breach of it.

The file is a Chrome extension

Why it fails: A .jumplist file records recent and pinned items for a Windows application's taskbar jump list, not a Chrome extension. It tempts because the filename contains 'chrome', but the extension is the .jumplist suffix. This artefact would be relevant when examining user activity for recently opened files.

The user has installed Chrome via a jump list installer

Why it fails: Jump lists are a Windows shell feature, not an installer; Chrome is installed via its own installer or package manager. It tempts because 'jump list' appears in the filename, but the artefact records application activity. This would be relevant when tracing how software was deployed.

The file contains Chrome bookmarks

Why it fails: Bookmarks are stored in Chrome's Bookmarks JSON file, not in a .jumplist, which records recent and pinned jump list entries. It tempts because both relate to browsing activity, but the format and purpose differ. This artefact would be relevant when reconstructing recently accessed items.