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 %

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).

Using Snort

We choosed to run the original day1.log
and day3.log tcpdump file
through snort and see what comes up. Since snort has many attack
signatures, we may get the list of IP address attacking the
honeypot, and their attack ID.

After installing the snort, and disabling all the commented rules
and preprocessors in the snort.conf file, we
execute the following command (respectively for day3.log) :

$ snort -r day1.log -c /etc/snort/snort.conf

Alerts generated as a result to processing these tcpdum files have
been used to detect some attacks performed or vulnerabilities
exploited. We will refer to these alerts for the analysis of some
questions.

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) :

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.

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.

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 :

The psyBNC was successfully configured on port 7000 as the honeyport
reported to the attacker over the packet # 8315. So, each system is
using that port to communicate, it is potentially attacking the
honeypot.

The following filter reveals these systems communicating with Cryphon
protocol :

The IRC traffic was generated then as a sequence to the Gryphon
session. In fact, the attacker requested the honeypot to initiate IRC
sessions which were been used in the attack. The following tethereal
filter determine the involved systems.

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 :

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.

After, running dtspcd with success, Attacker connects to the
shell available on port 1524. Next, he has issued many commands :

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.

Get the rootkit "sol.tar.gz" from
http://62.211.66.53:80/bobzz/sol.tar.gz

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).

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 ofStacheldraht).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 :

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.