CHFI OS and Network Forensics Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  tcp.flags.syn == 1 or tcp.flags.ack == 0

  Why it's wrong here

  This filter uses a logical OR, so it matches any packet that either has the SYN flag set or has the ACK flag cleared. Since ACK=0 is true for many packet types beyond initial SYNs—including RSTs and FINs—the filter returns a large superset of the intended traffic. It would also still include SYN-ACK packets because their SYN bit is set, even though they also have ACK=1. Consequently, it is far too broad for isolating only the initial TCP handshake packets.

• ✓

  tcp.flags.syn == 1 and tcp.flags.ack == 0

  Why this is correct

  This filter requires both conditions to be true: SYN=1 and ACK=0, which precisely identifies the initial SYN segment sent by the host initiating a TCP connection. During the three-way handshake, a SYN-ACK response has SYN=1 but also ACK=1, so it is excluded by the ACK=0 requirement. This is the standard, readable Wireshark filter for finding connection attempts, and it reliably distinguishes the connection initiator from the responder.

• ✗

  tcp.flags.syn == 1

  Why it's wrong here

  This filter matches every TCP segment with the SYN flag set, regardless of the state of the ACK bit. As a result, it captures both the initial SYN (ACK=0) and the SYN-ACK response (ACK=1), producing duplicate and irrelevant results for the analyst. It therefore fails to distinguish between a new connection request and the remote host's acknowledgment of that request, which is the very distinction needed to isolate initial handshake packets.

• ✗

  tcp.flags == 0x002

  Why it's wrong here

  This filter performs an exact bitwise equality on the full TCP flags field, requiring it to equal hexadecimal 0x002, which corresponds to only the SYN bit being set. While this can match a clean initial SYN, it is brittle in practice: any SYN that carries additional flags—such as ECE/CWR for Explicit Congestion Notification—will not match because the flags field will be 0x042 or similar. It also lacks the readability of named flag filters, making the analyst's intent less transparent and harder to maintain in shared packet analysis.