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.

• ✗

  A man‑in‑the‑middle attack

  Why it's wrong here

  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's wrong here

  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's wrong here

  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.

• ✓

  A TCP SYN scan (stealth scan)

  Why this is correct

  A TCP SYN scan, also known as a stealth scan or half-open scan, works by sending an SYN packet to a port and observing the response: if SYN-ACK is received, the port is open, and the scanner immediately sends an RST to tear down the connection. This avoids completing the three-way handshake, so the target service never sees a full connection and may not write it to application logs. The captured sequence — SYN, SYN-ACK, RST — exactly matches this behavior. This is why it is correctly identified as a TCP SYN scan, as the RST after SYN-ACK is the signature of an active port-scanning tool like Nmap.

Go deeper

Related to this question