Hard Difficulty Questions

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

Why wrong: Paging file is on disk, not volatile.

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

Why wrong: Wear leveling moves data but does not zero out deleted files.

The imaging tool incorrectly interpreted the data due to encryption

Why wrong: Encryption would not result in zeros; it would produce ciphertext.

Check the Docker daemon logs for container start/stop events

Why wrong: 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 wrong: 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 wrong: 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.

File carving techniques do not work on RAID volumes

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

The file system becomes corrupted after rebuild

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

The RAID controller encrypts data, preventing direct disk access

Why wrong: RAID 5 does not inherently encrypt.

Notifying all employees to preserve documents related to the lawsuit.

Why wrong: 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 wrong: 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 wrong: 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.

Google account tokens stored in AccountManager

Why wrong: Could be recoverable from /data/system/.

System logs in /data/log/

Why wrong: Some logs may persist after reset.

Deleted text messages from SQLite files

Why wrong: May be partially recoverable from unallocated space.

It cannot be used with USB drives

Why wrong: Software write blockers are interface-agnostic; they operate at the logical volume or file system layer, intercepting write commands before they reach storage. With proper configuration, such as mounting volumes read-only via the OS or using a filter driver, they can be used with USB-attached media. The assertion that USB drives are unsupported is incorrect—the underlying USB mass storage device is still presented as a block device, and the same blocking mechanisms apply. The real challenge with USB is not interface incompatibility but ensuring the OS driver stack does not allow direct SCSI commands that bypass the filter.

It does not support hashing algorithms for integrity

Why wrong: Hashing algorithms are not a component of write blockers at all; they are executed by separate forensic acquisition or integrity-verification tools. Software write blockers provide read-only access to the storage medium, while the analyst uses an external utility (e.g., FTK Imager, EnCase) to compute MD5, SHA-1, or SHA-256 hashes on the acquired image. The absence of built-in hashing in a software blocker does not affect integrity verification because the hash calculation operates independently of how the underlying device is accessed. Therefore, claiming that software write blockers fail to support hashing algorithms is a misunderstanding of the forensic acquisition workflow.

It is more expensive than hardware write blockers

Why wrong: In practice, software write blockers are significantly less expensive than hardware write blockers—often free or costing only a modest licensing fee. Hardware write blockers are dedicated physical devices with specialized chipsets and firmware, which inherently carry manufacturing and R&D costs, putting them in the hundreds or thousands of dollars. Software blockers run on a standard forensic workstation and require no additional hardware investment, making them the economical choice for many labs. The cost disparity is a well-known advantage of software solutions, not a limitation.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

Why wrong: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB exposes PnP device nodes for every USB device and hub that has ever been enumerated on the system, organized by VID/PID and instance ID. While it confirms that a particular USB peripheral was present, its values are hardware identifiers and configuration data, not forensic timestamps — there is no first connection or install date stored in this key. It may show the parent hub or ContainerID, but it cannot answer when the device was first plugged in, so it is not the correct source.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Why wrong: The DeviceClasses key with GUID {53f56307-b6bf-11d0-94f2-00a0c91efb8b} represents the storage volume device-interface class, which Windows uses to surface volume symbolic links such as \\?\\Volume{GUID}. This key shows that a storage volume (which could be a partition on a USB drive or an internal hard disk) was exposed to user-mode applications, but it does not record the time the USB device was first attached. Because this GUID applies equally to fixed internal disks, it is neither USB-specific nor a first-connection timestamp source.

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

Why wrong: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 stores per-user, MRU-style mount point mappings for volumes the logged-in user has accessed, including entries that reference USBSTOR device paths. However, the timestamps visible in this hive are the LastWrite times of the mount point keys, reflecting when that specific user mounted or accessed the volume, not when the device was first connected system-wide. It can indicate user awareness or use of a USB volume in a user profile, but it cannot supply the device's first-connection timestamp and is therefore incorrect.

Best evidence rule

Why wrong: The best evidence rule is a discrete legal doctrine requiring the original writing, recording, or photograph to prove its content, but it is not one of the three foundational rules of evidence governing digital forensic evidence. In digital forensics, it is satisfied by creating exact bit-for-bit copies verified by hash algorithms, so it functions as a procedural compliance measure rather than an independent evidentiary principle alongside admissibility, authenticity, and completeness.

Chain of custody

Why wrong: Chain of custody is a documentation process used to establish that evidence was continuously controlled and unchanged from the point of seizure through presentation in court, not a defined rule of evidence itself. It is a mechanism for proving authenticity and integrity, and while a broken chain can undermine weight or admissibility, the legal requirement actually being tested is the authenticity rule. Therefore, it is an operational best practice rather than one of the three core evidentiary principles.

Code injection via Reflective DLL

Why wrong: Reflective DLL injection is a sophisticated technique that loads a DLL entirely from memory into a process without relying on the Windows loader, mapping the PE headers and sections manually and resolving imports via a crafted stub. However, this method is fundamentally independent of the TLS directory: it does not require parsing the TLS callback table or executing any TLS callbacks for its unpacking or initialization. The presence of a .tls section would therefore not be an indicator of reflective DLL injection, which instead typically leaves traces such as a manually mapped module with no corresponding file on disk.

Packing with UPX

Why wrong: UPX is one of the most widely recognized packers and it typically compresses the original code into sections named UPX0, UPX1, and UPX2, with the decompressor stub at the entry point, but it does not use a .tls section for its unpacking logic. While UPX can theoretically preserve a TLS section if the original binary had one, the packer itself does not add or rely on TLS callbacks to decompress code; instead, the stub manually unpacks the sections in memory before jumping to the original entry point. Therefore, seeing .tls would not be a hallmark of UPX packing, and a malware analyst would look for the familiar UPX section names rather than a TLS directory.

Anti-debugging via NtGlobalFlag

Why wrong: NtGlobalFlag is a process environment variable located in the Process Environment Block (PEB) at offset 0x68 on 32-bit systems and 0xBC on 64-bit systems, which can be queried by malware to detect a debugger by checking for flags such as FLG_HEAP_ENABLE_TAIL_CHECK. This anti-debugging technique is entirely unrelated to the TLS section, as it relies on reading a specific PEB field and does not define any callbacks or executable code prior to the entry point. The presence of a .tls section would not indicate NtGlobalFlag-based anti-debugging, which is instead typically identified by code that accesses the PEB directly.

Command and control communication

Why wrong: Command and control (C2) communication requires the malware to establish a network channel to an external server, typically via HTTP/HTTPS, DNS, or raw TCP/UDP, to receive instructions or exfiltrate data. The evidence described—a Run key modification—is a purely local registry artifact and contains no indication of network connections, beaconing intervals, or C2 domains. While persistence mechanisms support long-term control, the Run key itself does not constitute or prove C2 communication without accompanying network telemetry.

Anti-forensic technique (timestomping)

Why wrong: Timestomping is an anti-forensic technique that deliberately alters file system timestamps (such as modification, access, and creation times) using APIs like SetFileTime or tools like timestomp, often targeting artifacts to mislead investigators. The addition of a value to the Run key modifies a registry key's last-write time, not file timestamps, and there is no mention of timestamp anomalies on files or directories. This action is an autostart configuration change, not a timestamp manipulation attack, so classifying it as timestomping would be incorrect.

Privilege escalation attempt

Why wrong: Privilege escalation is the process of gaining higher access rights than currently held, typically from a standard user to an administrator or SYSTEM, via techniques such as token manipulation, service exploitation, or vulnerability exploitation. Adding a Run key entry does not by itself change the privileges of the process that runs at logon; it merely schedules an executable to execute with the same user context and integrity level that the interactive session already has. Since it grants no additional privileges or security token rights, it is a persistence mechanism rather than a privilege escalation attempt.

Google account authentication tokens and sync settings

Why wrong: Google account authentication tokens and sync settings are stored in Android's /data partition, specifically within databases such as accounts.db and settings providers. A factory reset logically erases these files, but physical extraction from the raw flash memory can recover residual data from unallocated blocks, often yielding viable tokens and sync timestamps. These artifacts are critically important because they link the device to a specific Google account and reveal cloud synchronization activity, making them a high-value target for forensic analysis.

Deleted SMS messages from the mmssms.db WAL file

Why wrong: Deleted SMS messages in the mmssms.db WAL file are an unreliable source because the Write-Ahead Log (WAL) is subject to automatic checkpointing and truncation during normal operation and factory reset. Even if remnants persist in the WAL, they are typically overwritten or pruned, and recovery depends heavily on device usage after deletion. Unlike account tokens, which leave broader traces in multiple databases, SMS remnants in a truncated WAL are sparse and rarely yield complete, admissible message content.

The user's pattern lock hash stored in gatekeeper.password.key

Why wrong: The pattern lock hash stored in gatekeeper.password.key is invalidated and deleted during a factory reset, as the lock credential database is explicitly cleared to ensure the device is unlocked. Forensic tools cannot simply read this file from a reset device because the gatekeeper service no longer references it, and any residual flash data would be overwritten or rendered obsolete. Therefore, this option is incorrect as a reliable recoverable artifact, especially when compared to account tokens that persist in multiple system databases.

Perform a graceful shutdown via the operating system, then remove the SSD and image it using a hardware write-blocker.

Why wrong: A graceful shutdown is an active operating-system process that writes a large amount of data to persistent storage: registry hives are flushed, event logs are updated, prefetch and Superfetch files are modified, and filesystem metadata/journal entries are committed. Even though using a hardware write-blocker afterwards ensures the SSD image is forensically sound, the shutdown itself has already contaminated the disk and completely destroyed the contents of RAM, including the very processes, network connections, and memory-resident malware that likely triggered the incident. The correct approach is to image volatile memory first, not to shut down the system cleanly.

Boot the workstation from a forensic live CD, then use 'dd' to image the SSD to an external USB drive.

Why wrong: Booting from a forensic live CD alters the system state before any acquisition begins: the boot process overwrites RAM, the live OS may mount the internal SSD and update volume metadata or journal files, and hardware/firmware state is changed by the BIOS/UEFI. A dd image created after booting from the CD therefore captures only the disk's post-boot state and loses the live memory evidence needed to identify active malware, open ports, and encryption keys. Dead-box imaging with dd and a write-blocker is appropriate only when the system is already powered off; starting from a running system, volatile data must be preserved first.

Immediately shut down the workstation by unplugging the power cord, remove the SSD, and create a forensic image using a write-blocker on a forensic workstation.

Why wrong: Unplugging the power cord instantly destroys all volatile memory, eliminating every running process, kernel object, network connection, and encryption key, and it may also leave the filesystem in an inconsistent state because pending writes and SSD FTL mappings were never flushed. While removing the SSD and imaging it with a hardware write-blocker on a forensic workstation is a valid method for acquiring a dead disk, that step should occur only after the machine is no longer a live incident-response target. Performing this first reverses the correct order: the memory image must be captured while the system is running, before any power loss.

The analyst has direct knowledge of the case

Why wrong: Expert witnesses often have no direct knowledge but provide opinion.

The analyst has a certification in computer forensics

Why wrong: Certification helps but is not the sole factor.

The analyst is employed by the prosecution

Why wrong: Employment does not affect admissibility of expertise.

Delete the config.ini file and the conhost.exe executable immediately.

Why wrong: Immediately deleting config.ini and conhost.exe destroys potential digital evidence, including file metadata (creation/modification times) and the actual malware code needed for reverse engineering. Conhost.exe is a legitimate Windows Console Host binary, so its presence alone is not conclusive; without preservation, you cannot determine if it is benign or injected with malicious code. Additionally, if the malware uses persistence mechanisms such as scheduled tasks or Run registry keys, these files may be recreated, and reckless deletion may trigger the malware's anti-forensics or integrity checks, causing further system damage.

Restore the system to a previous restore point.

Why wrong: System Restore only reverts protected system files and select registry keys, leaving many malware artifacts—such as executables in user directories, alternate data streams, or modified DLLs—untouched. It can also overwrite the very restore points and log files that would have documented the infection timeline, destroying critical evidence and corrupting the forensic record. Furthermore, advanced malware can survive restore operations by hiding in volumes shadow copies or by reinstalling itself upon reboot, so this action neither removes the threat nor preserves a sound evidentiary foundation.

Terminate the suspicious conhost.exe process and run a full antivirus scan.

Why wrong: Terminating the conhost.exe process eliminates volatile memory artifacts—such as injected code, decrypted credentials, active network connections, and in-memory payloads—that are invaluable for determining the scope and nature of the compromise. A full antivirus scan on a live, potentially infected system is unreliable because malware can subvert scanning APIs, disable the AV, or hide in memory; signature-based detection also misses unknown or polymorphic variants. Even if the scan finds threats, persistence mechanisms ensure reinfection, while the act of running AV tools alters system state and may alert the attacker, triggering destructive anti-forensic behavior.

Delete the instance immediately

Why wrong: Deleting the instance immediately destroys the very evidence you are investigating: the ephemeral root volume (if not configured to persist) and any forensic artifacts on the ephemeral store vanish, and the instance's memory and process state are lost. AWS termination is not a reversible operation; a terminated instance's EBS volumes are typically deleted (unless the 'DeleteOnTermination' flag was changed), so you lose the ability to perform disk forensics, recover deleted data, or capture malware. Instead, the correct isolation step is to detach or snapshot the volumes and restrict network access, preserving the state while preventing further compromise.

Check the VPC flow logs for network traffic

Why wrong: VPC Flow Logs only record IP traffic metadata—such as source and destination addresses, ports, and byte counts—and reveal nothing about what actually executed on the instance, whether a malicious process is running, or what filesystem changes were made. They are also only useful if they were enabled and capturing data before and during the incident, so they may not even contain the relevant timeframe if logging was not already configured. While examining flow logs is a valuable later step for traceability, it does nothing to stop an active adversary or preserve volatile data, so it is not the immediate action.

Notify the user who launched the instance

Why wrong: The user recorded in CloudTrail who launched the instance is not necessarily an authorized actor—it could be an adversary who gained access to AWS credentials or IAM roles, and informing them gives the attacker the chance to destroy evidence, delete logs, or escalate privileges before you can collect forensic data. Even if the user is benign, notification is an operational decision that should follow your incident response and communication plan, not be made ad hoc during a forensic investigation. In every case, the priority is to preserve evidence and contain the incident, not to contact parties who may themselves be compromised or hostile.

Perform file carving on the PST file using a forensic tool

Why wrong: File carving on a PST file looks for block signatures and attempts to reassemble deleted data from raw disk clusters, but PSTs use a B-tree node database with a block allocation map and blocks that can be fragmented, compressed, and encrypted. Carving may recover isolated fragments or attachments, but it cannot recreate the table-of-contents structure needed to map those fragments back to complete email messages with headers, properties, and folder relationships. Outlook's Recoverable Items folder offers a structured way to recover deleted items that would otherwise require this impractical and unreliable reassembly.

Use a hex editor to manually reconstruct deleted emails

Why wrong: Using a hex editor to manually reconstruct deleted emails requires parsing the PST's private B-tree structure, 4KB block chains, and cyclic redundancy check (CRC) values. Deleted items may reside in free blocks that are no longer referenced by the node B-tree, and rebuilding the required header properties, message properties, and attachment streams by hand is not practical in real casework. It is time-consuming, error-prone, and not a recognized forensic recovery method for PST files.

Use a PST viewer to read the file directly

Why wrong: A PST viewer is designed to read the active folder hierarchy and message tables as stored in the PST's node B-tree, so it only displays undeleted items that are still referenced by the current folder structure. Deleted items that were removed from the Deleted Items folder or emptied are no longer present in the visible folder table, even though their data blocks may still exist. The viewer does not enumerate the Recoverable Items area or free-block space, so it cannot recover deleted evidence on its own.

Brute force attack

Why wrong: 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 wrong: 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 wrong: 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.

VPC Flow Logs

Why wrong: VPC Flow Logs are network-level telemetry that record only the metadata of IP traffic—such as source/destination addresses, ports, protocol, packet and byte counts, and ACCEPT/REJECT decisions—transiting an Elastic Network Interface. They do not capture OS-level activities like shell commands, local process execution, or file system modifications. At most, flow logs could show a connection from the instance to the SSM endpoint, but that is a network artifact, not evidence of what the Systems Manager agent actually executed inside the guest OS.

EC2 instance metadata

Why wrong: EC2 instance metadata is a service accessible from within the instance (via 169.254.169.254 or IMDSv2) that provides configuration details such as AMI ID, instance ID, hostname, security groups, IAM role credentials, and user-data. While user-data can contain a bootstrap script that runs at launch, instance metadata does not record a historical log of commands executed by users or processes after boot. Therefore, examining instance metadata might reveal the instance's intended configuration, but it cannot reveal the actual command history or runtime actions of the analyst's target.

AWS CloudTrail logs

Why wrong: AWS CloudTrail records control-plane API calls made by principals, such as the SendCommand, RunInstances, or DescribeInstanceInformation operations invoked against the AWS Systems Manager API. CloudTrail proves that a command request was made, by whom, and when, but it does not contain the command's actual execution results, guest-OS output, or effects inside the instance. Thus, it is useful for establishing the chain of command, but it cannot substitute for the SSM Agent logs that capture what the instance itself actually executed.

The executable is cleaning up after itself by deleting temporary files

Why wrong: The actions indicate installation, not cleanup.

The executable is a dropper that installs a rootkit

Why wrong: No evidence of rootkit installation; only persistence is shown.

The executable is a legitimate Windows update component

Why wrong: Legitimate Windows Update does not drop 'svchost.exe' in AppData.

No, RAID 5 requires all disks to be present

Why wrong: 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 wrong: 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 wrong: 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.