Refer to the Exhibit Practice Questions

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.

Conduct a thorough static analysis using a disassembler and debugger to understand the code

Why wrong: Static analysis with a disassembler and debugger is foundational for revealing code structure, but it cannot capture behaviors that manifest only under specific runtime conditions, such as a live command-and-control (C2) channel. Malware often employs anti-analysis techniques like packing, obfuscation, and anti-debugging, or it may deliberately wait for network responses before executing its payload. Debugging can also alter timing and trigger defensive routines, so static analysis alone is insufficient to observe the full attack sequence, especially network-dependent activity.

Delete the suspicious file and run a full antivirus scan on the system

Why wrong: Deleting the suspicious file destroys probative evidence and undermines forensic integrity, while a full antivirus scan relies primarily on signature-based detection that is ineffective against unknown, polymorphic, or fileless malware. Even if the scan flags the file, it does not reveal the malware's behavior, C2 infrastructure, or impact. Proper procedure requires preserving the original sample through forensic imaging, then performing dynamic analysis in a controlled environment to understand the threat, not summarily deleting it.

Perform a forensic imaging of the system again and compare with the original image

Why wrong: Performing a forensic imaging of the system again and comparing it with the original image will only show file-system changes, such as new files or altered timestamps, but it cannot reveal the malware's runtime behavior or the content of its C2 communications. Re-imaging is a preservation and evidence-integrity process, not an analytical technique for inducing or observing malicious actions. To understand the sample's network activity and payload, one must perform dynamic analysis in a sandboxed environment with controlled connectivity, not repeat forensic imaging.

The forensic image was not acquired with a write-blocker, causing data corruption.

Why wrong: The absence of a dedicated hardware write-blocker is a limitation of the acquisition chain, but the command history here shows `diskpart` operations, not the actual imaging utility; there is no evidence that the source drive was written to during acquisition. Corruption from a missing write-blocker would manifest as read errors or altered hash values in the original device, not as filesystem-integrity errors reported by e2fsck from inside the image. The e2fsck findings point to an inconsistency in the filesystem state itself, which is directly explained by an unclean dismount, rather than by external hardware writes.

The image file contains an NTFS filesystem, but e2fsck is designed for ext filesystems.

Why wrong: e2fsck is designed for ext-family filesystems, but it does not simply 'work on NTFS'; it first validates the superblock magic number and would immediately terminate with a message like 'Couldn't find a valid filesystem superblock' or 'bad magic number'. The detailed errors about group descriptors, inode bitmaps, or the like are ext-specific structures, so the image must actually contain an ext filesystem that was imaged while inconsistent. Therefore, the problem is not that the tool was run on NTFS; the tool's output itself proves the media is ext-based.

The e2fsck command syntax is incorrect; it should be 'e2fsck -f -n' instead.

Why wrong: The invocation `e2fsck -fn` is a valid and common shorthand; like `-f -n` it forces the check even if the filesystem is marked clean and opens the filesystem read-only so no changes are made. Combined single-letter switches are standard for e2fsck, so `-fn` is not the reason the check surfaces recoverable inconsistencies. If the analyst had used `-p` or omitted `-n`, the tool might have written repairs, but that would be a separate operational concern, not a syntax error.

A hidden file was permanently removed from the filesystem.

Why wrong: The syslog message describes a deleted orphan inode, not a hidden file. An orphan inode is an inode whose directory entry was removed while it was still open by a process, and the filesystem performs cleanup on the next mount. Hidden files are ordinary directory entries beginning with a dot, and the kernel message does not reference any filename or dotfile state. Thus the message indicates a normal unlink-while-open event, not the permanent removal of a hidden file.

A rootkit has attempted to hide files by marking them as orphan inodes.

Why wrong: The orphan inode message is generated by the kernel's filesystem layer during mount/recovery and refers to inodes that were open at the time of an unlink. Rootkits typically hide files by intercepting system calls or manipulating directory entries; they do not 'mark' inodes as orphaned, because an orphan inode is not a hidden file but one that has already lost its directory entry. Userspace processes cannot set an inode's orphan state, and this log line contains no evidence of rootkit activity.

A critical system file has been deleted, and the filesystem is warning the administrator.

Why wrong: The log message does not identify any particular file or inode, and it is an informational cleanup notice, not a system warning. A 'critical system file' is an administrative classification that the filesystem never evaluates; orphan inode cleanup applies equally to any open-but-unlinked file, such as a temporary database file or a rotated log. Even if a critical file were deleted, this message would not indicate which one or whether the loss was intentional.

It is a sign that a rootkit has hidden files in the image

Why wrong: The presence of $OrphanFiles is a routine artifact produced by file-system analysis tools (such as The Sleuth Kit) when they encounter file records that are not referenced by any directory entry. It reflects the state of the disk after deletion or corruption of directory structures, not any active concealment by a rootkit. Rootkit file-hiding typically relies on kernel-mode API hooking or direct manipulation of MFT attributes, which would not generate a virtual directory with that canonical name in a forensic image.

It indicates the location of the Master File Table (MFT) mirror

Why wrong: $OrphanFiles is not a pointer to or an indicator of the Master File Table (MFT) mirror. On NTFS, the MFT mirror is anchored at the file named $MFTMirr (metadata file number 1), which is a redundant copy of the first few MFT records stored near the middle of the volume. In contrast, $OrphanFiles is a conceptual virtual directory that forensic tools construct to present orphaned MFT entries, and it has no corresponding on-disk metadata file or location.

It is a standard NTFS metadata file that stores file permissions

Why wrong: $OrphanFiles is not one of the standard NTFS metadata files such as $MFT, $LogFile, or $Secure. Standard NTFS metadata files reside in the MFT with fixed record numbers and specific system-defined purposes, such as tracking security descriptors or the volume's file list. $OrphanFiles is not present on the volume at all; it is a synthetic grouping created by forensic software to aid the examiner in reviewing unlinked file records, so it does not store file permissions or any other metadata.

The MySQL user does not have write permissions to the data directory.

Why wrong: If the MySQL OS account lacked write permission to the data directory, startup would fail earlier with explicit 'Permission denied' or 'Can't create/write to file' errors when opening or creating files. Inode and file-access checks happen before InnoDB reads the system tablespace header. An InnoDB corruption error like 'Cannot open datafile' or 'Database page corruption' is not a permission complaint, so this hypothesis does not match the exhibit.

The binary log is full and cannot be rotated.

Why wrong: The binary log records committed transactions and is written after the storage engine accepts them; it is never read during InnoDB initialization or crash recovery. A full binary log or a log-rotation failure would generate runtime errors such as 'Could not write to binary log' or 'disk full' at commit time, not an InnoDB tablespace header failure. InnoDB recovery relies on redo logs (ib_logfile*), not binlogs, so a binlog problem cannot prevent InnoDB from loading ibdata1.

The server ran out of memory due to high innodb_buffer_pool_size.

Why wrong: An oversized innodb_buffer_pool_size might trigger the OS out-of-memory killer or an 'InnoDB: Cannot allocate memory' error before any tablespace file is opened. Memory allocation failures typically appear as 'Out of memory' or a process kill, not as a datafile corruption or checksum mismatch. The exhibit's error indicates a persistent I/O or integrity problem in ibdata1, not a transient memory shortage, so this explanation is inconsistent with the observed message.

The connection to 192.168.1.1:80 is suspicious because it is in TIME_WAIT state.

Why wrong: TIME_WAIT is a standard TCP closure state that occurs after a connection has been gracefully closed; the socket lingers briefly to handle any delayed segments. Seeing a connection to 192.168.1.1:80 in TIME_WAIT simply indicates a completed HTTP exchange, such as a web request, and is not inherently suspicious. Attackers can establish connections that end up in TIME_WAIT too, but the state itself is not a reliable indicator of compromise.

The UDP listener on port 5353 indicates a malware infection.

Why wrong: UDP port 5353 is the default port for multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), commonly used by Bonjour, AirPlay, and many network-aware applications for local device discovery. A listener on this port is typically benign background functionality enabled by default on workstations and does not by itself indicate malware. While some malicious tools could use the same port, the mere presence of a UDP listener without associated anomalous outbound traffic is weak evidence of infection.

The workstation is running multiple virtual machines based on the local addresses.

Why wrong: The local address shown for the connections is a single IP address (e.g., 192.168.1.2), which does not suggest the presence of multiple virtual machines. Virtual machines each have their own virtual network interface with distinct IP addresses (or separate loopback adapters), and netstat would list those addresses among the local entries. Moreover, virtual machine traffic is typically bridged or NATed, so the lack of multiple local addresses means this reasoning is unsupported by the exhibit.

services.exe PID 4321 is a known malware process

Why wrong: services.exe is the Windows Service Control Manager, a legitimate system process responsible for managing services, and its PID is assigned dynamically at boot. There is no known malware variant called 'services.exe' that can be identified by PID alone; malware authors frequently reuse the same file name to blend in, so the PID does not constitute a threat indicator.

Windows Defender service is stopped, allowing malware to run

Why wrong: The exhibit displays a service state of 4, which corresponds to SERVICE_RUNNING in the Windows SCM, not a stopped state. When a service is stopped, the state code is 1 (SERVICE_STOPPED), so Windows Defender is demonstrably active in this output. Even a running antivirus does not guarantee the system is clean, but the specific assertion that Defender is stopped is contradicted by the evidence.

svchost.exe hosting BFE and MpsSvc indicates a firewall bypass

Why wrong: svchost.exe is a shared host process that loads dozens of Windows services from DLLs, and BFE (Base Filtering Engine) plus MpsSvc (Windows Firewall) are expected residents in a standard svchost instance. Their presence simply reflects normal service hosting, not a firewall bypass. A real bypass would require evidence such as disabled firewall rules, a tampered filter driver, or a malicious DLL injected into the service host, none of which appears in this exhibit.

The DNS query to 192.168.1.1:53 in TIME_WAIT state.

Why wrong: A DNS query to 192.168.1.1:53 is routine internal infrastructure traffic, not an IOC: 192.168.1.1 is the typical default gateway and recursive resolver in SOHO networks. TIME_WAIT is a TCP state that only appears after a closed connection, and it simply indicates the client completed an exchange; DNS normally uses UDP, but a TCP fallback for large responses or zone transfers is legitimate. There is no external destination, no unusual port, and no encrypted channel that would hide malicious payloads.

The UDP listener on port 5353 (mDNS) with PID 910.

Why wrong: mDNS (port 5353/UDP) serves zero-configuration hostname resolution on the local link, using multicast address 224.0.0.251, so a device with PID 910 advertising or browsing services through it is normal consumer/enterprise behavior. It is a passive listening socket, not a connection to a remote host, and its multicast nature means traffic never leaves the local segment. Unless a rogue process is bound to all interfaces or paired with another IOC, it does not represent a compromise.

The listening RDP service on port 3389 (PID 1234).

Why wrong: An RDP service listening on 3389 is a default configuration for Windows servers and VDI hosts; in itself it is neither evidence of intrusion nor of lateral movement. The socket is in LISTEN state, meaning no remote session is active, and PID 1234 can be checked against the trusted services (e.g., termsrv.dll in svchost). While exposing RDP to the internet is risky and would warrant a risk note, in this netstat snapshot it is not the suspicious indicator.