LOGS: GIAC GCIA Version 3.4 Practical Detect James Stevenson

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. Si
 nce 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 a
 ttacks.

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 a
 ttackers 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, espe
 cially 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