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?