The attackers used rpc.statd attack to get into the system. What modifications did they make to the break in process to both automate and make the process faster?

Prior to establishing a connection to the target host on port 39168 which is then used to execute shell commands, the attacker is setting up and pulling down connections on port 111, in most cases there are two or three connections being established at a time.   Given the quick succession of attacks these appear to be scripted. 

The actual UDP attack is tried three times in short succession and from different source ports.  I assume that this attack is setting up /bin/sh to be associated with port 39168, so that when this connection is made the attacker gets immediate shell access which is what appears to happen when the connection is made.  You can see “/bin/sh” in the payload of the UDP packet.  I was unable to determine how they select the port number or where it is communicated. 

I suppose the speeding up of the break-in is to setup the backdoor using the rpc.statd hack, so that the subsequent connection on port 39168 gets immediate shell access. 

These observations were made by sifting through a text dump of the entire trace.   It was a case of seeing which sessions actually sent useful data, then determining other activity form that IP address (I used notepad).  Once you know the port address for the session it is very easy to trace the thread.   

There were other sources attacking the host, but after looking at what these were doing I discounted them as not related to this specific hack. 

I was also able to track down information on the rpc.statd attack by looking at CERT (www.cert.org) and security focus (www.securityfocus.com) advisory databases.  I had a look at statd-toy.c by drow to see what was happening with the actual attack.

What system/country did the badguys come in from? 

The host where the connection has come from is 211.185.125.124 – this is a host at Kyongsan Purim Elementary School in KYONGBUK state in Korea.

The IP address 211.185.0.0 is assigned to Korea – this was determined from APNIC (www.apnic.org).  

More details on the address were gained from a whois service at  http://whois.nic.or.kr/english/index.html

What nationality are the badguys, and how were you able to determine this?

I suspect that the break was performed by a Romanian.   

The root kit was downloaded by a user soane from the server ftp.home.ro (which is in Romania).  You can see this if you work through the commands sent on the session associated with port 4450.

The root kit install also displays text in both English and another language, although I don’t know what language is.  

What do the answers to questions #1 and #2 tell us about the tactics the badguys are using?

They have been breaking into other hosts and using  these to launch further attacks. 

What did you learn from this challenge?

This is the first decode if have had to do for several years, so it has forced me to remember some things I had forgotten.  

I have learnt a little about SNORT – especially how much more I need  to find out.

I have become a little more familiar with the resources available for looking into security problems – particularly chasing down source addresses.

I also know now that I need to find out more about the exploits – I was unable to find a protocol description of the rpc.statd break.  There were code examples but I find these difficult to understand. 

How long did this challenge take you?

Getting started (finding SNORT and how to work it on windows 2000) = 1 hour

Reading the log file to find out = 4 hours

Working out what the rpc.statd vulnerability should look like = 2 hours

Chasing down the network addresses = 1 hour

Writing up was performed as I went.      Total = 8 hours.

I can think of two ways to obtain a copy of the root kit. 

1.        Logon to ftp.home.ro using the user id soane and the password that is also in the trace.   Then GET the file lk.tgz.  Probably the easiest.  Use tar -zxvf lk.tgz to unpack. The trace also shows the root kit being installed.

2.        The complete packet dump from the FTP session is in the trace.  So it would be possible to extract this from the binary (I am not familiar with TCPDUMP). 

 At worst you can use Perl (or similar) to extract the text dump of the transfer, convert these back to binary and pack it into an output file.  This would be