|"Tales From the Trenches"|
Of course, I'd like to think that this was because of my impeccable story telling. Just look at some of the titles: "The Eager Attorney and the Hard Drive of Doom"; "The Search Term That Wouldn't Cull"; and, my favorite, "The Ineluctable Modality of the PDF". But once I finished fantasizing about adding "Master Storyteller" to my list of accomplishments, I had to acknowledge that there was probably more to it than my wordsmithing. Whatever you call them - war stories, case studies, investigation experiences - there is a lot of value to learning problems others have faced, and how those problems were dealt with.
Harlan Carvey (without whom I would likely never have new ideas for my blog) started another interesting discussion on the Win4n6 forums this week about sharing case studies within the field. I'll be the first to admit my reluctance in the past about inadvertantly disclosing sensitive material, but when I really thought about it, I feel that there are definitely ways to contribute without crossing, or even getting close, to that line. Corey Harrell coined the phrase "Case Experience" to differentiate these shorter, more sanitized communications from "Case Studies", which implies a more complete picture. Yes, I can share case experiences without guilt, and hopefully, I'll even pass on something. It may even be insight. Or knowledge. Or something good. No antibiotics needed.
And so, without further ado, I present GU's Case Experience #1.
Working Title: The Difference a Minute Makes
Standard disclosure: This represents a targeted investigation, and not all portions of the exam will be discussed. Please don't take this as SOP. Also, my set of tools has been evolving, but steps I mention should be able to be performed with a variety of different tools.
Possible data spoliation. The client requested an investigation that looked into data deletion on a Windows XP system within a specific time frame. The system in question had been in use for a couple months after the time of interest. The end result was a report that detailed recovered files of interest and a timeline of events.
Recycle bin analysis
File recovery using EnCase
File carving using PhotoRec
Analysis of carved files on system for context
Search for data deletion software
Registry and restore point analysis
The scene: Me smoking a cigar in a shadowy room with my feet on the desk, looking debonair. While recovering the deleted files was of great interest to the client, what makes this case stand out to me is what I found on the system regarding a program called CCleaner. Many of you are likely familiar with it, and have come across it in your cases (in fact, Cheeky4n6Monkey has some great posts about pulling artifacts relating to CCleaner using a RegRipper plugin) It seems to crop up an awful lot in certain types of cases. What made this one interesting was the reconstruction of events found in restore point registry hives. Luckily for me, though the computer had been in use for quite a while after the timeframe of interest, the restore points for the timeframe were still present.
I could see that the registry entries showed CCleaner being installed on the system a couple years before the timeframe of interest. Even better, after tracking down RPs for specific dates, and determining the proper user, the keys showed that CCleaner.exe had been run on the system by the user in the "hot zone". Bingo! But wait... it wasn't quite as clear as that. You see, a good minute after CCleaner.exe was run, a CCleaner installer file called ccsetup###.exe was run, with no indications that CCleaner.exe was run again after the installation. So, was CCleaner simply updated but not run? Or could it have been run after the installer without updating the registry entry?
I had come across CCleaner enough in the past to know that the program will check for an updated version of the software and ask the user if they want to download it if one is available. So it didn't come as a surprise that an installer file would be run soon after executing the program. The question became, after running the installer, if CCleaner was run what changes, or lack of changes, would occur in the registry?
It was time to stop speculating, and start researching. I used a Windows XP machine that had CCleaner already installed. Upon firing up the program, I was indeed prompted to update the software. Following the update, I used the default option to start CCleaner automatically, and then ran the default CCleaner process on the system. Following the run, I examined the test registry hives to see what sort of information was present. The test system registry hives mimicked the investigated system: though CCleaner had been run following the updated installer file, the registry just reflected the initial execution of the program.
Moral of the Story
Now, I don't expect that this is an earth-shattering revelation. I guess the real point that I want to make is the importance of testing when questions are raised or anticipated. In this case, there were questions, and I had the ability to confidently say "I tested the process and the data is consistent." There are so many variables on systems, testing should be common place. You don't need a plethora of extra equipment to do it, either. Run some virtual machines, have a few baseline setups you can use, and take the time to experiment.