Update: Call for Packets - Unassigned TCP Options

Published: 2011-03-07
Last Updated: 2011-03-14 19:12:41 UTC
by Lorna Hutcheson (Version: 2)
7 comment(s)

We had a user over the weekend send us some interesting traffic primarily destined to port 80.  The TCP option used is in an option kind that appears to be in unassigned range, the sequence numbers are not changing, but the source IPs are.  They also throw in a packet here and there to destination ports other than 80 such as ports 21, 22 and 1.   If anyone is seeing something similar and has logs or preferably packets, please send them to us.  


UPDATE:   I want to thank those who have submitted traffic and logs.  There is still no answer for this traffic, but I wanted to share with everyone what we have received so far.   Here is an example of a capture:    xxx.xxx.xxx.xxx    TCP    33338 > 80 [SYN] Seq=846930886 Win=61690 Len=0 MSS=1460 WS=4

0000   00 00 ff ff 00 00 00 00 00 00 00 00 00 00 08 00           ................
0010   45 00 00 3c 45 67 40 00 e9 06 a7 30 72 86 53 8d      E..<Eg@....0r.S.
0020   xx xx xx xx 82 3a 00 50 32 7b 23 c6 69 98 3c 64            >K...:.P2{#.i.<d
0030   a0 02 f0 fa 97 d4 00 00 02 04 05 b4 01 01 04 02         ................
0040   b2 08 f0 47 00 00 00 00 01 03 03 04                              ...G........


Items of interest across three captures sent to us:

Source IPs:  Various

Initial Sequence Number is identical :  846930886

ACK Flag is NOT set, but the ACK field contains data which is identical in all 3 captures:  69 98 3c 64

Window Scale is the same and set to 4: 

Unassigned TCP option:  b2 08 f0 47 00 00 00 00


If you have any ideas or your seeing this traffic similar to this with unassigned TCP options, please let us know.



7 comment(s)


Yep - been seeing that for a few weeks. I have a small sample pcap I can send you, and just started another one for longer-term collection. What's the preferred way to get it to you? Would prefer not posting an URL in public.
NM - just found the contact us page. sending now.
What's the simplest tcpdump filter or snort rule to watch for this?
It's been way too long since I had to create a filter using offsets and if someone else has it, it would save me time and headaches.
Hey Jason,

tcpdump -w /storage/dump -s0 -nn -Z pcap 'not src host (yourhostip) and not (port with known traffic) and tcp[tcpflags]&(tcp-syn) !=0 and not tcp[tcpflags]& (tcp-ack) !=0', optionally piped by a `grep opt' should work out of the box.[0]

Kind regards,

[0] man 1 tcpdump
Whatever is sending these packets may be based on the source code found here:

The documentation includes examples where the sequence number above appears on every packet. The reason for this is that the programmer forgot to seed the random number generator, resulting in the same "random" number being generated every time the program is launched. Also the line of code that sets the tcp offset does not make sense to me - it looks like a kludge that may work most of the time, or may cause garbage from adjacent memory to be appended to the packet. Also it does not look like the code initializes the ACK number, which could result in garbage data going into that field.
Nice catch and bears further investigating. I wonder if someone has used this code in a new tool or as is...you just gotta love a good mystery:) Thanks for sending this in!! Lorna
Looks like this may be the culprit? Or at least a variant of this code?

Diary Archives