How many Refer to the Exhibit Practice Questions questions are on this page?

This page has 11 Refer to the Exhibit Practice Questions scenario questions for the CHFI exam, each with detailed explanations and wrong-answer analysis.

How should I approach CHFI scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Computer Hacking Forensic Investigator CHFI questions

Scenario-based practice

Refer to the Exhibit Practice Questions

Practise Computer Hacking Forensic Investigator CHFI practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

CHFI

exam code

EC-Council

vendor

Scenario guide

How to approach refer to the exhibit practice questions

Practise exhibit-style questions that ask you to read a topology, table, command output or diagram before choosing the best answer.

Quick answer

Exhibit-style questions test whether you can read a topology, command output, diagram or table before choosing the best answer.

How to extract the relevant detail from an exhibit.

How topology, command output or routing information affects the answer.

How to avoid answering from memory before reading the evidence.

How to map the exhibit back to the exam objective.

Practice scenarios

Question 1easymultiple choice

Full question →

Refer to the exhibit. During incident response, a first responder runs 'netstat -ano' on a compromised Windows system. Which connection is most likely to be the command-and-control (C2) channel and should be prioritized for isolation?

Exhibit

Refer to the exhibit.

C:\> netstat -ano
Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    192.168.1.100:1045     203.0.113.5:4444      ESTABLISHED     1234
  TCP    192.168.1.100:1046     192.168.1.1:443        ESTABLISHED     5678
  TCP    192.168.1.100:1047     10.0.0.1:22            ESTABLISHED     9012
  TCP    192.168.1.100:1048     198.51.100.7:80        TIME_WAIT       3456

A
192.168.1.100:1045 to 203.0.113.5:4444 (ESTABLISHED)
The established connection from the internal host to 203.0.113.5 on TCP port 4444 is a classic command-and-control indicator: port 4444 is the default listener port for Metasploit's Meterpreter reverse shell, and the destination is an external IP address that would not be in any internal allowlist. The ESTABLISHED state confirms an active, ongoing session, meaning the attacker likely already has a foothold and is maintaining control of the host. Moreover, 203.0.113.0/24 is a documentation range (TEST-NET-3), so its appearance in real traffic should immediately raise suspicion.
B
192.168.1.100:1047 to 10.0.0.1:22 (ESTABLISHED)
Why it fails: This connection to 10.0.0.1 on port 22 (SSH) is a legitimate administrative session to an internal server, not a C2 channel. The destination is a private RFC 1918 address, indicating the traffic stays within the trusted network, and SSH's strong encryption is appropriate for secure remote management. While SSH can be abused for tunneling, there is no evidence of that here—the source port is a normal ephemeral port, and the established state reflects a routine, authorized control session that aligns with standard operational behavior.
C
192.168.1.100:1046 to 192.168.1.1:443 (ESTABLISHED)
Why it fails: HTTPS to 192.168.1.1:443 is likely the internal gateway's management web interface or a captive portal, making this connection benign. The destination is the local router (default gateway) on a private IP, so the traffic never leaves the trusted segment, and the use of TLS provides confidentiality without indicating malicious intent. An established HTTPS connection to a known internal device is expected in a typical network and lacks the external destination and suspicious port pairing that would flag it as command-and-control.
D
192.168.1.100:1048 to 198.51.100.7:80 (TIME_WAIT)
Why it fails: This entry shows an HTTP request to 198.51.100.7 on port 80, but the TIME_WAIT state reveals that the connection is already completing its teardown, meaning no active data exchange is occurring. Short-lived HTTP connections like this are normal for web browsing or API calls, and TIME_WAIT simply indicates the client is waiting for a final ACK to ensure the connection closed cleanly. Command-and-control typically requires persistent, established sessions, so a connection in TIME_WAIT—especially to a documentation-range IP on a common web port—does not align with active attacker communication.

Full breakdown with real-world context →

Question 2mediummultiple choice

Full question →

Refer to the exhibit. During a malware investigation, a forensic analyst runs the commands shown. What is the most likely conclusion?

Exhibit

Refer to the exhibit.

C:\> tasklist /svc
Image Name                     PID Services
========================= ======== ============================================
svchost.exe                   1236 CryptSvc, Dnscache, LmHosts, EventSystem
svchost.exe                   1344 W32Time, WdiServiceHost
svchost.exe                    768 BFE, MpsSvc
notepad.exe                   1456 N/A
svchost.exe                    524 SessionEnv, TermService, UmRdpService
rundll32.exe                  1500 N/A

C:\> netstat -ano | findstr :4444
  TCP    0.0.0.0:4444           0.0.0.0:0              LISTENING       1500

C:\> wmic process where processid=1500 get executablepath
ExecutablePath
C:\Windows\System32\rundll32.exe

A
Svchost.exe processes are hosting legitimate Windows services; no malware is present.
Why it fails: While it is true that Windows routinely runs multiple svchost.exe instances to host a variety of legitimate system services, the exhibit shows a network socket bound to port 4444, which is not a standard service port. Any process, including svchost.exe, listening on port 4444 is highly anomalous and typically indicates a backdoor or command-and-control channel. This option simply dismisses the suspicious connection, so it fails to recognize the evidence of compromise.
B
The malware has injected code into svchost.exe using a reflective DLL injection tool.
Why it fails: Reflective DLL injection is a sophisticated technique that loads a malicious DLL entirely from memory into a process without touching disk, but there is no indication in the exhibit that svchost.exe has been injected in this manner. The observed suspicious traffic and listening socket are attributed to rundll32.exe with PID 1500, not to svchost.exe. Thus, this option incorrectly attributes the infection to the wrong process and misreads the network evidence.
C
The malware is using port 4444 for Windows Update communications.
Why it fails: Windows Update communicates over HTTP/HTTPS, typically using TCP ports 80 and 443, to reach Microsoft's servers; it never uses port 4444. Port 4444 is a common default for Metasploit payloads, EternalBlue exploits, and other remote-access Trojans. Therefore, this option is factually impossible because the port usage does not align with Windows Update's known networking behavior.
D
Rundll32.exe with PID 1500 is likely a backdoor listening on port 4444.
rundll32.exe is a legitimate Windows binary used to load and execute functions exported from DLLs, but by default it does not create network listeners. When a rundll32 process is observed listening on TCP port 4444—a port heavily associated with Metasploit and backdoor payloads—it strongly suggests that the process has loaded a malicious DLL that opens a remote command shell. The combination of an unusual process acting as a network server on a non-standard port is classic evidence of a backdoor.

Full breakdown with real-world context →

Question 3hardmultiple choice

Full question →

You are investigating a Windows 10 workstation that exhibits slow performance and frequent pop-ups. The user reports that the system started acting strangely after installing a 'PDF Converter' from an email attachment. You suspect malware. You have captured a memory dump using FTK Imager and a network capture during the infection. In the memory dump, you find a suspicious process 'conhost.exe' running from a non-standard location (C:\Users\Public\Temp). The process has an open handle to a file named 'config.ini' in the same directory. The network capture shows periodic HTTPS connections to 'malicious.com' on port 443 from the workstation's IP. Using Volatility, you extract the process's command line: 'conhost.exe -hidden -log C:\Users\Public\Temp\output.log'. Which of the following is the BEST immediate course of action to contain the threat and preserve evidence?

A
Delete the config.ini file and the conhost.exe executable immediately.
Why it fails: 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.
B
Restore the system to a previous restore point.
Why it fails: 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.
C
Terminate the suspicious conhost.exe process and run a full antivirus scan.
Why it fails: 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.
D
Isolate the workstation from the network, then create a forensic image of the hard disk for analysis.
Isolating the workstation from the network by disconnecting the cable or disabling the NIC immediately severs Command & Control (C2) channels and halts any lateral movement to other hosts, preserving the network flow data and the current state of live connections. Creating a forensic image of the hard disk using a write-blocker and bit-for-bit imaging tools maintains the integrity of evidence, allowing recovery of deleted files, unallocated space, and file system slack that may contain residual malware or attacker artifacts. This evidence-preserving approach aligns with forensic best practices, keeps proper chain of custody, and enables thorough static and dynamic analysis in a controlled lab environment—unlike the destructive or ineffective alternatives.

Full breakdown with real-world context →

Question 4mediummultiple choice

Full question →

You are a forensic analyst investigating a suspected malware infection on a Windows 10 workstation. The user reports that the system has been slow and that unexpected pop-ups appear. You have acquired a memory dump and a disk image. During analysis, you find a suspicious process named 'svch0st.exe' running with PID 4567. The process has loaded several DLLs, including 'wininet.dll' and 'ws2_32.dll'. You also find that the process has an active TCP connection to an external IP address 203.0.113.5 on port 4444. In the disk image, you find an executable file at C:\Users\Public\svch0st.exe with a creation date that matches the start of symptoms. The file's hash is not in any known malware database. You decide to perform dynamic analysis by running the file in a sandbox. However, the sandbox environment has no network connectivity. The executable runs but does not exhibit any malicious behavior. What should you do next to determine if the file is malicious?

A
Conduct a thorough static analysis using a disassembler and debugger to understand the code
Why it fails: 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.
B
Delete the suspicious file and run a full antivirus scan on the system
Why it fails: 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.
C
Re-run the sample in a sandbox with simulated network connectivity or a controlled network to observe C2 communication
Re-running the sample in a sandbox with simulated network connectivity or a controlled network is the correct approach because many malware families remain dormant until they establish C2 communication, at which point they download additional payloads, exfiltrate data, or execute commands. A network-enabled sandbox provides a safe, but realistic environment where the analyst can observe DNS queries, HTTP/S connections, beaconing intervals, and the exact data exchanged with the C2 server. This dynamic analysis yields actionable indicators of compromise (IoCs) and reveals the malware's full functionality without risking real network infection.
D
Perform a forensic imaging of the system again and compare with the original image
Why it fails: 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.

Full breakdown with real-world context →

Question 5mediummultiple choice

Full question →

Refer to the exhibit. An analyst recovers this binary log entry from a MySQL server. What does the timestamp '190101 10:00:00' represent?

Exhibit

Refer to the exhibit.

```
MySQL Binary Log Entry:
# at 12345678
#190101 10:00:00 server id 1  end_log_pos 12345679 CRC32 0x12345678 	Query	thread_id=100	exec_time=0	error_code=0
SET TIMESTAMP=1546334400/*!*/;
DELETE FROM users WHERE id=5
/*!*/;
```

A
The time the DELETE statement was executed on the MySQL server
The timestamp in the binary log entry records when the MySQL server executed the DELETE statement, as part of its statement-based or row-based logging. This is the server's authoritative clock at the moment the statement was processed, not when the client sent it or when the file was flushed. MySQL writes this event timestamp into the binary log header for replication and point-in-time recovery, reflecting execution time.
B
The time the client sent the query to the server
Why it fails: The timestamp reflects server-side processing, not the client's send time. Network latency, client-side batching, or queuing can delay the query arrival; the binary log captures when the server actually started executing the statement, after receiving it. So it cannot be used to measure client behavior or network transmission time.
C
The time the binary log file was written to disk
Why it fails: The binary log file is written as events are generated, but the event timestamp is set at execution time, independent of when the log file is physically flushed to disk. Disk I/O, buffering, and sync settings may cause a delay between event generation and file write. Therefore the timestamp does not indicate the write time to storage.
D
The time the transaction was committed
Why it fails: For a DELETE statement, particularly in non-transactional storage engines like MyISAM or with autocommit, there is no explicit transaction commit; the statement is immediately durable. Even in InnoDB, the binary log records the statement execution time, not the commit time, as a commit may occur later at the end of the transaction. Thus the timestamp is not about commit timing.

Full breakdown with real-world context →

Question 6easymultiple choice

Full question →

Based on the log exhibit, what type of attack is occurring?

Exhibit

Refer to the exhibit.

Nov 12 09:23:45 server1 sshd[1234]: Failed password for root from 10.0.0.5 port 22 ssh2
Nov 12 09:24:10 server1 sshd[1235]: Failed password for root from 10.0.0.5 port 22 ssh2
Nov 12 09:24:35 server1 sshd[1236]: Failed password for root from 10.0.0.5 port 22 ssh2
... (repeated every 25 seconds)

A
Man-in-the-middle attack
Why it fails: A man-in-the-middle attack would leave distinct traces such as ARP cache poisoning (duplicate MAC addresses for a single IP), unexpected SSL/TLS certificate validation failures, or interception of credentials via a rogue gateway. The exhibit shows no such protocol-level redirection, DNS poisoning, or spoofed addressing; it only displays repeated SSH authentication failures. Without evidence of traffic interception or credential eavesdropping, classifying this as MITM is unsupported.
B
SQL injection attack
Why it fails: SQL injection attacks exploit web application input fields by injecting malicious SQL syntax, often producing distinctive HTTP request patterns containing encoded characters, UNION clauses, or database error messages in the response. The exhibit is clearly from an SSH daemon log, not a web server log, and the entries show authentication failures rather than HTTP queries. There are no SQL statements, query strings, or database output anomalies, so this is not an SQL injection attack.
C
Denial of Service attack
Why it fails: A denial-of-service attack seeks to exhaust resources or disrupt availability, typically via high-volume traffic like SYN floods, ICMP floods, or connection floods that overwhelm the target. The log excerpt shows a systematic sequence of SSH login failures from one source IP, which is low-bandwidth and does not indicate service unavailability, resource exhaustion, or network saturation. Repeated failed logins without a spike in traffic or downtime fail to meet the criteria for a DoS attack.
D
Brute-force attack on SSH
This is a classic SSH brute-force attack: the log shows repeated "Failed password for root" messages from the same source IP, indicating automated guesses against a privileged account. Attackers run dictionary or credential-stuffing tools to try many passwords in rapid succession, and the steady stream of failures from a single origin is the definitive signature. The target is the SSH service, not the application layer, and the goal is unauthorized access, not interception or resource exhaustion.

Full breakdown with real-world context →

Question 7mediummultiple choice

Full question →

An analyst executed the commands shown in the exhibit on a Windows system to prepare a forensic image for analysis. What is the most likely reason for the error message from e2fsck?

Exhibit

Refer to the exhibit.

C:\> fsutil volume dismount C:

C:\> diskpart
DISKPART> select volume 1
DISKPART> attribute volume clear readonly
DISKPART> exit

C:\> e2fsck -fn image.dd

e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
image.dd: ********** WARNING: Filesystem still has errors **********

A
The analyst failed to properly dismount the source volume before imaging, leading to filesystem inconsistencies.
The sequence shows `fsutil dismount` being run on C:, but a forensic image taken afterward—especially after Windows remounts the volume or during a live acquisition—will capture the volume in an inconsistent state. When Windows later performs recovery on the dirty volume, metadata updates begin immediately, so e2fsck in the analyst's analysis environment will legitimately report superblock, group descriptor, or inode inconsistencies that were never present in the source. This is the classic 'dirty volume' imaging error, not a problem with the image tool.
B
The forensic image was not acquired with a write-blocker, causing data corruption.
Why it fails: 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.
C
The image file contains an NTFS filesystem, but e2fsck is designed for ext filesystems.
Why it fails: 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.
D
The e2fsck command syntax is incorrect; it should be 'e2fsck -f -n' instead.
Why it fails: 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.

Full breakdown with real-world context →

Question 8hardmultiple choice

Read the full network assurance explanation →

A forensic analyst is reviewing the syslog from a compromised Linux server. Based on the exhibit, what does the 'orphan inode deleted' message indicate?

Exhibit

Refer to the exhibit.

=== Linux log excerpt (var/log/syslog) ===
Jan 12 10:15:32 server1 kernel: [ 1234.5678] EXT4-fs (sda1): recovery complete
Jan 12 10:15:33 server1 kernel: [ 1234.5680] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
Jan 12 10:15:34 server1 sshd[2345]: Accepted publickey for root from 192.168.1.10 port 54321 ssh2: RSA SHA256:abc...
Jan 12 10:15:35 server1 sshd[2346]: Received disconnect from 192.168.1.10 port 54321:11: disconnected by user
Jan 12 10:15:36 server1 kernel: [ 1234.5700] EXT4-fs (sda1): 1 orphan inode deleted
Jan 12 10:15:37 server1 kernel: [ 1234.5702] EXT4-fs (sda1): 1 orphan inode deleted

A
A hidden file was permanently removed from the filesystem.
Why it fails: 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.
B
A file was deleted while still open, and the filesystem has cleaned up the orphan inode.
When a file is unlinked but a process still holds its file descriptor, the inode remains allocated until the descriptor closes, resulting in an orphan inode. On a journaling filesystem such as ext4, that inode is recorded in the orphan list during the transaction, and after an unclean shutdown or during mount, the filesystem deletes it to reclaim space and logs 'orphan inode' messages. This is expected lifecycle behavior, not a sign of an attack or corruption.
C
A rootkit has attempted to hide files by marking them as orphan inodes.
Why it fails: 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.
D
A critical system file has been deleted, and the filesystem is warning the administrator.
Why it fails: 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.

Full breakdown with real-world context →

Question 9hardmultiple choice

Full question →

Refer to the exhibit. An investigator is examining a disk image using TSK. The output from 'fls' shows the directory structure. What is the significance of the entry 'V/V 113-128-1: $OrphanFiles'?

Exhibit

Refer to the exhibit.

C:\> fls -f ntfs -o 2048 image.dd
r/r 4-128-3: $AttrDef
r/r 8-128-2: $BadClus
r/r 6-128-2: $Bitmap
r/r 7-128-1: $Boot
r/r 11-128-3: $Extend
r/r 2-128-1: $LogFile
r/r 0-128-1: $MFT
r/r 1-128-1: $MFTMirr
r/r 9-128-8: $Secure
r/r 10-128-1: $UpCase
r/r 3-128-3: $Volume
r/r 108-128-2: Users
r/r 109-128-3: ProgramData
r/r 110-128-2: Windows
r/r 111-128-1: Program Files
r/r 112-128-1: Program Files (x86)
V/V 113-128-1: $OrphanFiles
r/r 114-128-3: autoexec.bat
r/r 115-128-1: config.sys

A
It is a sign that a rootkit has hidden files in the image
Why it fails: 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.
B
It indicates the location of the Master File Table (MFT) mirror
Why it fails: $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.
C
It is a virtual directory that contains files with no parent directory, often from deleted files
In tools like The Sleuth Kit (tsk) and Autopsy, the virtual directory named $OrphanFiles (or displayed as 'V/V') is not a literal directory stored on the disk. It is dynamically generated to represent files whose MFT entries exist but whose parent directory references were lost, typically because the directory entry was deleted, overwritten, or corrupted while the file record itself remains in the MFT. This commonly occurs after a file is deleted, when the directory index entry is removed but the file's MFT record is not yet reused, or after a malformed directory entry prevents normal linkage in the tree.
D
It is a standard NTFS metadata file that stores file permissions
Why it fails: $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.

Full breakdown with real-world context →

Question 10hardmultiple choice

Full question →

Refer to the exhibit. A database administrator finds the above error log entries when attempting to start the MySQL service. The server was working fine yesterday. What is the most likely cause of this issue?

Exhibit

Refer to the exhibit.

Exhibit:
```
MySQL Error Log Entry:
[ERROR] Plugin 'InnoDB' init function returned error.
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
[ERROR] Aborting
```

A
The MySQL user does not have write permissions to the data directory.
Why it fails: 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.
B
The binary log is full and cannot be rotated.
Why it fails: 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.
C
The server ran out of memory due to high innodb_buffer_pool_size.
Why it fails: 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.
D
The InnoDB system tablespace file (ibdata1) is corrupted.
The InnoDB system tablespace file (ibdata1) holds the data dictionary, rollback segments, and undo tablespaces; its first page contains a header that InnoDB validates at startup. If that header or any critical internal page is corrupted, InnoDB cannot initialize its storage engine and aborts with errors such as 'Database page corruption' or 'Cannot open datafile'. This matches the administrator's exhibit, making corruption of ibdata1 the correct explanation; recovery requires restoring the tablespace from backup or rebuilding it with new setup.

Full breakdown with real-world context →

Question 11easymultiple choice

Full question →

Refer to the exhibit. A first responder runs the netstat command on a compromised Windows workstation. Which of the following conclusions is BEST supported by the output?

Exhibit

Refer to the exhibit.

C:\Users\Forensic> netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    192.168.1.10:49152     10.2.3.4:443           ESTABLISHED     1234
  TCP    192.168.1.10:49153     192.168.1.1:80         TIME_WAIT       0
  TCP    192.168.1.10:49154     10.2.3.4:80            ESTABLISHED     1234
  UDP    0.0.0.0:5353           *:*                                    5678

A
The connection to 192.168.1.1:80 is suspicious because it is in TIME_WAIT state.
Why it fails: 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.
B
The UDP listener on port 5353 indicates a malware infection.
Why it fails: 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.
C
A process with PID 1234 is likely communicating with a remote C2 server at 10.2.3.4.
PID 1234 holding two established TCP connections to the same remote IP address 10.2.3.4 on different ephemeral source ports is a notable pattern. Established connections indicate active communication, and multiple simultaneous connections to a single remote host—especially if that host is not a known internal server—can represent command-and-control (C2) beaconing or data exfiltration, particularly when the process is unfamiliar or unauthorized. This observation warrants further investigation into the process, its binary, and the remote address's reputation.
D
The workstation is running multiple virtual machines based on the local addresses.
Why it fails: 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.

Full breakdown with real-world context →

These CHFI practice questions are part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style CHFI questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Refer to the Exhibit Practice Questions

How to approach refer to the exhibit practice questions

Quick answer

Related CHFI topic practice pages

Computer Forensics Investigation Process practice questions

Computer Forensics Fundamentals and Process practice questions

Application, Email and Cloud Forensics practice questions

Mobile and Malware Forensics practice questions

Network and Cloud Forensics practice questions

Storage Forensics and File System Analysis practice questions

Database and Application Forensics practice questions

Incident Response and First Responder Skills practice questions

Computer Forensics Lab practice questions

OS and Network Forensics practice questions

Malware Forensics practice questions

Evidence Acquisition and Duplication practice questions

Practice scenarios

Refer to the exhibit. During incident response, a first responder runs 'netstat -ano' on a compromised Windows system. Which connection is most likely to be the command-and-control (C2) channel and should be prioritized for isolation?

Exhibit

Refer to the exhibit. During a malware investigation, a forensic analyst runs the commands shown. What is the most likely conclusion?

Exhibit

Refer to the exhibit. An analyst recovers this binary log entry from a MySQL server. What does the timestamp '190101 10:00:00' represent?

Exhibit

Based on the log exhibit, what type of attack is occurring?

Exhibit

An analyst executed the commands shown in the exhibit on a Windows system to prepare a forensic image for analysis. What is the most likely reason for the error message from e2fsck?

Exhibit

A forensic analyst is reviewing the syslog from a compromised Linux server. Based on the exhibit, what does the 'orphan inode deleted' message indicate?

Exhibit

Refer to the exhibit. An investigator is examining a disk image using TSK. The output from 'fls' shows the directory structure. What is the significance of the entry 'V/V 113-128-1: $OrphanFiles'?

Exhibit

Refer to the exhibit. A database administrator finds the above error log entries when attempting to start the MySQL service. The server was working fine yesterday. What is the most likely cause of this issue?

Exhibit

Refer to the exhibit. A first responder runs the netstat command on a compromised Windows workstation. Which of the following conclusions is BEST supported by the output?

Exhibit