Downloaded honeypot.tar.gz from project.honeynet.org
# md5sum honeynet.tar.gz 0dff8fb9fe022ea80d8f1a4e4ae33e21 honeynet.tar.gz
# md5sum honeypot.hda8.dd 5a8ebf5725b15e563c825be85f2f852e honeypot.hda8.dd
MD5 Sums match those advertised on http://project.honeynet.org/scans/scan15
Mount resulting disk image using loopback device:
# mkdir /t # mount -o ro,loop,nodev,noexec honeypot.hda8.dd /t
Download The Coroners Toolkit from http://www.procupine.org/forensics/tct-1.06.tar.gz
Extract The Coroners Toolkit # tar zxvf tct-1.06.tar.gz
Resulting files in tct-1.06
Follow instructions in README.FIRST and INSTALL to compile TCT.
Run the TCT grave-robber with the following options (I did as suggested and read the Forensic Challenge Results, thanks Dave D for your write-up)
# pwd /home/honeynet/scan15/tct-1.06/scan15 # ../bin/grave-robber -c /t -m -d . -o LINUX2 # ../bin/ils honeypot.hda8.dd | ../extras/ils2mac > hda8.body # cat body hda8.body>body-full
Have a look to see what dates files were changed in /bin (/t/bin)
# ls -lat /t/bin
--[snip]-- lrwxrwxrwx 1 root root 4 Mar 15 22:10 sh -> bash* -rwxr-xr-x 1 root root 35300 Feb 27 02:23 netstat* -rwxr-xr-x 1 root root 33280 Feb 27 02:23 ps* -rwxr-xr-x 1 root root 2448 Mar 9 2000 doexec* -rwxr-xr-x 1 root root 19228 Mar 9 2000 ipcalc* -rwxr-xr-x 1 root root 16252 Mar 9 2000 usleep* --[snip]--
We can see that netstat & ps have different dates to the other files, as do the links. Now the same for /t/sbin.
# ls -lat /t/sbin
--[snip]-- lrwxrwxrwx 1 root root 4 Mar 15 22:10 reboot -> halt* lrwxrwxrwx 1 root root 4 Mar 15 22:10 telinit -> init* -rwxr-xr-x 1 root root 19840 Feb 27 02:23 ifconfig* -rwxr-xr-x 1 root root 22912 Mar 9 2000 chkconfig* -rwxr-xr-x 1 root root 2684 Mar 9 2000 consoletype* --[snip]--
ifconfig seems to have a different timestamp here, but the timestamp is the same as the other 2 files that have different time stamps..
The above would indicate that the following files form at least part of the rootkit, there are probably other files too, somewhere else.
netstat ps ifconfig
These tools are most likely to hide the other rootkit tools, comprising at least a sniffer (for which ifconfig hides promiscuity, and ps & netstat hide other attributes). I'd be surprised if there is not s
Lets use 15 March 2001 as the date to check from
# ../bin/mactime -p /t/etc/passwd -g /etc/group -b body-full 03/15/2001 > mactime.txt
Going through the resulting mactime.txt it appears as though the system was actually installed on March 15. Lots of files are being created/modified, including a lot of init scripts and their corresponding links in rc<n>.d. (Maybe this box was the system in question on the Honeynet Home Page?).
|
Based on our research, we have identified
the following. |
System installation ends at Mar 15 2001 22:20:39 (GMT+10).
First access after install is complete is to /etc/HOSTNAME on Mar 16 2001 04:22:25 (which now contains asdf1).
The next file that is created is /lib/modules/2.2.14-5.0/modules.dep
--[snip]--
Mar 15 01 22:20:38 160 m.c -rw-r--r-- root root /t/etc/lilo.conf
Mar 15 01 22:20:39 160 .a. -rw-r--r-- root root /t/etc/lilo.conf
Mar 16 01 04:22:25 6 mac -rw-r--r-- root root /t/etc/HOSTNAME
Mar 16 01 04:22:30 1024 m.c drwxr-xr-x root root /t/lib/modules/2.2.14-5.0
28633 m.c -rw-r--r-- root root /t/lib/modules/2.2.14-5.0/modules.dep
Mar 16 01 04:22:34 60 mac -rw------- root root /t/etc/ioctl.save
13708 .a. -rwxr-xr-x root root /t/etc/rc.d/rc.sysinit
14 .a. lrwxrwxrwx root root /t/etc/rc.d/rc3.d/K05innd -> ../init.d/innd
Mar 16 01 04:22:35 13 .a. lrwxrwxrwx root root /t/etc/rc.d/rc3.d/K20nfs -> ../init.d/nfs
16 .a. lrwxrwxrwx root root /t/etc/rc.d/rc3.d/K20rstatd -> ../init.d/rstatd
17 .a. lrwxrwxrwx root root /t/etc/rc.d/rc3.d/K20rusersd -> ../init.d/rusersd
--[snip]--
The file /t/etc/ioctl.save seems to correspond with at the very least a change in runlevel, if not a reboot. There is a lot of activity in /t/etc/rc3.d. It looks like X is not running on this system, and the runlevel is being set to 3, which in turn causes a whole lot of other file accesses. Checking this behaviour on my system I can confirm that the file gets written at reboot.
Recovering deleted files
# grep "\-dead\-" macfiles.txt
--[snip]--
Feb 09 02 00:08:13 611931 m.. -rwxr-xr-x root root <honeypot.hda8.dd-dead-2039>
33135 mac -rw-r--r-- root root <honeypot.hda8.dd-dead-56231>
16 ma. lrwxrwxrwx root root <honeypot.hda8.dd-dead-12107>
16 ma. lrwxrwxrwx root root <honeypot.hda8.dd-dead-20883>
16 ma. lrwxrwxrwx root root <honeypot.hda8.dd-dead-28172>
16 ..c lrwxrwxrwx root root <honeypot.hda8.dd-dead-12107>
239 .ac -rw-r--r-- root root <honeypot.hda8.dd-dead-16110>
16 ..c lrwxrwxrwx root root <honeypot.hda8.dd-dead-20883>
16 ..c lrwxrwxrwx root root <honeypot.hda8.dd-dead-28172>
66736 .a. -rwxr-xr-x root root <honeypot.hda8.dd-dead-30188>
42736 .a. -rwxr-xr-x root root <honeypot.hda8.dd-dead-48284>
Mar 16 01 04:29:12 60080 .a. -r-xr-xr-x root root <honeypot.hda8.dd-dead-30191>
Mar 16 01 12:36:48 520333 m.. -rw-r--r-- root root <honeypot.hda8.dd-dead-23>
611931 .a. -rwxr-xr-x root root <honeypot.hda8.dd-dead-2039>
1 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-2040>
1345 .a. -rwxr-xr-x root root <honeypot.hda8.dd-dead-2043>
880 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-2048>
344 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-2050>
688 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-2052>
520333 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-23>
4060 .a. -rwxr-xr-x root root <honeypot.hda8.dd-dead-2047>
8268 .a. -rwx------ root root <honeypot.hda8.dd-dead-2053>
53588 .ac -rwxr-xr-x root root <honeypot.hda8.dd-dead-2058>
75 .a. -rwx------ root root <honeypot.hda8.dd-dead-2059>
66736 ..c -rwxr-xr-x root root <honeypot.hda8.dd-dead-30188>
60080 ..c -r-xr-xr-x root root <honeypot.hda8.dd-dead-30191>
42736 ..c -rwxr-xr-x root root <honeypot.hda8.dd-dead-48284>
3278 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-2044>
79 .a. -rwxr-xr-x root root <honeypot.hda8.dd-dead-2045>
11407 .a. -rw-r--r-- root root <honeypot.hda8.dd-dead-2046>
4060 ..c -rwxr-xr-x root root <honeypot.hda8.dd-dead-2047>
540 .ac -rw------- root root <honeypot.hda8.dd-dead-2049>
512 .ac -rw------- root root <honeypot.hda8.dd-dead-2051>
--[snip]--
Our first deleted file to recover was deleted on Feb 09.
# ../bin/icat honeypot.hd8.dd 2039 > 2039
Turns out this inode was reused later and was deleted again on 12:44:50
# strings 2039
--[snip]--
Usage: %s [options] host [command]
Options:
-l user Log in using this user name.
-n Redirect input from /dev/null.
-a Disable authentication agent forwarding.
-x Disable X11 connection forwarding.
-i file Identity for RSA authentication (default: ~/.ssh/identity).
-t Tty; allocate a tty even if command is given.
-v Verbose; display verbose debugging messages.
-V Display version number only.
-q Quiet; don't display any warning messages.
-f Fork into background after authentication.
-e char Set escape character; ``none'' = disable (default: ~).
-c cipher Select encryption algorithm: ``idea'', ``blowfish'', ``3des''
-p port Connect to this port. Server must be on the same port.
-P Don't use privileged source port.
-L listen-port:host:port Forward local port to remote address
-R listen-port:host:port Forward remote port to local address
These cause %s to listen for connections on a port, and
forward them to the other side by connecting to host:port.
-C Enable compression.
-g Allow remote hosts to connect to local port forwardings
-o 'option' Process the option as if it was read from a configuration file.
Using rsh. WARNING: Connection will not be encrypted.
setuid: %.100s
rlogin
slogin
/usr/bin/rsh
/rlogin
You don't exist, go away!
ssh1
slogin1
ssh.old
slogin.old
ssh1.old
slogin1.old
remsh
eilcpLRo
Warning: Identity file %s does not exist.
Too many identity files specified (max %d)
i586-unknown-linux
1.2.30
SSH Version %s [%s], protocol version %d.%d.
Standard version. Does not use RSAREF.
--[snip]--
Looks like this is an ssh 1.2.30 client.
10/05/2001 23:45 - 2:15Processing all deleted files using above commands yields the following when determining the file types:
--[snip]-- ./files/23: gzip compressed data, deflated, last modified: Sat Mar 3 14:09:06 2001, os: Unix ./files/2038: empty ./files/2039: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped ./files/2040: ASCII text ./files/2041: Bourne shell script text executable ./files/2042: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped ./files/2043: Bourne-Again shell script text executable ./files/2044: ASCII English text ./files/2045: Bourne shell script text executable ./files/2046: ASCII English text ./files/2047: perl script text executable ./files/2048: ASCII English text ./files/2049: data ./files/2050: ASCII text, with very long lines ./files/2051: data ./files/2052: ASCII text ./files/2053: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped ./files/2054: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped ./files/2058: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped ./files/2059: ASCII text ./files/2060: ASCII text ./files/2061: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped ./files/8097: empty ./files/8100: ASCII English text ./files/12107: empty ./files/16110: ASCII text ./files/20883: empty ./files/22103: empty ./files/22104: empty ./files/22105: empty ./files/22106: empty ./files/22107: empty ./files/22108: empty ./files/28172: empty ./files/30188: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped ./files/30191: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped ./files/48284: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), stripped ./files/56231: ASCII text, with no line terminators --[snip]--
The first file looks most interesting since it is an archive and probably contains other files. Lets get a list of the contents:
# tar tvf 23
drwxr-xr-x 1031/users 0 2001-02-27 07:40:30 last/ tar: Archive contains future timestamp 2002-02-09 00:08:13 -rwxr-xr-x 1031/users 611931 2002-02-09 00:08:13 last/ssh -rw-r--r-- 1031/users 1 2001-02-27 02:29:58 last/pidfile -rwx------ 1031/users 3713 2001-03-03 14:08:37 last/install -rwx------ 1031/users 7165 2001-02-27 02:22:50 last/linsniffer -rwxr-xr-x 1031/users 1345 1999-09-10 01:57:11 last/cleaner -rw-r--r-- 1031/users 3278 2001-01-28 02:11:32 last/inetd.conf -rwxr-xr-x 1031/users 79 2001-02-27 02:28:40 last/lsattr -rw-r--r-- 1031/users 11407 2001-01-28 02:11:44 last/services -rwxr-xr-x 1031/users 4060 2001-02-27 02:22:55 last/sense -rw-r--r-- 1031/users 880 2000-10-23 06:29:44 last/ssh_config -rw------- 1031/users 540 2000-10-23 06:29:44 last/ssh_host_key -rw-r--r-- 1031/users 344 2000-10-23 06:29:44 last/ssh_host_key.pub -rw------- 1031/users 512 2000-10-23 06:29:44 last/ssh_random_seed -rw-r--r-- 1031/users 688 2001-02-27 02:29:51 last/sshd_config -rwx------ 1031/users 8268 2001-02-27 02:22:59 last/sl2 -rwxr-xr-x 1031/users 4620 2001-02-27 02:23:10 last/last.cgi -rwxr-xr-x 1031/users 33280 2001-02-27 02:23:33 last/ps -rwxr-xr-x 1031/users 35300 2001-02-27 02:23:42 last/netstat -rwxr-xr-x 1031/users 19840 2001-02-27 02:23:47 last/ifconfig -rwxr-xr-x 1031/users 53588 2001-02-27 02:23:55 last/top -rwx------ 1031/users 75 2001-02-27 02:24:03 last/logclear -rw-r--r-- root/root 708 2001-03-03 14:05:12 last/s -rwxr-xr-x 1031/users 632066 2001-02-27 01:46:04 last/mkxfs
This means that our rootkit has now been recovered.
Based on size and type these files match some of our deleted files. Lets take a look at the install script.
--[snip]-- #!/bin/sh clear unset HISTFILE echo "********* Instalarea Rootkitului A Pornit La Drum *********" echo "********* Mircea SUGI PULA ********************************" echo "********* Multumiri La Toti Care M-Au Ajutat **************" echo "********* Lemme Give You A Tip : **************************" echo "********* Ignore everything, call your freedom ************" echo "********* Scream & swear as much as you can ***************" echo "********* Cuz anyway nobody will hear you and no one will *" echo "********* Care about you **********************************" echo --[snip]--
Can't seem to work out what language that is.. could be Malay or
Indonesian, but then some searches for the words in the first three lines seem
to indicate that it's Romanian. No luck trying to translate it at any of
the translation sites.
The install script then goes on to replace the various system files with the rootkit files & writes some names of processes/files etc to remain invisible to the administrator when running the backdoored tools.
/dev/rpm
3 sl2 3 sshdu 3 linsniffer 3 smurf 3 slice 3 mech 3 muh 3 bnc 3 psybnc
/dev/last
1 193.231.139 1 213.154.137 1 193.254.34 3 48744 3 3666 3 31221 3 22546 4 48744 4 2222
It then copies all the backdoored files to two folders (presumably in case one gets found)
"/dev/ida/.. "
/dev/ida/.drag-on
The first of these two files looks like it contains strings that the backdoored ps should hide, while the second file contains strings (subnets, ports) that the backdoored netstat command should hide. Lets see if we can find the file names in the strings of either of these programs.
# strings ps
No trace of /dev/rpm , but there is a reference to /dev/dsx and that device doesn't exist on the system! Same applies for top.
17/05/2001 11:00 - 0:30# strings netstat
No trace of /dev/last, references to /dev/caca and /dev/route, neither of which exist.
Doing a strings on the ifconfig binary reveals that the PROMISC flag has been stripped from it (as compared with the ifconfig from my system anyway).
Continuing on with the install script, /etc/inetd.conf and /etc/services get overwritten with rootkit versions, and inetd gets told to re-read its configuration files. I can't find anything obviously nasty here, except maybe just the telnet daemon being enabled.
Next /usr/bin/lsattr is replaced by a script that starts a backdoored ssh server (mkxfs) and linsniffer, and a line is added to the end of /etc/rc.d/rc.local. We cannot actually see anything that was in /usr since that was on a different filesystem. The /dev/ida/.drag-on/s configuration file is used by the ssh server, and specifies that it should bind to port 5 (from snort port search database - Remote Job Entry) which is not often used. Linsniffer is configured to log to /dev/ida/.drag-on/tcp.log. There is a small amount of data in this file, but nothing of any value. The immutable flag is set on /usr/bin/lsattr, preventing normal operations from making any changes to the file. The immutable flag would have to be removed to do anything to the file.
The install script then goes looking for a web server cgi-scripts folder to put the last.cgi file in. last.cgi appears to allow a remote user to run arbitrary commands through the web server (perhaps to restore /dev/ida/.drag-on with files from /dev/ida/".. ").
Before cleaning up, the install script collects some system information using uname, hostname, ifconfig, uptime, cpuinfo and mails it off to last@linuxmail.org and bidi_damm@yahoo.com with subject lines "placinte" and "root" respectively.
17/05/2001 14:00 - 1:00The file that was at deleted inode 2050 contains an email address (root@dil2.datainfosys.net) along with a long string of numbers which looks like an ssh key, matches rootkit's ssh_host_key.pub.
The full list of files that makes up our rootkit is as follows:
lk.tgz or lk.tar.gz - Our rootkit tarball
Filename |
Purpose |
|---|---|
cleaner* |
cleaner of system log files |
ifconfig* |
backdoored ifconfig without PROMISC flag to hide linsniffer |
inetd.conf |
replacement inetd.conf |
install* |
rootkit installation script |
last.cgi* |
backdoor cgi binary for web server |
linsniffer* |
traffic sniffer |
logclear* |
script to clear linsniffer log file |
lsattr* |
script to launch backdoored sshd and linsniffer at system startup |
mkxfs* |
backdoored sshd |
netstat* |
backdoored netstat to hide network connections by IP or port number |
pidfile |
process id file for mkxfs |
ps* |
backdoored ps binary to hide processes matching certain names |
s |
configuration file for mkxfs |
sense* |
perl script to sort through data captured by linsniffer |
services |
replacement services file |
sl2* |
not sure, maybe some sort of port scanner, strings indicate an ip address should be specified along with a low and high port number |
ssh* |
secure shell client, apparently not used as it does not get copied anywhere and is deleted at the end of install script |
ssh_config |
secure shell client config file |
ssh_host_key |
secure shell host key (private) |
ssh_host_key.pub |
secure shell host key (public) |
ssh_random_seed |
secure shell random seed file |
sshd_config |
secure shell server basic config file |
top* |
backdoored top binary to hide processes matching certain names |
The installation script was certainly executed, since a whole bunch of the files exist where the script places them. Whether the installation was actually successful is another question. The files were definitely placed where the install script intended to place them, /dev/ida/.drag-on and /dev/ida/".. ", with the configuration files for ps,top and netstat in /dev. The tarball file was deleted, as were the files extracted from it. Also the /etc/services and /etc/inetd.conf files match those supplied with the rootkit. The linsniffer was very briefly used prior to 17/03/2001 03:28 (GMT+10), since that is the last time of modification, though nothing shows up in mactimes after the initial creation of the file. There is no definitive way to tell if the last.cgi file ever got installed since it would have lived on a different file-system that is not available to us, nor can we see if the log files were cleaned using the cleaner script (written by someone of German origins).
Three of the four backdoored binaries that were installed in /bin and /sbin
had (as far as I was able to determine) different configuration file
requirements than those created by the install script. The install script
created /dev/rpm for ps and top, and /dev/last for netstat. Since the
binaries had references to /dev/dsx and /dev/caca respectively I would think
that the configuration files won't actually be found, and thus the rootkit would
not be doing its job properly, and thus would be easier to spot.
| Name | Time Spent | Yrs Sysadmin/Security |
|---|---|---|
| John Berkers | 8:00 | 6/0.5 |