Scan Of The Month 28

Summary Report



Written by Petros Papadopoulos ([email protected])


Question 1

What is the operating system of the honeypot? How did you determine that? (see day1)


Answer to Question 1: 

The first command the attacker send to the system after the successful compromise was (see packet 595 from day1.log)


                        uname –a


And the system responded (see packet 598 from day1.log)


SunOS zoberius 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-5_10


So it is a Solaris 8 Machine.






Question 2

How did the attacker(s) break into the system? (see day1)


Answer to Question 2: 

The attacker exploited a known buffer overflow Vulnerability in CDE Subprocess Control Service dtspcd which leads

to a remote compromise of a system. This is described in full detail in



This vulnerability gives the attacker root privileges on the target system. The buffer overflow happens at port 6112 

dtspcd (see packet 580 from day1.log). The attacker creates a shell on port 1524 (ingreslock) by


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


This is probably made from an automated tool (see Scan Of The Month 20 - Scan 20 - Solaris dtspcd attack.). The tool

before the buffer overflow checked both ports 6112 and 1524 to verify their status and possible ip filtering (see packets 561 & 564 from day1.log).



And then the attacker starts sending commands to the honeypot system using port 1524 (see packet 595 from day1.log). 







Question 3

Which systems were used in this attack, and how? (see day1)


Answer to Question 3: 

The Systems used in the attack were

1.    Honeypot – IP Address: This is the compromised system.


2.    Attacker – IP Address: From this address the attacker started the attack. All the commands to port 1524 from the attacker were given from this address.


3.    FTP Server Controlled by Attacker - IP Address: This Server was used from the attacker to download the files  wget, dlp, solbnc, iupv6sun to the honeypot.


4.    HTTP Server  Controlled by Attacker – IP Address: This server was used from the attacker to download the rootkit sol.tar.gz to the honeypot.


5.    SUN FTP Server ( This FTP server was accessed from the rootkit to download the patches, The rootkit is patching the system!


6.    Other hosts owned by attacker. The hosts  and are owned by attacker and the honeypot sends “heartbeat” (I’m alive) messages to them. Host connects to

     honeypot through the rootkit created port TCP 7000.


7.    IRC Server. Host was contacted from Honeypot to TCP port 5555 and tunnel IRC traffic.





Question 4

Create a diagram that demonstrates the sequences involved in the attack (see day1)


Answer to Question 4: 

The diagram follows. The numbers in the comments demonstrate the sequence of the events.




















Question 5

What is the purpose/reason of the ICMP packets with 'skillz' in them? (see day1)


Answer to Question 5: 

The  ICMP packets are only of type Echo Reply. There is no “echo” in order to respond with an “echo reply”. This is fake ICMP trying to fool those firewalls and access list routers which don’t understand what STATEFUL ICMP is. Stateful ICMP was considered “alien technology” from big firewall vendors only a couple of years ago.


These ICMP are used for “heartbeat” information. The compromised system is saying “I’m alive” to the “master” who controls it.

More on the “skillz” (found in day 1 & 3) and “ficken” (found in day 3) echo replies can be found on the DDOS analysis given by

1.    ISS Security Alert, February 9, 2000. “Denial of Service Attack using the TFN2K and Stacheldraht programs”
2.    David Dittrich, December 31, 1999.  ”The "stacheldraht" distributed denial of service attack tool”






Question 6

Following the attack, the attacker(s) enabled a unique protocol that one would not expect to find on a n IPv4 network. Can you identify that protocol and why it was used? (see day3)  


Answer to Question 6: 

The protocol used is the IP V6. It was used to tunnel IRC traffic. By using IP V6 IDS systems can’t detect the potential attack since they can’t decode IP V6 traffic. The V6 IP addresses were


Honeypot IP V6 =  2001:6b8:0:400::5d0e  

Attackers IRC Server IP V6 =  2001:750:2:0:202:a5ff:fef0:aac7  


The communication between these two starts at packet 117614 (day3.log) and it is an IRC Session.






Question 7

Can you identify the nationality of the attacker? (see day3)


Answer to Question 7: 

Yes, he is Italian. This is from the decoded IP V6 IRC session in their own(z) words … PONG :`OwnZ``

:_-PaKi-_![email protected] PRIVMSG #bobz :a giorni io cambio scheda madre

PRIVMSG `OwnZ`` :away

NICK `OwnZ`` 301 `OwnZ`` `OwnZ`` :-OwnZ-

:`OwnZ``![email protected] PRIVMSG `OwnZ`` :away

:_-PaKi-_![email protected] PRIVMSG #bobz :quindi cambio memorie

:_-PaKi-_![email protected] PRIVMSG #bobz :metto le ddr

:_-PaKi-_![email protected] PRIVMSG #bobz :se vuoi te regalo un modulo da 256

:_-PaKi-_![email protected] PRIVMSG #bobz ::P PONG :`OwnZ``


And more …. PONG :`OwnZ``

:RiValD|nO![email protected] PRIVMSG #bobz :la durA=?

:_-PaKi-_![email protected] PRIVMSG #bobz :ehehhehe

:_-PaKi-_![email protected] PRIVMSG #bobz :dura come il mio cazzo

:RiValD|nO![email protected] PRIVMSG #bobz :mhauHAUHauHAUhuahUH

:_-PaKi-_![email protected] PRIVMSG #bobz :visto che è 1 mese che nn scopo

:_-PaKi-_![email protected] PRIVMSG #bobz :ahuhuahuahuhuahuuhahuuha

:RiValD|nO![email protected] PRIVMSG #bobz :=°|

:RiValD|nO![email protected] PRIVMSG #bobz :beh.. buona scopata=P

:_-PaKi-_![email protected] PRIVMSG #bobz :si cion federika?

:_-PaKi-_![email protected] PRIVMSG #bobz :ahuhuahuhuahuua

:_-PaKi-_![email protected] PRIVMSG #bobz :a domani segaioli

:_-PaKi-_![email protected] PRIVMSG #bobz :ahuahuhuauhhuauhuauhhuhuahua

:RiValD|nO![email protected] PRIVMSG #bobz :maHUHUahUHAUhauHHH








Bonus Question 1

What are the implications of using the unusual IP protocol to the Intrusion Detection industry?


Answer to Bonus Question 1: 

The IDS vendors must update their products to include IP V6 support. Otherwise bad things might happen and the IDS will give zero information. In other words (Lance’s words actually from the focus-ids list).



From: Lance Spitzner (
Date: Dec 19 2002


Recently one of the Honeynet Project's Solaris Honeynets was compromised.
What made this attack unique was IPv6 tunneling was enabled on the system,
with communications being forwarded to another country. The attack and
communications were captured using Snort, however the data could not be
decoded due to the IPv6 encapsulation.

This made me consider, this activity could be used as a means of
"covert" communications or activity. Many IDS systems, and potentially
many sniffers, have difficulty decoding IPv6 activity. Was wondering if
others had seen this activity, and the implications it may have to the IDS





And don’t forget Marty’s words from the focus-ids list


IDS: EXPERIMENTAL IPv6 decoder available in Snort

From: Martin Roesch (
Date: Dec 20 2002


Hi everyone,
     Following up Lance's message regarding the usage of IPv6 tunneling on a
honeynet, I'd like to announce the availability of an *experimental* version
of Snort with an IPv6 decoder. This decoder is implemented to test Snort's
capability to analyze IPv6 and IPv6 tunneled over IPv4. Currently it
consists of a decoder and printing module only, so if you want to test it
and see the v6 output, just run 'snort -dv'.

If people would like to test the code out and see if it's working properly,
it can be downloaded and tested at:

This code currently doesn't have any components integrated into the
detection engine, so you can't tell Snort to look at IPv6 addresses or
header fields using the rules language yet. It is capable of looking for
standard embedded protocol headers and payloads in IPv6 tunneled over IPv4.

If people would like to test this code out, I'm primarily interested in
seeing if the code is stable and capable of decoding all v6 traffic without
any memory leaks or crashes. Unfortunately, my ability to generate v6
traffic for testing purposes is extremely limited right now, so I'm
depending on people with access to the right kind of networks to help out!

Once I'm happy with the decoder, I'll integrate IPv6 support into the
detection engine!









Bonus Question 2

What tools exist that can decode this protocol?


Answer to Bonus Question 2: 

My favorite is Ethereal. But from

We have

1.    Ethereal

2.    Analyzer

3.    WinDump

4.    WinPcap