Re: LOGS: GIAC GCIA Version 3.4 Practical Detect JamesStevenson

Hi,

Just made some observations. I would be interested to find out what
particular tool we are dealing with here. The passive fingerprint pointed to
FreeBSD, based on the "guessed" initial TTL and Window Size. The TCP header
was 40 bytes (high for my standard), partly because of the timestamp option.
Does FreeBSD OS set timestamp TCP option? Another particular "feature" of
this tool is that certain properties changes every 7 packets. If you look
closely at the rawdump, you would observe that the source TCP port, SEQ
number changes every 7 packets. The targeted TCP port (1080, 3128, 8080)
also changed after 14, 7, 7 SYN packets respectively. Seemed like the loop
count was set to 7? Or defaulted to 7. Another feature of the tool; every
SYN packet are 3 seconds apart but there's a jump of 6 seconds for the 7th
packet.

Could this be just a one-off recon attempt by the attacker, or maybe he's
just familarising with the tool. Did you observe any other occurence on
previous occassions or on later dates? There were gaps of 51s and 75s
between the targeted port changes (i.e. 1080 -> 3128 ->8080), which would be
more than enough time to scan another target. So could the targeted address
be a part of a targeted segment or subnet (hint: look at the IP ID, does it
increment linearly?)?

Hope these observations can provide more insight for you.

Rgds,

Johnny Wong

----- Original Message ----- 
From: <StevensonJA@xxxxxxx>
To: <intrusions@xxxxxxxxxxxxx>
Sent: Sunday, May 09, 2004 3:36 AM
Subject: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect
JamesStevenson


> Hello,
>
> This is my 3rd detect for the GCIA Practical,
> Any comments would be greatly appreciated!
>
> Many Thanks in advance,
> James Stevenson
>
>
> Trace #3: TCP Connections to port 1080,3128,8080
>
> Source of trace:
>
> This trace was extracted from the log file dated 2002.6.2 located at
incidents.org/logs/raw. This log file is available from the following URL:
>
>     http://www.incidents.org/logs/raw/2002.6.2
>
> It’s important to note that this log file has been sanitised. All of the
IP addresses from the protected network space have been “munged” [1] and no
information has been provided with regards to the network layout.
>
> Detect was generated by:
>
> This log file was generated by a Snort Intrusion Detection System running
in binary logging mode, hence only packets that violate the ruleset will
appear in the log. A small amount of time was spent interrogating the log
file using Windump and a variety of filters, after which an interesting
trace was eventually detected with regards to an external host with an IP
address of 66.60.157.246. In order to analyse this detect accurately its
imperative that we can view as much packet information as possible from the
log file, hence why the following parameters were used when running Windump:
>
> windump -n -v -X -r 2002.6.2 host 66.60.157.246
>
> In addition to the –n switch (Do not resolve host addresses and port
numbers to names), the –v switch was also used to increase the verbose
output so that ttl and total length fields in each IP packet are printed. In
addition, the –X switch was used to tell Windump to print hex and its
associated ascii aswell. In this instance a custom filter file (-F <file>)
has not been applied in order to show the exact syntax applied in this
filter. This windump filter provided the following detect of interest:
>
> windump -n -v -X -r 2002.6.2 host 66.60.157.246
>
> 15:15:12.464488 IP (tos 0x0, ttl 48, id 14162, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum d74 (->86c)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33239493 0> (DF)bad cksum
87d6 (->82ce)!
> 0x0000   4500 003c 3752 4000 3006 87d6 423c 9df6       E..<7R@.0...B<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 0d74 0000 0204 05b4 0103 0300      ..@..t..........
> 0x0030   0101 080a 01fb 31c5 0000 0000                   ......1.....
> 15:15:15.624488 IP (tos 0x0, ttl 48, id 14584, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum c48 (->740)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33239793 0> (DF)bad cksum
8630 (->8128)!
> 0x0000   4500 003c 38f8 4000 3006 8630 423c 9df6        E..<8.@.0..0B<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 0c48 0000 0204 05b4 0103 0300       ..@..H..........
> 0x0030   0101 080a 01fb 32f1 0000 0000                    ......2.....
> 15:15:18.324488 IP (tos 0x0, ttl 48, id 15021, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum b1c (->614)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33240093 0> (DF)bad cksum
847b (->7f73)!
> 0x0000   4500 003c 3aad 4000 3006 847b 423c 9df6        E..<:.@.0..{B<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 0b1c 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 341d 0000 0000                    ......4.....
> 15:15:21.284488 IP (tos 0x0, ttl 48, id 15541, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum 9f0 (->4e8)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33240393 0> (DF)bad cksum
8273 (->7d6b)!
> 0x0000   4500 003c 3cb5 4000 3006 8273 423c 9df6        E..<<.@.0..sB<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 09f0 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 3549 0000 0000                   ......5I....
> 15:15:24.284488 IP (tos 0x0, ttl 48, id 16013, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum 8c4 (->3bc)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33240693 0> (DF)bad cksum
809b (->7b93)!
> 0x0000   4500 003c 3e8d 4000 3006 809b 423c 9df6        E..<>.@.0...B<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 08c4 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 3675 0000 0000                  ......6u....
> 15:15:27.284488 IP (tos 0x0, ttl 48, id 16475, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum 798 (->290)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33240993 0> (DF)bad cksum
7ecd (->79c5)!
> 0x0000   4500 003c 405b 4000 3006 7ecd 423c 9df6        E..<@[@.0.~.B<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 0798 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 37a1 0000 0000                    ......7.....
> 15:15:33.354488 IP (tos 0x0, ttl 48, id 17278, len 60) 66.60.157.246.2312
> 46.5.130.100.1080: S [bad tcp cksum 540 (->38)!] 4218369424:4218369424(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33241593 0> (DF)bad cksum
7baa (->76a2)!
> 0x0000   4500 003c 437e 4000 3006 7baa 423c 9df6        E..<C~@.0.{.B<..
> 0x0010   2e05 8264 0908 0438 fb6f 3590 0000 0000        ...d...8.o5.....
> 0x0020   a002 4000 0540 0000 0204 05b4 0103 0300        ..@..@..........
> 0x0030   0101 080a 01fb 39f9 0000 0000                   ......9.....
> 15:15:36.324488 IP (tos 0x0, ttl 48, id 17726, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 48ce (->43c6)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33241894 0> (DF)bad cksum 79ea (->74e2)!
> 0x0000   4500 003c 453e 4000 3006 79ea 423c 9df6        E..<E>@.0.y.B<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 48ce 0000 0204 05b4 0103 0300        ..@.H...........
> 0x0030   0101 080a 01fb 3b26 0000 0000                    ......;&....
> 15:15:39.454488 IP (tos 0x0, ttl 48, id 18146, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 47a2 (->429a)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33242194 0> (DF)bad cksum 7846 (->733e)!
> 0x0000   4500 003c 46e2 4000 3006 7846 423c 9df6        E..<F.@.0.xFB<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 47a2 0000 0204 05b4 0103 0300        ..@.G...........
> 0x0030   0101 080a 01fb 3c52 0000 0000                      ......<R....
> 15:15:42.324488 IP (tos 0x0, ttl 48, id 18519, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 4676 (->416e)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33242494 0> (DF)bad cksum 76d1 (->71c9)!
> 0x0000   4500 003c 4857 4000 3006 76d1 423c 9df6        E..<HW@.0.v.B<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 4676 0000 0204 05b4 0103 0300        ..@.Fv..........
> 0x0030   0101 080a 01fb 3d7e 0000 0000                   ......=~....
> 15:15:45.304488 IP (tos 0x0, ttl 48, id 18902, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 454a (->4042)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33242794 0> (DF)bad cksum 7552 (->704a)!
> 0x0000   4500 003c 49d6 4000 3006 7552 423c 9df6        E..<I.@.0.uRB<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 454a 0000 0204 05b4 0103 0300        ..@.EJ..........
> 0x0030   0101 080a 01fb 3eaa 0000 0000                     ......>.....
> 15:15:48.304488 IP (tos 0x0, ttl 48, id 19290, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 441e (->3f16)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33243094 0> (DF)bad cksum 73ce (->6ec6)!
> 0x0000   4500 003c 4b5a 4000 3006 73ce 423c 9df6        E..<KZ@.0.s.B<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 441e 0000 0204 05b4 0103 0300        ..@.D...........
> 0x0030   0101 080a 01fb 3fd6 0000 0000                   ......?.....
> 15:15:51.294488 IP (tos 0x0, ttl 48, id 19681, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 42f2 (->3dea)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33243394 0> (DF)bad cksum 7247 (->6d3f)!
> 0x0000   4500 003c 4ce1 4000 3006 7247 423c 9df6        E..<L.@.0.rGB<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 42f2 0000 0204 05b4 0103 0300        ..@.B...........
> 0x0030   0101 080a 01fb 4102 0000 0000                    ......A.....
> 15:15:57.394488 IP (tos 0x0, ttl 48, id 20410, len 60) 66.60.157.246.3013
> 46.5.130.100.1080: S [bad tcp cksum 409a (->3b92)!]
2268160598:2268160598(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33243994 0> (DF)bad cksum 6f6e (->6a66)!
> 0x0000   4500 003c 4fba 4000 3006 6f6e 423c 9df6        E..<O.@.0.onB<..
> 0x0010   2e05 8264 0bc5 0438 8731 6256 0000 0000        ...d...8.1bV....
> 0x0020   a002 4000 409a 0000 0204 05b4 0103 0300        ..@.@...........
> 0x0030   0101 080a 01fb 435a 0000 0000                   ......CZ....
> 15:16:48.404488 IP (tos 0x0, ttl 48, id 27951, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum 737 (->22f)!] 4216456306:4216456306(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33249097 0> (DF)bad cksum
51f9 (->4cf1)!
> 0x0000   4500 003c 6d2f 4000 3006 51f9 423c 9df6        E..<m/@.0.Q.B<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 0737 0000 0204 05b4 0103 0300        ..@..7..........
> 0x0030   0101 080a 01fb 5749 0000 0000                   ......WI....
> 15:16:51.384488 IP (tos 0x0, ttl 48, id 28337, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum 60b (->103)!] 4216456306:4216456306(0)
win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 33249397 0> (DF)bad cksum
5077 (->4b6f)!
> 0x0000   4500 003c 6eb1 4000 3006 5077 423c 9df6        E..<n.@.0.PwB<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 060b 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 5875 0000 0000                    ......Xu....
> 15:16:54.344488 IP (tos 0x0, ttl 48, id 28724, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum 4df (->ffd6)!]
4216456306:4216456306(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33249697 0> (DF)bad cksum 4ef4 (->49ec)!
> 0x0000   4500 003c 7034 4000 3006 4ef4 423c 9df6        E..<p4@.0.N.B<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 04df 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 59a1 0000 0000                     ......Y.....
> 15:16:57.394488 IP (tos 0x0, ttl 48, id 29128, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum 3b3 (->feaa)!]
4216456306:4216456306(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33249997 0> (DF)bad cksum 4d60 (->4858)!
> 0x0000   4500 003c 71c8 4000 3006 4d60 423c 9df6        E..<q.@.0.M`B<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 03b3 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 5acd 0000 0000                    ......Z.....
> 15:17:00.334488 IP (tos 0x0, ttl 48, id 29518, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum 287 (->fd7e)!]
4216456306:4216456306(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33250297 0> (DF)bad cksum 4bda (->46d2)!
> 0x0000   4500 003c 734e 4000 3006 4bda 423c 9df6        E..<sN@.0.K.B<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 0287 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 5bf9 0000 0000                     ......[.....
> 15:17:03.344488 IP (tos 0x0, ttl 48, id 29884, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum 15b (->fc52)!]
4216456306:4216456306(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33250597 0> (DF)bad cksum 4a6c (->4564)!
> 0x0000   4500 003c 74bc 4000 3006 4a6c 423c 9df6        E..<t.@.0.JlB<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 015b 0000 0204 05b4 0103 0300        ..@..[..........
> 0x0030   0101 080a 01fb 5d25 0000 0000                    ......]%....
> 15:17:09.434488 IP (tos 0x0, ttl 48, id 30606, len 60) 66.60.157.246.4860
> 46.5.130.100.3128: S [bad tcp cksum ff02 (->f9fa)!]
4216456306:4216456306(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33251197 0> (DF)bad cksum 479a (->4292)!
> 0x0000   4500 003c 778e 4000 3006 479a 423c 9df6        E..<w.@.0.G.B<..
> 0x0010   2e05 8264 12fc 0c38 fb52 0472 0000 0000        ...d...8.R.r....
> 0x0020   a002 4000 ff02 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 5f7d 0000 0000                    ......_}....
> 15:18:24.414488 IP (tos 0x0, ttl 48, id 40021, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum f63f (->f137)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33258701 0> (DF)bad cksum 22d3 (->1dcb)!
> 0x0000   4500 003c 9c55 4000 3006 22d3 423c 9df6        E..<.U@.0.".B<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 f63f 0000 0204 05b4 0103 0300        ..@..?..........
> 0x0030   0101 080a 01fb 7ccd 0000 0000                    ......|.....
> 15:18:27.554488 IP (tos 0x0, ttl 48, id 40397, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum f513 (->f00b)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33259001 0> (DF)bad cksum 215b (->1c53)!
> 0x0000   4500 003c 9dcd 4000 3006 215b 423c 9df6        E..<..@.0.![B<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 f513 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 7df9 0000 0000                   ......}.....
> 15:18:30.444488 IP (tos 0x0, ttl 48, id 40757, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum f3e7 (->eedf)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33259301 0> (DF)bad cksum 1ff3 (->1aeb)!
> 0x0000   4500 003c 9f35 4000 3006 1ff3 423c 9df6        E..<.5@.0...B<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 f3e7 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 7f25 0000 0000                    .......%....
> 15:18:33.474488 IP (tos 0x0, ttl 48, id 41136, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum f2bb (->edb3)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33259601 0> (DF)bad cksum 1e78 (->1970)!
> 0x0000   4500 003c a0b0 4000 3006 1e78 423c 9df6        E..<..@.0..xB<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 f2bb 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 8051 0000 0000                     .......Q....
> 15:18:36.434488 IP (tos 0x0, ttl 48, id 41538, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum f18f (->ec87)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33259901 0> (DF)bad cksum 1ce6 (->17de)!
> 0x0000   4500 003c a242 4000 3006 1ce6 423c 9df6        E..<.B@.0...B<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 f18f 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 817d 0000 0000                   .......}....
> 15:18:39.404488 IP (tos 0x0, ttl 48, id 41899, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum f063 (->eb5b)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33260201 0> (DF)bad cksum 1b7d (->1675)!
> 0x0000   4500 003c a3ab 4000 3006 1b7d 423c 9df6        E..<..@.0..}B<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 f063 0000 0204 05b4 0103 0300        ..@..c..........
> 0x0030   0101 080a 01fb 82a9 0000 0000                    ............
> 15:18:45.404488 IP (tos 0x0, ttl 48, id 42614, len 60) 66.60.157.246.2550
> 46.5.130.100.8080: S [bad tcp cksum ee0b (->e903)!]
1727560173:1727560173(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp
33260801 0> (DF)bad cksum 18b2 (->13aa)!
> 0x0000   4500 003c a676 4000 3006 18b2 423c 9df6        E..<.v@.0...B<..
> 0x0010   2e05 8264 09f6 1f90 66f8 79ed 0000 0000        ...d....f.y.....
> 0x0020   a002 4000 ee0b 0000 0204 05b4 0103 0300        ..@.............
> 0x0030   0101 080a 01fb 8501 0000 0000                   ............
>
> Although there is no information regarding the location or configuration
of this Snort device, we are able to speculate what Snort rules triggered
these alerts. Based upon detailed analysis, this detect was most likely
triggered by a combination of the following rules:
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 1080 (msg:"SCAN SOCKS Proxy
attempt"; stateless; flags:S,12; reference:url,help.undernet.org/proxyscan/;
classtype:attempted-recon; sid:615; rev:5;)
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 3128 (msg:"SCAN Squid Proxy
attempt"; stateless; flags:S,12; classtype:attempted-recon; sid:618; rev:5;)
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg:"SCAN Proxy Port 8080
attempt"; stateless; flags:S,12; classtype:attempted-recon; sid:620; rev:6;)
>
> All three rules are designed to detect any external host sending a TCP-SYN
packet (as defined in the snort.conf file), in an attempt to initiate a TCP
connection with the protected destination host over ports 1080,3128 and 8080
respectively.
>
> Probability source address was spoofed:
>
> It is considered unlikely that the source address was spoofed. This logged
activity most likely represents an attacker conducting network
reconnaissance, specifically searching for open proxy servers on TCP ports
1080, 3128 and 8080. In order for this reconnaissance activity to be of any
use, it’s vital that the response from the target host is sent back to the
attacking host. On this basis if the attacker spoofed the source address,
the response (if any) from the target host would be sent back to the spoofed
address and not the attackers.
>
> With this logic now established we are able to gather some intelligence
regarding the attacking source IP. Performing a Whois query using Sam Spade
provided the following information:
>
> Trying 66.60.157.246 at ARIN
> Trying 66.60.157 at ARIN
>
> OrgName:    Surewest Internet
> OrgID:      SURW
> Address:    P.O. Box 969
> City:           Roseville
> StateProv:  CA
> PostalCode: 95678
> Country:        US
>
> NetRange:       66.60.128.0 - 66.60.191.255
> CIDR:   66.60.128.0/18
> NetName:        SUREWEST-INTERNET
> NetHandle:  NET-66-60-128-0-1
> Parent:         NET-66-0-0-0-0
> NetType:        Direct Allocation
> NameServer: NS1.SUREWEST.NET
> NameServer: NS2.SUREWEST.NET
>
> While an nslookup query against the attacking IP provided the following
information:
>
> nslookup 66.60.157.246
> Canonical name: 246.157-60-66-fuji-dsl.static.surewest.net
>
> Based upon this information we are able to determine that an ISP named
Surewest provides the IP address assigned to the attacker. Furthermore,
based upon the Canonical name provided by the nslookup query, we can be
confident that Surewest provides high-speed Internet connections, one of
which is utilised by the attacker. Surewest’s website confirms the
availability of high-speed connections http://www.surewestbroadband.com.
>
> What is interesting is that the attacker appears to have utilised a static
IP address. If a victim were to trace an attack back to the source, the
process of contacting the ISP with attack information is made somewhat
easier if a static IP is involved, since its usually assigned to a specific
user. There is a possibility however that the source address in this
instance has been compromised and is being used as platform to launch
attacks against other hosts including ours. This is a common tactic employed
by many in an attempt to prevent anyone tracing an attack back to its true
origin. On this basis we may find the true attacker is hiding behind
multiple hosts in an attempt to minimise the risk of being traced. Many
attackers prefer to use dial-up accounts because they’re cheaper, readily
available and will only be assigned a temporary address from a large IP pool
when they dial-up. Since the probability of an attacker being assigned the
same IP address twice (within a medium timeframe) is minimal, the chance of
a victim correlating attacks from an array of IP’s to one specific user is
extremely unlikely. Furthermore, if an attack was relatively aggressive, the
victim may subsequently block the source IP (whether through an automated or
manual process) at their border routers etc. Since it would be impractical
for the victim to block the entire ISP netrange, the attacker only needs to
Dial-up again to obtain a different IP address in order to continue their
malicious activity.
>
> Description of attack:
>
> This detect represents an attackers reconnaissance technique in the form
of port scanning in search for specific proxy servers, namely:
>
>     1080/tcp (SOCKS Proxy)
>     3128/tcp (Squid Proxy)
>     8080/tcp (Proxy)
>
> This attacker like many others in the wild are attempting to discover live
hosts potentially running common proxy services. The discovery of a
miss-configured proxy server could be exploited to the extent that its used
as a platform to launch attacks, thus any attack would appear to originate
from the compromised proxy host rather than the attackers true source
address. In a sense the attacker is hiding behind another IP address to
obfuscate the true attack source, or to remain anonymous when conducting
other illegitimate activities. Additionally, if the compromised proxy is
situated behind a firewall, it could potentially be used to gain further
access to the network from which it resides.
>
> Port scanning from a generalised perspective is not uncommon and is one of
the most popular techniques an attacker uses to discover listening hosts and
services. Port scanning activity can be loosely defined into three
categories, Horizontal Scanning (many hosts targeted looking for few
services on each), Vertical Scanning (few hosts targeted looking for
multiple services on each) or Block Scanning (many hosts many services). By
correlating the log evidence available in this detect, combined with these
established scanning definitions we can class the attack in this instance as
a vertical scan.
>
> Based on the log evidence alone we can only speculate that the attacker
was performing network reconnaissance in an attempt to find listening proxy
services. On this basis there are no specific CVE entries that suggest the
above proxy services are vulnerable to simple SYN connection requests. There
is however a variety of exploitable vulnerabilities with regards to specific
proxy services if the attacker was so inclined to discover and exploit them.
Since we are unaware of the attackers exact intentions and attack vectors
available in his/her arsenal, it would be impractical in this case to
explore and explain all vulnerabilities related to all proxy services. To
summarise, this attack only represents a reconnaissance effort with no
immediate threat, however, this activity should not be ignored on these
grounds because reconnaissance activities are usually a precursor to more
intrusive attacks.
>
> Attack Mechanism:
>
> In this detect, the attacker specifically targeted 46.5.130.100 and sent
multiple SYN packets to TCP ports 1080,3128 and 8080. The duration of the
scan occurred between the timestamps of 15:15:12 and 15:18:45, during which
28 SYN packets were captured in total.
>
> By analyzing all available log data, it appears the attacker failed to
discover any listening proxy services running on the target. A target host
listening on these ports would reply with a SYN-ACK packet once the SYN
packet was received. The fact that there was no such response would explain
why the attacker sent multiple SYN packets. The use of a static source port
and initial sequence number (ISN) for each connection attempt would also
confirm no response was established. For example: Each SYN packet sent to
port 8080/tcp had a static source port of 2550 and ISN of 1727560173 as
printed on the windump filter below:
>
> windump -n -r 2002.6.2 host 66.60.157.246 and port 8080
>
> 15:18:24.414488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33258701 0> (DF)
> 15:18:27.554488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33259001 0> (DF)
> 15:18:30.444488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33259301 0> (DF)
> 15:18:33.474488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33259601 0> (DF)
> 15:18:36.434488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33259901 0> (DF)
> 15:18:39.404488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33260201 0> (DF)
> 15:18:45.404488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
1727560173:1727560173(0) win 16384 <mss 1460,nop,
> wscale 0,nop,nop,timestamp 33260801 0> (DF)
> 28
>
> In addition, 7 SYN packets in total were sent within 21 seconds before
eventually giving up. After the first SYN packet was sent, the source host
waited 3 seconds for a SYN-ACK response. Since there was no such response,
another SYN packet was sent automatically using the same source port and ISN
as previous. All of these factors most likely indicate an automated process
that occurred because a connection could not be established. A similar
process also occurred with connection attempts to both 1080 and 3128. It
would appear that the attacker was reluctant to give up and move on to other
potential targets.
>
>  There are a number of possibilities why the desired SYN-ACK response was
not detected. Firstly, it’s possible that the host is currently offline.
Maybe the attacker knows the existence of proxy services on this host, but
is unaware of its current status. That would explain why the attacker was
persistent and specifically targeted this host rather than conducting a
horizontal scan across the entire network.  Secondly, it’s possible that the
targets firewall and/or border routers have IP filtering/ACL policies in
place that subsequently dropped the SYN packets before they even arrived at
the target host. Finally, it’s possible the target host was live, but
responded with a RST packet because it was not listening on these ports.
Since we didn’t detect any reply from the target host we could assume that a
firewall or router blocked such a response. This action is common to prevent
attackers gaining information based upon response type, which in-turn can
provide key hints with regards to a hosts current status, potential services
running or OS type etc. All such information would be used to collate a
profile of the potential victim(s) and perimeter defenses before an
attacking strategy can be implemented.
>
> By investigating the TTL field within each packet we could determine the
OS probably running on the source (although not 100% accurate). By reviewing
our complete detect we can see that every packet had a TTL value of 48. This
most likely means that the packet had to traverse over 16 hops to reach the
target host, thus the original TTL value was 64. On this basis we could
speculate that the packet was sent from a linux or freeBSD box. We can
further increase the probability of discovering the OS type by investigating
the set window size in each packet. All packets in this detect have a window
size of 16384, by default the following OS set this window size: FreeBSD,
and Windows 2000. Since Windows 2000 sets the TTL value to 128 not 64 we
could speculate that the source is most likely running FreeBSD. Again I must
emphasize that this is based upon probability and is not 100% accurate,
especially since the default TTL value can be configured and even spoofed.
>
> An article on Passive OS fingerprinting (p0f) detailing TTL and Windows
size values as per OS type can be viewed here:
>
> http://www.stearns.org/p0f/devel/p0f.fp
>
> The last question to address is what tool was the attacker using to aid in
the search for open proxies on ports 1080,3128 and 8080? In all probability,
the attacker conducted the scan with the assistance of a port-scanning tool
rather than conducting the reconnaissance on a manual basis (certainly the
slower alternative). A popular port-scanning tool such as Nmap is most
likely, but really any scanning tool that can identify remote hosts
listening on these ports could be used.
>
> Correlations:
>
> This scan type is not uncommon, while the reports of such activity have
been logged for quite some time now. Scanning activity for 1080/tcp has only
recently been knocked off the www.Incidents.org Top Ten List, however, it
will most likely regain a position in this chart due to its sporadic nature.
>
> The use of open proxy servers is so popular that many sites provide and
maintain a list of known open proxies to use. Some sites claim to provide
legitimate proxy services for all that require it:
>
> http://theproxyconnection.com/httplist.html
>
> With sites such as this you can become a proxy member that provides you
with a list of proxies available for use at any time. An example of another
site providing a list of anonymous proxy severs can be seen here:
>
> http://www.multiproxy.org/
>
> Whether these sites are really legitimate is another question, however,
sites do exist that illegally scan the Internet for open proxy servers. It
is possible that the attacker in this detect is attempting to maintain a
list of open proxy servers for sites such as this or for private use.
>
> Finally, many fellow GCIA participants have provided detailed analysis on
proxy scanning activity. Although a multitude of detects exist, one example
of such analysis can be seen here:
>
> http://cert.uni-stuttgart.de/archive/intrusions/2003/11/msg00053.html
>
> Evidence of active targeting:
>
> Based upon log evidence alone one could assume that this attacker actively
targeted the host located at 46.5.130.100. However, it’s possible that
additional scans have targeted hosts not monitored by this snort device, or
have been conducted over a time period not contained within our log file. A
larger selection of logs would need to be obtained for this to be confirmed.
It’s highly unlikely that an attacker with malicious intent would rely
purely on one proxy server, because most have a reputation for maintaining a
list of multiple proxies to abuse.  With this in mind its entirely possible
that this detect only represents a small part of the complete scanning,
maintenance and discovery process.
>
> Severity:
>
> The severity of this detect is calculated using the following formula:
>
> (Criticality + Lethality) – (System Countermeasures + Network
Countermeasures)
>
> Criticality = 1
>
> Since there is no information regarding network topology or services
running on this host we are unable to provide an accurate criticality
rating. Analysing the log file shows no evidence of the target host
conducting activity on any port. This was confirmed by the following filter
windump -n -r 2002.6.2 host 46.5.130.100. Only SYN packets from the
attacking source were printed on this filter. Without knowing what traffic
this host sends and receives makes it impossible to speculate what services
are running, thus will be rated as a non-critical system.
>
> Lethality = 2
>
> The scanning activity itself is not destructive in nature, however, this
reconnaissance activity is usually a precursor to a more intrusive attack.
If a follow-on exploit were successful the attacker would be able to conduct
a variety of illegitimate activities from anonymous web surfing to using the
host as a launch pad for successive attacks against other hosts. Although
the potential lethality is rated at level 3-4, the actual potential of
reconnaissance activity itself should only be rated at level 2.
>
> System Countermeasures = 3
>
> As we are unaware of the target systems response to the multiple SYN
packets, we are unable to confirm whether it’s running a proxy service on
TCP ports 1080,3128 or 8080. In addition, we are also unable to determine if
the host is allowing unauthorised access if it is indeed running a proxy
service. In this situation it’s best to play it safe and provide and average
score of 3. This will at least imply that improvements can be made to
booster system countermeasures.
>
> Network Countermeasures  =3
>
> The fact that a Snort device detected this attack proves the network does
at least have minimal defence mechanisms in place. Since there was no
response from the target we could assume that either the host is down, or
any SYN-ACK responses from the target is being blocked by the upstream
routers (assuming a service is running on these ports). It is of course
possible that these SYN packets never reached the target host because they
were dropped by ACL’s present on the border router. This is all speculation,
but all theories point to some form of defence mechanism in place. As there
is limited information with regards to network topology, while working on
the basis that something can always be done to strengthen your network
security stance, a modest 3 will be awarded.
>
> Total Score = -3
>
> Defensive recommendation:
>
> Since the attacker failed to find any listening proxy services on the
target host its highly likely the attacker moved on in search for less
protected networks. Nevertheless, aim to be proactive rather than reactive.
Ensure that any legitimate proxy servers are running fully patched and have
been security audited to confirm that unauthorized access is not permitted
from the external network. Achieve this via properly configured firewalls
and routers and utilize strong authentication and encryption to reduce the
risk of compromise. If you are not running any form of proxy server ensure
that your routers and firewalls are configured to drop any traffic destined
for TCP ports 1080,3128 and 8080.
>
> Multiple Choice Question:
>
> What service is commonly run on TCP port 3128?
>
> (a) SOCKS
> (b) Telnet
> (c) SQUID
> (d) ALT HTTP
> (e) SMTP
>
> The correct answer is (c). The Squid Proxy service is commonly run on TCP
port 3128.
>
> Part II Trace 3 References:
>
> [1]     http://www.incidents.org/logs/
> [2] http://www.snort.org/snort-db/sid.html?sid=615
> [3] http://www.snort.org/snort-db/sid.html?sid=618
> [4] http://www.snort.org/snort-db/sid.html?sid=620
> [5] http://project.honeynet.org/papers/finger/
> [6] http://www.dshield.org/pipermail/intrusions/2002-October/005636.php
> [7] http://windump.polito.it/docs/manual.htm
> [8]     http://www.insecure.org/nmap/
> [9] http://cert.uni-stuttgart.de/archive/intrusions/2003/11/msg00053.html
> _______________________________________________
> Intrusions mailing list
> Intrusions@xxxxxxxxxxxxxx
> http://www.dshield.org/mailman/listinfo/intrusions

_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions