Description
Introduction
Episode 12: “POST Mortem”
You are Chip Holmes, a private security consultant specializing in computer forensics with an office in a crumbling 5th story brownstone somewhere in The City. You consider yourself a digital detective — a grepping gumshoe if you will — helping people and organizations (such as companies, coppers, and wealthy individuals) investigate computer systems and files, typically when things have gone horribly wrong or something important is at stake. You had just poured yourself a strong cup of joe, put your
feet up on the desk and started reading The Times when your assistant Lefty called and told you to check your messages; some new clients called this morning and of course they all think it’s an emergency.
It was a pretty typical morning, all things considered. One client was looking for a binary bloodhound to investigate their server that was accused of being infected with a worm. The second client had some sensitive data stolen and they wanted some help interpreting the evidence. The third client was a little more interesting — it was a high rolling fat cat who was being extorted by black hat scum from some remote corner of the Internet. Typically, none of the clients had any network logs and you could be darn sure they didn’t have an Intrusion Detection System either, so the only information available was on the computers themselves.
You typically use a bootable “live CD” (such as Finnix) to create a disk image and cryptographic hash of each computer’s hard drive so you can inspect and manipulate the image without messing with the real thing. It takes a long time, but it’s the right way to do it. While you investigate the images, the real computers are powered off and in a vault somewhere, but every hour they remain offline in a “morgue” represents big bucks to the clients. The clients all want to know what happened, and what they should do next. Oh yeah, and they want to know yesterday!
Assignment Instructions
Setup
-
If you don’t have an account, follow the instructions in the introduction to DETER document.
-
Log into DETER.
-
Create an instance of this exercise by following the instructions here, using
/share/education/ComputerForensics_UCLA/forensics.ns as your NS File.
In the “Idle-Swap” field, enter “1”. This tells DETER to swap your experiment out if it is idle for more than one hour.
In the “Max. Duration” field, enter “6”. This tells DETER to swap the experiment out after six hours.
-
Swap in your new lab.
-
After the experiment has finished swapping in, log in to the node via ssh.
Because these labs are all based off of investigating stored, static disk images, you know that network scanners and the like will not be necessary. Furthermore, while “chain of custody” and related issues are very important in real life, they are not necessary for this lab — just careful investigation of evidence left on the disk and consideration of what may have happened.
Your analysis should be directly supported by the data on the disk image, or if it is unclear what happened exactly, explain why.
Beyond that, the basic method is:
-
Swap in the experiment.
-
cd into the /images directory on the experimental node workbench. (This experiment only has one node.)
-
Follow the instructions for loadimage.sh to load a disk image. loadimage.sh will copy the dd image from a network server to your workbench machine, but you’ll still have to mount it.
-
Use losetup and mount to mount the partitions. there are sda1 and sda2 directories in the /images directory; these are meant for you to mount the first and second partitions of the disk (root and swap).
-
After you have mounted the partition, cd into that directory and start working! You’ll probably find tools like hexedit, e2undel, strings, less, grep, and more useful. (See the tools section of this lab for some ideas.)
-
Use those tools (and any others as you desire) to try and answer the questions above. Find data that may be hiding, and analyze it in conjunction with the data left on the system in order to determine (as best as you can) what happened on the system.
Important: Do not use the /var/log/wtmp file for login information; you don’t need it, and the information in that file will be incorrect.
Tasks
Act I: The University Server
Your buddy, Bob, is now a professor of Computer Science at some big school here in The City. He got an angry email from the Network Operations Center (NOC) at the University saying that his lab’s server was infected with a worm — the NOC determined this because of a huge spike in Internet traffic which occurred at 4 in the morning. He immediately shut it down and brought it in to be imaged. He doesn’t think it was infected, but the University wants independent confirmation before they will put it back online. Bob told you that the machine was just being installed; there were hardly any files on it except for his own account ‘bob’ and some student accounts ‘eric’, ‘kevin’, ‘peter’ and ‘takeda’.
Was the server compromised? If so, how? If not, what happened? What needs to happen before the system is put back into service?
Your assignment for each act is the same.
Act II: The Missing Numbers
Your cousin Jimmy down at the precinct thought he’d throw you a bone so he sent you this case. It seems like a local punk broke into a server at Yoyodyne Defense, stole a protected spreadsheet chock full of secret numbers, and got caught trying to fence it to an undercover cop via Myspace. He says he got the spreadsheet “from a friend” but the story doesn’t check out. The boys at the station seized his computer with an outstanding warrant for “Second Degree Music Piracy” but didn’t find any evidence on it, so if they’re going to get him for more than “Possession of Stolen Numbers,” they need reasonable proof that he actually did it.
Yoyodyne graciously sent a disk image of the server that had the file on it for you to examine. The only other thing they know is that the kid’s IP address at home was 207.92.30.41 at the time of the heist.
They know the file was stolen, but they need to know precisely how and whether this kid is responsible. Finally, Yoyodyne wants your professional recommendation as to what they need to do before putting the server back into production.
Your assignment for each act is the same.
Act III: The Wealthy Individual
When you got back after lunch, there was already someone in the office. You could tell from the tux, tails, and British accent that he was a butler, but before you could offer him a drink he handed you the biggest diamond-encrusted hard drive you’d ever seen. Now, it’s a fundamental truth that money attracts crooks like Martians attract germs, so you weren’t exactly surprised when he told you that his employer’s computer had recently been broken into. What was surprising was the M.O. — the crooks deleted the boss’ files to show they were serious, and then they encrypted his swiss bank account access codes and held the decryption keys ransom for 1 megabucks.
The boss needs the access codes to do business, but he doesn’t want to cave in, either. At this point, he doesn’t care about his computer, and he doesn’t particularly care how they got in (although he’ll give you some extra dough if you figure out who was responsible). He’s just hoping that you can find a way to decrypt the codes so he doesn’t have to pay those lowlifes. If you can do it, he’ll give you a cut of the 2^20 dollars… and that’ll keep you in patty melts at Norm’s for a long time.
Hint: A few of these bank codes are really hard to find. Don’t sweat it if you can’t find every one — 6 out of 8 is worth full marks — but of course you’ll get some extra credit if you collect ’em all.
Your assignment for each act is the same.
Your Assignment
Your assignment for each act is the same: investigate the computer systems and develop a recommendation for three clients based on your investigations. The clients would each like a 1-2 page “post mortem” report on their computers detailing all relevant discoveries, including:
-
whether you think the server was indeed compromised
if so, how? if not, what actually happened?
give a blow-by-blow account if possible — the more detail, the better!
-
whether you think the attacker accessed any sensitive information
-
your recovery of any meaningful data
-
a discussion of what should be done before returning the system to production
For example, is it good enough to delete the obvious files? Could the system be trojaned?
-
recommendations as to how they can keep this from happening again
-
an estimate on how long this assignment took you
In order to do this, you’ll be inspecting filesystem images. You’ll probably want to start by looking at the log files in /var/log on the images. See the setup section for some important lab-specific instructions. This assignment illuminates that computer forensics is sometimes “guesswork” — if there was someone who knew exactly what happened, you probably wouldn’t be there. In real life, some pieces of evidence make certain things obvious, while other pieces of evidence open or close possibilities. In the end, what is important is that your report explains what you found, and only from there does it attempt to describe what may have happened. There should be enough evidence in each exercise to make each scenario clear, but if there are things you don’t know or can’t discover, say what they are, and explain what your thoughts are.
Please note: Your report should be representative of something you would return to a client who has contracted you for this work. Be thorough and explain clearly what happened in a format suitable for delivering to a client.
What can go wrong
Undelete Early, Undelete Often! Make sure you perform undeletion as soon as you set up the loopback device — if you mount the disk and do any work on it — including reading files — you may eliminate important information! (Why?) You can always delete your disk images and rerun loadimage.sh to get “clean” versions of the files.
Pathnames are confusing! Be careful! It is tempting to type cd /var/log — but /var/log is where workbench keeps its logs — your forensic logs will probably be located at /images/sda1/var/logs — or wherever you mount them. Make sure you keep your directories straight or you might find “evidence” that DETER has infiltrated your clients’ computers!
Use Built In Search Tools! Tools like less, vim, and hexedit have searching facilities, where you can enter string searches. For filesystem searching, consider using locate or find. This could speed up your recovery process.
There Could Be Bugs! Because these scenarios are obviously manufactured, it is possible that you will encounter something that looks like a “clue” but is actually an mistake from our creation of the lab. We’ve tried to eliminate all of these, but if you think something may be a “mistake”, feel free to ask your instructor.
Good luck!
Extra Credit
For extra credit in this lab, try using the john password cracker on the /etc/shadow file for Act 3. You’ll receive extra credit for recovering user passwords. You’ll also receive extra credit if you recover all 8 missing bank keys.
Submission Instructions
Make a single file (.pdf, .doc, or .txt) containing all three memos and any relevant materials. Submit this file to your instructor.
