For my raw notes on what I tried please see the file mynotes.txt
This is a condensed version with details where appropriate.
The first thing I did was mount the filesystem:
mkdir fs
mount -o ro,loop,nodev,noexec honeypot.hda8.dd fs
after which I noticed that its layout looked like a RedHat install.
I verified that the sytem was a RedHat distribution:
cat etc/redhat-release
revealed it was most likely:
Red Hat Linux release 6.2 (Zoot)
I then listed some key directories using:
ls -lat dirname
to sort files by modification time.
This revealed a few suspicious file dates on key files:
bin/netstat
bin/ps
sbin/ifconfig
Next I looked for any evidence of a back door by examining inetd.conf, and the startup scripts in etc/rc.d and etc/rc.d/rc3.d
I chose rc3.d instead of the others by determining the default runlevel as
follows:
grep default etc/inittab
which gave 3 lines including:
id:3:initdefault:
showing that the system would boot in runlevel 3 by default.
By examining the startup scripts I found an unusual command at the end of rc.sysinit:
/usr/bin/lsattr -t1 -X53 -p
It was unusual as I was familiar with RedHat startup scripts and the arguments did not match what I'd expect for that command based on it's man page man lsattr.
I noted what services were presumably running (ie at runlevel 3) and that inetd.conf had most services closed off.
At this point I believed the rootkit had been installed but now I needed to prove it, identify the files that made it up and if possible recover it.
Previous to attempting this I'd never even heard of TCT so it was good to have
the opportunity to actually use it to see what I could recover:
bin/unrm /home/user/security/honeynet/honeypot.hda8.dd > unrm_output
and
bin/lazarus -h unrm_output
This generated a number of files which I then searched for evidence of the
rootkit. My first attemtp to grep for "uid" returned nothing so then I
tried:
grep root block/*.txt
This returned a number of files so I tried to narrow it down:
grep -i rootkit blocks/*
Binary file blocks/8499.p.txt matches
They used the word rootkit in their shell file! :)
An afterthought was that searching for "unset" or "#!\" may have been
a better option.
A typical rootkit script would want to unset
certain variables and would almost definitely include "#!/bin/sh" at
the start of the file.
I searched google (both web and usenet) for many of the words mentioned in the file. No luck there.
I identified words that needed translating and put them in a file: translate.txt
I found a file 9.z.txt that appeared to be a damaged version of the rootkit.
I tried to recover it:
mv 9.z.txt test.gz
gunzip test.gz
gunzip: test.gz: unexpected end of file
to no avail. :(
I identified what files comprised the rootkit and placed them in a file: files.txt
I examined the filestyem for evidence of these files (particularly the directories in dev) and found that the files were still there so that showed that the rootkit had been installed on the system.
My initial thoughts were that it may be a modified version of the Torn Kit?
http://www.cert.org/incident_notes/IN-2000-10.html
http://packetstorm.securify.com/UNIX/penetration/rootkits/
I decided to grep for a word that went in the email to find that file:
grep Satiru blocks/*
Binary file blocks/84383.m.txt matches
Binary file blocks/8499.p.txt matches
Took a break. I'd spent about two hours to this point and it was time to go home anyway.
I created this document and did a few final greps on the recovered blocks to see what else I might be able to determine.
The system had been hacked and a rootkit installed. The rootkit replaced a number of files with trojaned versions and installed a backdoor (lsattr). Without being able to recover the full tarball and not having access to the rootkit version of lsattr I couldn't be 100% sure as to the nature of the backdoor. However evidence (presence of a an ssh_hosts_key, etc) would tend to indicate that it was a copy off ssh. Possibly running on port 53.
Given the time and the insentive I'd make further attempts to identify and recover the original tarball and writeup in further detail what the shell script actually does. I may also have made further efforts to translate the text in the shell script.
1. Show step by step how you identify and recover the deleted rootkit from the / partition.
See above for steps taken. The full rootkit (tarball) was not recovered however
and I look forward to seeing if anyone managed to do that.
What files make up the deleted rootkit?
See files.txt
Bonus Question:
Was the rootkit ever actually installed on the system? How do you know?
Yes. Both the directories that it creates in dev were still present on the
filesystem and rc.sysinit had been modified.
As I was unable to recover the tarball I could not determine if the other files
were still the trojaned versions or had been recently restored from original
RPMs.