Scan 29
http://www.honeynet.org/scans/scan29/
Write Up by Daniele Muscetta - daniele@muscetta.com - www.muscetta.com - September 2003
The Challenge:
On August 10, 2003 a Linu Red Hat 7.2 system was compromised.
The mission assigned is to analyze the compromised system. What
makes this challenge unique is we are to analyze a live system.
The image in question was ran within VMware. Once compromised,
the image was suspended. The challenge to us is to download the
suspended image, run it within VMware (we will get a console to
the system with root access), and respond to the incident. When
responding to the incident, we may do a live analysis of the system
or we can first verify that the system has been compromised and
then take it down for a dead analysis (or a combination of both).
In either case, we will be expected to explain the impact you
had on the evidence. Fortunately, this system was prepared for
an incident and MD5 hashes were calculated for all files before
the system was deployed.
Pre-Analysis
Note, this image was recovered from VMware Workstation 4.0,
it will not work in older versions.
Since I do not own a license of VMware, I downloaded and used
an evaluation copy.
Suspended image (106MB) MD5 = d95a8c351e048bd7d5596d6fc49b6d72
- http://www.honeynet.org/misc/files/linux-suspended.tar.bz2
MD5 of all files of the system *before* it was compromised. -
http://www.honeynet.org/scans/scan29/linux-suspended-md5s.gz
Previously I downloaded the two files, verified their md5 checksums
and proceeded to uncompress them. It looks like Every writeup
for a Scan of the month *HAS* to start with a verification of
the md5 checksums.
This should be routinely done for EVERY downloaded file. md5sum
filename, and see if the checksum matches the given one.
Now I think that at nearly 30 SOTM, we all know how to do
this.
After that, we need to prepare VMWare to use the virtual machine.
In my particular case I have been running the virtual machine
on the Windows version of VMWare, rather than the linux version
where it was originally created. No big deal, it is enough to
change a couple of settings in the virtual machine's config file
vmachinename.vmx (which is a text file), like changing the floppy
to "A:" instead than /dev/fd0 and other things like
that. Anyay these are details not 100% pertinent with the case
itself, rather with setting up out working environment.
Let's go then to the *real* thing. Let's go to my answers to
the questions:
[NOTE: To ease the reading, in the following pages I've used italic
font style for the descriptions of my actions, ideas and findings,
while the rest in normal style is intended to be commands or output
from the computer.]
Answers to the Questions and Analysis:
1. Describe the process
you used to confirm that the live host was compromised while reducing
the impact to the running system and minimizing your trust in
the system.
2. Explain the impact that your actions
had on the running system.
3. List the PID(s) of the process(es)
that had a suspect port(s) open (i.e. non Red Hat 7.2 default
ports).
4. Were there any active network connections?
If so, what address(es) was the other end and what service(s)
was it for?
5. How many instances of an SSH server
were installed and at what times?
6. Which instances of the SSH servers
from question 5 were run?
7. Did any of the SSH servers identified
in question 5 appear to have been modified to collect unique information?
If so, was any information collected?
8. Which system executables (if any) were
trojaned and what configuration files did they use?
9. How and from where was the system likely
compromised?
Bonus Question:
What nationality
do you believe the attacker(s) to be, and why?