Scan 18 Results

Analysis provided by Lance Spitzner, Sun Microsystems SunPS
The Honeynet Project


The Challenge:
On March 15, the honeypot 172.16.1.108 was compromised. Armed only with a Snort binary capture of the attack, your mission is to accomplish the following.

  1. 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?
  2. What system/country did the badguys come in from?
  3. What nationality are the badguys, and how were you able to determine this?
  4. What do the answers to questions #1 and #2 tell us about the tactics the badguys are using?
  5. What did you learn from this challenge?
  6. How long did this challenge take you?
Bonus Question:
Can you recover the blackhat's rootkit from the Snort binary log file? If so, how?

The Analysis:
The first step is to download the file and confirm the MD5 Checksum, this validates the integrity of the file. Then the analysis can begin. wget(1) is a Unix utility that retrieves files from the World Wide Web.

$wget http://project.honeynet.org/scans/scan18/[email protected]
$md5 [email protected]
9b68e8ffade74bbf5ce0296a1977d111 [email protected]
$tar -zxvf [email protected]
Once we have downloaded and confirmed the integrity of the file, we can begin analysis. However, we like to first extract data from the binary file, as this will make the data analysis easier. We extract two forms of data. First, we will extract all the packets going to the system 172.16.1.108. This will give us easy access to all the traffic to and from the compromised system. Notice how exclude port 20, for packet review we will not need any binary ftp downloads. Second, we will extract all the ASCII information from the binary log file, including activity such as telnet, ftp and http sessions. This will make it easier to extract any cleartext activity from the attacker. At times, we will still want to reference the actual binary log file, however this data extraction will make some analysis easier.

Packet extraction
snort -vdr [email protected] host 172.16.1.108 and not port 20 > snort.txt

ASCII cleartext extraction
mkdir log
snort -dr [email protected] -c snort.conf -l ./log

We can now use the data extracted to snort.txt and ./log directory to better analyze the attack. The first thing we will notice is that our honeypot went on online at 15 March. This is why that the honeypot does not respond to any connections before 12:30, because there is honeypot to respond. At 12:34 the system is now online and excutes whois to test online connectivity.

03/15-12:34:07.018434 172.16.1.108:1025 -> 216.168.224.69:43
TCP TTL:63 TOS:0x0 ID:63 IpLen:20 DgmLen:60 DF
******S* Seq: 0x73088CB4 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 75198 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/15-12:34:07.189410 216.168.224.69:43 -> 172.16.1.108:1025
TCP TTL:240 TOS:0x0 ID:44765 IpLen:20 DgmLen:60
***A**S* Seq: 0xDC2B3D6C Ack: 0x73088CB5 Win: 0x2798 TcpLen: 40
TCP Options (6) => NOP NOP TS: 1214982934 75198 NOP WS: 0 MSS: 1460

Now that we have determined when the system went online, we can begin our analysis.

1. What modifications did they make to the break in process to both automate and make the process faster?
We are dealing with an autorooter, an automated tool that scans, probes, attacks and roots vulnerable systems. We can see this process in the packet traces. First, we see the automated tool probe for vulnerable systems. Once identified, the automated tool kicks in. Notice how the tool scans every IP address in the network. When if finds someone running rpc services (port 111) it queries for statd. If it gets confirmation that statd is running, it immedaitely runs the exploit. Notice how no attempt is made to determine the operating systems nor the architecture, the attack is simply launched. This is confirmed when the tool attacks honeypot 172.16.1.103, a Solaris SPARC system. So the tool has been created to scan all IPs within a given range, identify ANYTHING running rpc.statd, then attack it. If you put rpc.statd on a coffe pot, this tool would attack it. Lets review the attack by looking at the Snort decode of the attack. We begin with the initial network sweep on port 111.

03/15-20:21:23.840485 211.185.125.124:3493 -> 172.16.1.101:111
TCP TTL:43 TOS:0x0 ID:28754 IpLen:20 DgmLen:60 DF
******S* Seq: 0x9B8A127C Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 23678607 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/15-20:21:23.857472 211.185.125.124:3495 -> 172.16.1.103:111
TCP TTL:43 TOS:0x0 ID:28756 IpLen:20 DgmLen:60 DF
******S* Seq: 0x9B6B33C0 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 23678607 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/15-20:21:23.863730 211.185.125.124:3494 -> 172.16.1.102:111
TCP TTL:43 TOS:0x0 ID:28755 IpLen:20 DgmLen:60 DF
******S* Seq: 0x9B6A9C03 Ack: 0x0 Win: 0x7D78 TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 23678607 0 NOP WS: 0

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


We then see our system scanned and exploited.

03/15-20:21:24.107053 211.185.125.124:3500 -> 172.16.1.108:111
TCP TTL:43 TOS:0x0 ID:29726 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x9B6338C5 Ack: 0x5820ADD0 Win: 0x7D78 TcpLen: 32
TCP Options (3) => NOP NOP TS: 23678634 2878772

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/15-20:21:24.452051 211.185.125.124:789 -> 172.16.1.103:111
UDP TTL:43 TOS:0x0 ID:29733 IpLen:20 DgmLen:84
Len: 64
01 0A 8A 0A 00 00 00 00 00 00 00 02 00 01 86 A0 ................
00 00 00 02 00 00 00 03 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 01 86 B8 00 00 00 01 ................
00 00 00 11 00 00 00 00 ........

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/15-20:21:24.730436 211.185.125.124:790 -> 172.16.1.103:32773
UDP TTL:43 TOS:0x0 ID:29781 IpLen:20 DgmLen:1104
Len: 1084
47 F7 9F 63 00 00 00 00 00 00 00 02 00 01 86 B8 G..c............
00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 20 ...............
3A B1 5E E5 00 00 00 09 6C 6F 63 61 6C 68 6F 73 :.^.....localhos

... followed by the tool confirming a successful exploit ...

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

03/15-20:21:36.539731 211.185.125.124:4450 -> 172.16.1.108:39168
TCP TTL:43 TOS:0x0 ID:31660 IpLen:20 DgmLen:71 DF
***AP*** Seq: 0x9C6D2BFF Ack: 0x59606333 Win: 0x7D78 TcpLen: 32
TCP Options (3) => NOP NOP TS: 23679878 2880015
63 64 20 2F 3B 20 75 6E 61 6D 65 20 2D 61 3B 20 cd /; uname -a;
69 64 3B id;

Notice how this entire process is automated, from the scan, identification, to explotation. The attacker is most likely scanning thousands, if not millions, of systems using an autorooter. Amost all the steps involved in attacking a system have been combined into a single tool. This makes early warning and prediction far more difficult.

2. What system/country did the badguys come in from?
The source IP address of the attack is 211.185.125.124. We look up the IP address on ARIN and see the IP block belongs to Kyongsan Purim Elementary School, a grade school located 171 puki-1ry jinrang-eup kyongsan-ci, Korea. We determined this using several whois lookups.

3. What nationality are the badguys, and how were you able to determine this?
These attackers are most likely Romanian. We are able to determine this via several factors. Upon gaining access to the system, they ftp'd out to a Romanain system, which they had a shell account, and retrieved the rootkit , lk.tgz, which has also elements written in Romanain. The Honeynet Project was able to confirm the Romanian identify the following day, when they started up several IRC channels and spoke in Romanian.

4. What do the answers to questions #1 and #2 tell us about the tactics the badguys are using?
First, these attackers are most likely not interested in so much which systems they compromise, just how many. They are going after number of systems. This can be seen in the use of an automated tool scanning entire network blocks and attacking anything that looks vaguley vulnerable. Second, we see them coming from a foreign IP address. This implies that the source attacking system has also been compromised, and is being used by the attacker to relentlessy scan and attack as many systems as possible. This makes it more difficult to identify and track down the attacker.

5. What did you learn from this challenge?
The system (and system admin) that is attacking you may not be the one responsible for the actual attack. In the case of this challenge, it is most likely not Koreans that are attacking us, but Romanians. This exercise gives me the opportunity to express a personal rant of mine. Far to often I see administraters posting on maillists how elite they are by retaliating against systems that attacked them. They express pride in taking out the system that scanned them. I have serious concerns about this behavior. For example, in the case of this challenge, we were attacked by an IP from Korea. However, if we had retaliated against this site, we most likely would have taken out some innocent 3rd graders, very 'elite' indeed. What if the source IP had been a Hospital instead, and we attacked that? The Honeynet Project urges administrators to refrain in attacking source IP addresses. Instead, attempt to contact the admins of the compromised systems and educate them, that way everyone benefits.

6. How long did this challenge take you?
Four hours, with another two hours developing the documentation.

Bonus Question:
Can you recover the blackhat's rootkit from the Snort binary log file? If so, how?

Recovering the toolkit from the data stream can easily be done using the outstanding tool ethereal, it has a TCP recovery feature designed specifically for this. To recover the data file, you open the binary log file in Ethereal, find one of the FTP packets, right click on it, select TCP Stream from the options, then save the file (ASCII format) to the file name you want. Once recovered, you will have the rootkit, called lk.tgz. For some reason, I had an invalid compressed data error, but was able to recover almost the entire rootkit.


The Honeynet Project