Re: LOGS: GIAC GCIA Version 3.4 Practical Detect James Stevenson

Enjoyed reading, very good wording.

One question about this is what other reasons might the
attacker have for looking for an open proxy besides
anonymity?  Hint:  search through this list as I'm sure
you'll find something.

Scott Renna CISSP/GCIA
Security Analyst



On Sat, 08 May 2004 15:36:58 -0400
 StevensonJA@xxxxxxx wrote:
> 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