SYN-FIN packet decode

Though the attack vector has shifted heavily to client-side attacks through the Web browser, there are still plenty of attacks coming against the perimeter (which supposedly doesn't exist any more, a premise I don't buy into). The result is that an intrusion analyst not only needs to learn how to accurately decipher client side attacks, he/she also STILL needs to know the basic packet/protocol decode information as well. The best course I have personal experience with to do that is the SANS SEC503 course, six days of learning starting with Day One's "Bit Boot Camp". To that end, here's a decode of a SYN-FIN packet. It's a good example for the new intrusion analyst, as it requires some bit masking to decode instead of all fields breaking nicely on 4 bit or greater boundaries. We need to check the individual bits of the TCP flags field, as shown below.

The alert:

Event : DECODE_TCP_SYN_FIN (116:420), Timestamp : 2013-12-11 07:45:20

Classification : Misc Activity

Priority : low

Detection Engine : myidsdmz2-IPS / myyidsdmz2.xxx.com

Protocol : tcp

Source IP : 10.10.10.130 (desktop1.xyz.xxx.com)

Source Port/ICMP Type : 59025/tcp

Destination IP : 69.171.245.49 (mqtt-shv-04-ash3.facebook.com)

Destination Port/ICMP Code : 443 (https)/tcp

Intrusion Policy : DMZ Passive Intrusion Policy

Rule : alert (msg:"DECODE_TCP_SYN_FIN"; sid:420; gid:116; rev:1; metadata:rule-type decode; classtype:misc-activity; )

Actions

Packet Information

FRAME 1 (Expand All)

Frame 1: 62 bytes on wire (62 bytes captured (496 bits)

Ethernet II, Src: 00:1c:f9:6b:64:00, Dst: e0:5f:b9:04:45:9b

Internet Protocol Version 4, Src: 10.10.10.130 (desktop1.xyz.com), Dst: 69.171.245.49 (mqtt-shv-04-ash3.facebook.com)

Transmission Control Protocol, Src Port: 59025 (59025), Dst Port: 443 (443), Seq: 0, Len: 0

Packet Text

._..E....kd...E..0V.@.=... P..E..1......4.....p...c...........

Packet Bytes

0000 e0 5f b9 04 45 9b 00 1c f9 6b 64 00 08 00 45 00 ._..E....kd...E. 0010 00 30 56 87 40 00 3d 06 f7 91 0a 0a 0a 82 45 ab .0V.@.=....P..E. 0020 f5 31 e6 91 01 bb 13 d5 34 b7 00 00 00 00 70 03 .1......4.....p. 0030 ff ff 63 97 00 00 02 04 05 b4 04 02 00 00 ..c...........

To verify this:

GREEN is your Ethernet header, the first 14 bytes.

BLUE is your IP header, 20 bytes. How do we know? The first byte offset from 0, (counting always starts at 0) the second nibble is a 5 (one byte equals 8 bits, half a byte is called a nibble and is 4 bits, so this is the nibble in the first byte which has a value of "5"), this is the header length field which represents the number of 32 bit words (or 4 byte words), and 4 bytes times 5 = 20 bytes)

RED is your TCP header. The TCP flags are in byte 13 offset from 0, in BOLD UNDERLINE.

The value is 0x03.

The TCP flags in the 13th byte (from 0), are in the following order:

CWR ECE URG ACK           PUSH RESET SYN FIN

We have one byte (or two nibbles or 8 bits here). 

Ignore the first two. They’re used for Explicit Congestion Notification and aren't used here. 

We have a 0 in the first (leftmost) nibble, so no flags are set.

The second nibble equals 3, so binary wise, the FIN (value of 1) flag and SYN (value of 2) flags are set, giving us a value of 3.  So when we see 03 in the TCP Flags byte, the packet is a SYN-FIN packet. 

Of course, if the ECN or CWR flags are set, that will change the value.

For example, if the CWR flag were set as well as SYN and FIN, our value would be 0x83, because in the first nibble, the CWR flag is in the 8's (2 to the power of 3) column. 

If CWR and ECE were both set,we'd have a value of 12 (8 + 4) in the first nibble, represented in hex as C, so our flags field would 0xC3.