In my last blog entry, I explained how Wireshark calculates TCP Conversation Completeness based on the TCP flags and whether data is seen in a TCP conversation (stream).
To use this feature, I recommend that you add three columns to Wireshark:
tcp.completeness
[The fastest way to add these three columns is to click and drag the following fields to the column header area - Stream index, Conversation completeness, and Completeness Flags.]
[Yes - I recommend you create a profile for "TCP Completeness" and add these columns to that new profile. Also add a tcp.stream column as you see in the image below.]
Now grab the following trace file and open it in Wireshark. Sort the Packet List pane based on the Stream index column.
TRACE FILE: sec-nmap-quickscanplus.pcapng
At first, you will see a bunch of UDP-based traffic (DNS, ICMP, and basic UDP packets). You can apply a filter for tcp, if desired. Alternately, just scroll down until you see Frame 5 or 9 (they are both part of TCP stream 0).
This stream's TCP conversation is "incomplete" with R - - A - S shown for the Completeness flags. Reset, ACK, and SYN have been seen in this conversation.
A quick reminder of the values assigned for TCP completeness:
32 : RST
16 : FIN
8 : DA
4 : ACK
2 : SYN-ACK
1 : SYN
Now, let's use this value to detect suspicious TCP traffic - you can see how we got 37 for conversation completeness. That's not a number we'd expect for a "normal" conversation. The fact that this is an odd number indicates that we saw the SYN packet. In that case, we'd expect to see SYN-ACK, ACK, DATA, and FIN or Reset.
We would expect to see either 31 or 47.
Could you create a display filter to detect this unusual TCP completeness value? Sure you can! Use tcp.completeness == 37.
This trace file contains a LOT of questionable TCP conversations. Spend a moment looking through all the TCP Conversation Completeness values shown.
Enjoy!