Tuesday, March 8, 2011

Dereliction of Duty

Once again, I have been derelict in posting regularly to this blog. I enjoy writing and documenting the cool stuff I'm working on, but lately it seems there's been too many other things going on in life to post on a regular basis. One of these days, things will slow down and I can do more fun stuff, like testing, experimenting and blogging about it all.  Until then, it's going to be on an "as I have time" basis. I had a few things I wanted to talk about today, so away we go...

Have you ever been examining a system and found it was just too "clean?" I'm not talking about the absence of cobwebs and dust here, but rather the absence of practically any signs of use at all?

I recently examined a computer that only had user created data on it from a couple weeks earlier up until the time it was brought to me. I knew the alleged illegal use of the machine had occurred several months ago, so this made little sense. I pulled the registry files and also did a time line of the system. Using RegRipper, I took a look at the SOFTWARE hive and found the install date for the Windows 7 OS was only a couple weeks earlier. I followed up by looking at the time line, discovering the $MFT was created within a short time of the OS install date shown in the registry. Just to be extra thorough, I also extracted the $MFT and used David Kovar's excellent AnalyzeMFT python script to create a csv listing of the master file table information. All the data I was seeing was in agreement, so I knew something was up.

I immediately suspected the "factory reset" utility had been run and wondered if the purpose had been to destroy evidence. Continuing to look at the time line, it was pretty clear that the factory reset had taken place. After doing a bit more investigation, it turned out that a non-suspect user of the computer had run the reset after the suspect had acquired a virus on the machine they hadn't been able to get rid of. While the intent of the reset wasn't malicious, it did wipe out a lot of information. File carving with X-Ways Forensics and the use of the Hstex tool that comes with NetAnalysis provided a considerable amount of recovered data to the case and I was able to conclude the exam soon thereafter.

And now for something completely different.....

I wanted to mention some good stuff I've read lately that I found valuable. Harlan wrote an interesting post on MBR Infectors. I've never run into one, so it gave me some good ideas on things to check for in future exams. Seems like I'm running into more and more malware situations lately, which I enjoy, so I'm always glad to read things like this.

I also read a tweet this morning that mentioned Cuckoo, a malware analyzer sandbox. I haven't had the opportunity to try it out yet, but from reading over the website, it looks like it could prove useful. I'll post further after I've had time to dive into it (sometime next century, possibly, with my life ;-) ) From the project website, here is a list of it's capabilities:

• Retrieve files from remote URLs and analyze them.
• Trace relevant API calls for behavioral analysis.
• Recursively monitor newly spawned processes.
• Dump generated network traffic.
• Run concurrent analysis on multiple machines.
• Support custom analysis package based on AutoIt3 scripting.
• Intercept downloaded and deleted files.
• Take screenshots during runtime.


I can definitely use this if it does all that. I am looking very forward to giving it a look.

2 comments:

  1. "Continuing to look at the time line, it was pretty clear that the factory reset had taken place."

    How so? What does this "look like"?

    ReplyDelete
  2. Hi Harlan...In this case, there were many many system and OEM folders and files with "born on" and access times/dates all beginning at about the same time and that continued throughout the time line for quite a while. That included the point where the $MFT and $MFTmirror were created (or born) along with other NTFS specific files.

    ReplyDelete