WFA 3/e

While I was in Atlanta recently for the DoD CyberCrime Conference, I received an email telling me that my advance copy of WFA 3/e was available...even though this is my sixth book, I still get excited/nervous/anxious.  After all, you never know how the book is going to be received.  Anyway, I arrived home last night to find a FedEx box sitting on my desk. 

However, I received an email from someone I know who was at ShmooCon...come find out, the books had been printed and several sent to ShmooCon.  So, apparently, I didn't really get an "advance copy".  

I had been informed that the book would not be available until 7 Feb, so I'll be posting the code associated with the book this week, and will provide a link off of the Books page on this blog.  I haven't been holding off on it...I have been adding some things to the distribution.  I'll let everyone know when it's up.

Revisiting "Forensic Value"

I posted some thoughts a while back on defining "forensic value"...in that post, I pondered the question of who defines the "forensic value" of an artifact or finding.  The post had received 15 comments relatively quickly, and it seems that there's something of a consensus that the forensic value of data is in the eyes of analyst.  One would suppose that this means, then, that the forensic value of a particular artifact can be determined by viewing that artifact through the lens of the analyst's knowledge and experience.  In my previous post, I used terms like relative and subjective value, and I think that these descriptive terms come not only from the goals of the examination, but also depend heavily on the knowledge and experience of the analyst.

I recently had the opportunity to review a paper written by someone who had done some pretty comprehensive testing and documented some interesting artifacts.  In that paper, the author mentioned certain artifacts that were available, but that these artifacts were not pertinent to the analysis being performed...the artifacts were provided for informational purposes, and might be of value to other analyses.  For the paper and the analysis being performed, I thought that this was a valid distinction to make, as it addressed the issue of why those artifacts were not discussed (how the got there, their format, etc.) further in the paper. In short, the author had made a clear distinction as to the relative value of certain artifacts.

The relative value of an artifact often has a lot to do with the context of that artifact.  Consider an email address found within an image, perhaps using something like bulk_extractor or a keyword search.  The email address may already have an intrinsic value to you, possibly as a piece of intelligence.  From that point, any additional value of that artifact can rely heavily on the context in which that artifact resides.  Was that artifact found in a file?  In a PST file?  If the email address was found in a PST file, in an email, what is the context?  The value of the email address vary greatly depending upon not only the goals of your examination, but also whether the address was found in the To:, From:, or CC: block of the email, or if it is located in the body of the email.  Depending upon the goals of your examination, the fact that the email address was found in the body of an email may be more important and have more relative value than if it were found in the To: block.

The absence of an artifact can also be of significant value, but again, that will depend heavily upon (a) the goals of the examination, and (b) the skills of the examiner.  For example, I was performing some Registry analysis a while back to determine which files a user account had been used to access on that system (goals).  I noticed immediately that RegRipper reported that the "RecentDocs key was not found."  This was a very significant finding, and not something I had expected...and my experience told me that it was something worth exploring, particularly given the goals of my exam.  I quickly determined that a "scrubbing" tool had been applied to the system, and determined when that tool had been installed and run, and by which user.  I was also able to recover a significant bit of deleted data from within the hive file itself.

Now for the big question...so what?  How does this apply to...well...anything?  Well, consider my recent post on Timeline Analysis...for those analysts who want to "see everything", how much of that "everything" is actually relevant and of forensic value?

In order to address that, I think that we need to look at a couple of things...and I'd start with, what are the goals of your exam?

I've heard some folks say that during analysis, it's important to understand an attacker's methods, as well as their intentions.  I'm not so sure that's something I'd hang my hat on...mostly because the attacker isn't sitting next to me so that I can ask them questions and understand their intentions.  When performing analysis, all we see is the results of their actions...maybe only some of those results...and we often look at those results and artifacts through the lens of our own experiences in order to attempt to determine the intentions of others.  Further, when it comes to understanding the methods an attacker uses, that's an understanding that's most often developed by observing various artifacts from within the system...but if we're not familiar with the system that we're analyzing, and we're using some automated tool to pull out all of the "relevant" artifacts for us, are we observing all of the artifacts, or at least the right ones to give us a view into what the attacker is trying to do?

Consider this...given an image acquired from a system...let's say, for the sake of discussion, a Windows 7 system...how do we know that when we run a particular tool (or set of tools) against that image that we're extracting all of the relevant data that we require in order to make informed opinions regarding our findings?  When an analyst says, "I want a timeline, and I want it with everything!", how does that analyst then know that they've got everything in that timeline?

The forensic value of any particular artifact is determined by the goals of the exam, and the relevance of that artifact, taken in context with other artifacts.  The terms "relevance" and "context" will often be subjective, based on the knowledge and skill level of the examiner.

Does this mean that every analyst needs to be an expert in Windows?  No, that's not entirely practical.  What it does mean is there needs to be should be multiple levels of access to knowledge, including training, mentors and trusted advisers available to your analysts, and that these should all be part of or accessible to your analysis team.

Stuff

DFIROnline Meetup
If you're interested purely in numbers, last night's DFIROnline meetup had, at one point, 97 attendees.  It might've helped that my presentation was addressing malware, and we ended up continuing Cory Altheide's drinking game from last year's OSDFC...every time I mispronounced the word as "mall wear", everyone had to take a drink.  I have to go back and review the tape, but my presentation may have ended up being more like a Ron White concert.  ;-)

My previous blog post includes a link to the slides I used, as well as the malware detection checklist that I mentioned in my presentation. 

There's an excellent write-up at the Digital Forensic Source blog regarding last night's meetup, if you're interested, and you can also search for the "#DFIROnline" hash tag on Twitter to see what comments folks made during the meetup.  I have to say, however, that most of the comments were made online, in chat window 3...

Again, a huge thanks to Mike for setting these up and making the resources available, and thanks to everyone who takes the time out of their evening (or day, depending on where you are) to attend and engage. 

Malware IOCs - Ramnit
Here's an excellent walk-through of creating an IOC for the Ramnit malware.  If you're interested in the OpenIOCs at all, or just want to see how someone would go about creating an IOC, take a look at the post...and be sure to read the first two parts, as well.

If you were on last night's DFIROnline presentation on malware detection within an acquired image, what would the malware characteristics be for Ramnit, based on the IOC?

Timelines
If you like case studies and discussions of practical analysis techniques, take a look at Rob's post on Digital Forensic SIFTing.  Rob provides some very good walk-thrus regarding how to use log2timeline effectively on several incident types, and this is well worth a look.

Tools
A bit ago I ran across something Yogesh had written on parsing IE RecoveryStore files.  As these files are based on the OLE format, and I've recently had some experience writing parsers for files that use this format (Jump Lists, StickyNotes), I thought I'd take a crack at this file, as well.  This is still something I'd like to do...I'm hoping Yogesh will release the specifics of parsing the various streams soon.

Along those lines, John Moan recently commented on a blog post and mentioned that he's written two tools, ParseRS and RipRS.  I haven't had a case yet that involves recovering information about a user's browser activity, but the approach he's taken is very interesting, and I'm sure that John would greatly appreciate it if folks would try the tools out and provide him with some valuable feedback.  I've added the tools to my FOSS Tools page, keeping them persistent in one place.

Case Studies
Speaking of case studies, this is one of the items of interest within the community.  I've known about it for a while...in fact, I've tried to write my books to include case studies, and I also tend to look for similar approaches in other books.  Writing about a tool or technique is dry enough as it is, and the way to engage the reader (using the vehicle of the written word) is to include a case study that describes how the tool or technique was used.

On a number of forums, I see requests for case studies.  Not long ago, a thread was started in a forum that included a request that analysts post case studies; this is nothing new, I've seen it before.  What I haven't seen is those folks then posting case studies themselves.  Now, there are a number of what could be considered case studies online.  In fact, if you go to the FOSS Tools page off of my blog, and scroll down to the "Sample Images" section, you'll see links to several sample images that you can download...several of them have actual scenarios associated with them, as well as solutions.  These can serve as some pretty good case studies.

DFIROnline: Detecting Malware in an Acquired Image

The next DFIROnline meetup is on Thu, 19 Jan 2012, at 8pm EST.  Eric Huber and I will each be presenting, with my presentation being Malware Detection within an Acquired Image (the PDF for the presentation is linked below).  I thought that this would be a good presentation to give, as it seems to be fairly topical.  We'll be focusing on understanding malware and addressing malware detection within an image acquired from a Windows system.

For those attending the presentation tonight, I'm sure that Eric and Mike would appreciate questions, feedback, thoughts and comments.  During the presentation, please feel free to use the available chat windows for any interaction, and also feel free to contact folks via email during or after the presentations.

In particular, please feel free to either volunteer to give presentations, or to offer up ideas and/or requests for material to be covered in these presentations.  Who knows...there might be someone out there with some great material who simply doesn't think that anyone could possibly be interested in what they have to say...and all it takes is one or two people to send in, "...I'd really appreciate hearing more about this topic...".

Finally, a HUGE thanks to Mike for setting this up and providing the resources to make this event possible on a regular basis.

Resources
Presentation PDF for 19 Jan DFIROnline Meetup

Malware page to this blog
Malware Detection Checklist

Timeline Analysis

The DoD Cybercrime Conference is approaching, and I've been doing some thinking about my topic, Timeline Analysis.  I'll be presenting on Wed morning, starting at 8:30am...I remember Cory Altheide saying at one point that all tech conferences should start no sooner than 1pm and run no later than 3:30pm, or something like that.  Cool idea.

So, anyway...I've been thinking about some of the things that I put into pretty much all of my timeline analysis presentations.  When it comes to creating timelines, IMHO there are essentially two "camps", or approaches.  One is what I call the "kitchen sink" approach, which is basically, "Give me everything and let me do the analysis."  The other is what I call the "layered" or "overlay" approach, in which the analyst is familiar with the system being analyzed and adds successive "layers" to the timeline.  When I had a chance to chat with Chad Tilbury at PFIC 2011, he recommended a hybrid of the two approaches...get everything, and then view the data a layer at a time, using something he referred to as a "zoom" capability.  This is something I think is completely within reach...but I digress.

One of the things I've heard folks say about using the "everything" or "kitchen sink" approach is that they'd rather have everything so that they can look at it all when they're conducting analysis, because that's how we find new things.  I completely agree with that (the "finding new things" part), and I think it's a great idea.  After all, one of the core, foundational ideas behind creating timelines is that they can provide a great deal of context to the events we're seeing, and generally speaking, the more data we have, the more context there is likely to be available.  After all, a file modification can be pretty meaningless, in and of itself...but if you are able to see other events going on "nearby", you'll begin to see what events led up to and occurred immediately following the file modification.  For example, you may see that the user launched IE, began browsing the web, requested a specific page, Java was launched, a file was created, and the file in question was modified...all of which provides a great deal of context.

That leads me to this question...if you're running a tool that someone else designed and put together, and you're just pushing a button or launching a command, how do you know that the tool got everything?  How do you know that what you're looking at in the output of the tool is, in fact, everything?

The reason I prefer the layered approach is that it's predicated on (a) fully understanding the goals of your examination, and (b) understanding the system that you're analyzing.  Because you understand your goals, you know what it is you're trying to achieve.  And because you understand that system you're analyzing...Windows XP, Windows 7, etc...you also understand how various aspects of the operating system interact and are interconnected.  As such, you're able to identify where there may be additional data, and either request or create your own tools for extracting the data that you need.  Yes, this approach is more manually-intensive than a more automated approach, but it does have it's positive points.  For one, you'll know exactly what should be in the timeline, because you added it.

Alternatively, most often when talking to analysts about collecting data, the sense I get is that the general feeling is to "GET ALL THE THINGS!!" and then begin digging through the volumes of data to perform "analysis".  I had a case a while back that involved SQL injection, and I created a timeline using only the file system metadata and the SQL injection statements from the web server logs; adding everything else available (including user profile data) would have simply made the timeline too cumbersome and too confusing to effectively analyze.  I understood the goals of my exam (i.e., determine what the bad guy did and/or was able to access), and I understood the system (in this case, how SQL injection works, particularly when the database and web server are on the same system).

Now, some folks are going to say, "hey, but what if you missed something?"  To that I say...well, how would you know?  Or, what if you had the data available because you grabbed everything, and because you had no real knowledge of how the system acted, you had no idea that the event(s) you were looking at were important?

Something else to consider is this...what does it tell us when artifacts that we expect to see are not present?  Or...


The absence of an artifact where you would expect to find one is itself an artifact.

Sound familiar?  An example of this would be creating a timeline from an image acquired from a Windows system, and not seeing any indication of Prefetch file metadata in the timeline.  A closer look might reveal that there are no files ending in .pf in the timeline.  So...what does that tell you?  I'll leave that one to the reader...

My point is that while there are (as I see it) two approaches to creating timelines, I'm not saying that one is better than the other...I'm not advocating one approach over another.  I know from experience that there a lot of analysts who are not comfortable operating in the command line (the "dark place"), and as such, might not create a timeline to begin with, and in particular not one that is pretty command-line-intensive.  I also know that there are a good number of folks who use log2timeline pretty regularly, but don't necessarily understand the complete set of data that it collects, or how it goes about doing so.

What I am saying is that, from my perspective, each has it's own strengths and weaknesses, and it's up to the analyst how they want to approach creating timelines.  You may not want to use a manually-intensive approach (which you can easily automate using batch files, a la Corey Harrell's approach), but if you end up using a substantive framework, how do you know you're getting everything?

Uncertainty

Not too long ago, I blogged with a view of how you can contribute to the DFIR community, and this post seems to have sparked some discussion, leading to posts from other bloggers.  I saw via Twitter this morning that Christa Miller had posted her review of the Jonathan Fields book, Uncertainty.  Unfortunately, Twitter is poor medium for commenting (although many seem to prefer it) as 140 characters simply is not enough space to offer comments, input or feedback on something.  Far too often, I think, for many forensicators it comes down to tweeting or nothing.  When that happens, I honestly believe the something is lost, and the community is less for it.  As such, I opted to post the thoughts that Christa's review percolated here on my own blog.

I won't rehash Christa's review here...there's really no point in doing that.  Christa is an excellent writer, and the only way to do her review and writing justice is to recommend that you go read what she's written, and draw your own opinions.

Two sentences in particular within Christa's review really caught my attention:

A forensicator’s fear of looking stupid or failing is not, on its face, all that irrational. Who wouldn’t worry about how one’s employer or a courtroom will react to the disclosure that you don’t have all the answers?

What I thought was interesting about this was not so much whether this fear is irrational or not; rather, what caught my attention was the "one's employer or a courtroom".  I'm sure that a lot of analysts are faced with this very situation or feeling, and as such, I wouldn't discount as being irrational at all.  Now, I'm not saying that Christa's review did this...rather, I'm simply saying that as a community, this is a place where a number of analysts find themselves.

When I was in graduate school, I was surrounded by other students, a few of whom were PhD candidates.  There were a great number of PhD academic professors, of course, and perhaps one of the most powerful things I learned in my 2 1/2 years at NPS was something one of my instructors shared with me.  He had been an enlisted Marine, switched over to "the dark side" to become an officer, and was a Major by the time he left the Marine Corps to pursue his PhD.  In short, he told me that if I was struggling with a 6th order differential equation, after no more than 15 minutes of not making any headway, ask for help.

That's right.  Admit that you need help, assistance, a gentle nudge...hey, we all find at times that we've worked ourselves into a tight corner by going down a rabbit hole, particularly the wrong one.  Why keep doing it, if all you really need is a little help?

So, I found myself thinking about that statement years later when I would be going over another analyst's case notes and report, and I'd see "Registry Analysis - 16 hrs" and nothing else.  No "this is what I was looking for" and no "this is what I found."  Why was that?  Why would a consultant consume 8 or 16 hrs doing something that they had no idea of and had no discernible results, and then charge a customer for that time?  Particularly when someone who could provide assistance was a phone call or a cubicle away?

Whenever I've encountered a situation where I'm not familiar with something, I tend to reach out for some assistance.  While I was on the ISS ERS team, I was tasked with a Saturday morning response to address a FreeBSD firewall in a server room in another state.  Now, I have some familiarity with Linux, but hey, this is a firewall...so I asked the engagement manager to see about lining someone up with whom I could speak once I got on-site, got situated and got an idea of what was going on.  After all, I'm not an expert on much of anything, in particular FreeBSD firewalls.

Having worked with teams of analysts over the years, I've seen this "fear of failure" issue several times.  Each time, I see two sides to the issue...on one hand, you have the analyst who's afraid to even ask a question, because (as I've been told) they're afraid of "looking stupid" to their peers and boss.  So what happens is that instead of asking for help, they turn in a report that's incomplete, full of glaring holes in the analysis and conclusions, and essentially blank case notes.  That gig to analyze one image that was spec'd out at 48 hrs now takes 72 or even 96 (or more) hours to complete between multiple analysts, and while the customer ultimately gets a half-way decent deliverable, your team has lost money on the engagement.  On top of that, there's now some ill-will on the team...because one analyst didn't want to ask for help, now another analyst has to drop everything (including their family time after 5pm) to work late, in emergency mode.

On the other hand, there's the analyst who does ask questions, does ask for assistance, and in the process learns something that they can then carry forward on future engagements.  The customer receives a comprehensive report in a timely manner, and the analyst is able to meet their revenue numbers, allowing them the time to take a vacation or "mental health day", and receive a bonus.

My point is this...there's not one of us that knows everything, and regardless of what your individual perception may be, no one expects you to know everything.  If you have a passion for what you do, you learn when you ask questions and engage with others, you incorporate that new information into what you do, and you grow from it.  If you're worried about people thinking you'll "look stupid", an option would be to pursue a trusted adviser relationship with someone with whom you feel comfortable asking questions.

If you're concerned with someone seeing you ask a question publicly (potential employer, defense counsel), then find someone you can ask questions of "off the grid". 

Ultimately, as I see it, the question becomes, do you continue into the future not knowing something, or do you ask someone and at the least get a leg up on fully discovering the answer?  Would you rather look like you don't know something for a moment (as you ask the question) and then have an answer (or at least a pathway to it), or would your preference be to not know something at all, and have it discovered later, after the issue has grown?

My recommendation with respect to the two sentences from Christa's review is this...if you find yourself in a situation where you are telling yourself, "I don't want people to think I'm dumb", consider what happens if you don't ask that question.  Are you going to run over hours on your analysis, and ultimately provide a poor product to your customer?  Are you missing data that would lead to the conviction or exoneration of someone who's been accused of a crime?  Or, can you take a moment to frame your question, provide some meaningful background data ("I'm looking at a Windows XP system"), maybe do some online searches, and ask it...even if that means you're reaching out to someone you know rather than posting to a public forum? 

Stuff

Using RegRipper
Russ McRee let me know recently that the folks at Passmark recently posted a tutorial on how to use their OSForensics tool with RegRipper.

Speaking of RegRipper, I was contacted not long ago about setting up a German mirror for RegRipper...while it doesn't appear to active yet, the domain has been set aside, and I'm told that the guys organizing it are going to use it not only as a mirror, but also as a site for some of the plugins they'll be getting in that are specific to what they've been doing.

If you're into GenToo Linux, there's also this site from Stefan Reimer which contains a RegRipper ebuild for that platform.

Updated tool:  Stefan over on the Win4n6 Yahoo group tried out the Jump List parser code and found out that, once again, I'd reversed two of the time stamps embedded in the LNK file parsing code.  I updated the code and reposted the archive.  Thanks!

Meetups
With respect to the NoVA Forensics Meetups, I posted here asking what folks thought about moving them to the DFIROnline meetups, and I tweeted something similar.  Thus far, I have yet to receive a response from the blog post, and of the responses I've seen on Twitter, the vast majority (2 or 3..I've only seen like 4 responses...) indicate that moving to the online format is just fine.  I did receive one response from someone who seems to like the IRL format...although that person also admitted that they haven't actually been to a meetup yet.

So...it looks like for 2012, we'll be moving to the online format.  Looking at the lineup thus far, we already seem to be getting some good presentations coming along in the near future.

Speaking of which, offering to either give a presentation or asking for some specific content to be presented on is a great way to contribute to the community.  Just something to keep in mind...if you're going to say, "...I'd like to hear about this topic", be prepared to engage in a discussion.  This isn't to say that someone's going to come after you and try to belittle your idea...not at all.  Instead, someone willing to present on the topic may need more information about your respective, what you've tried (if anything), any research that you've already done, etc.  So...please be willing to share ideas of what you'd like to see presented, but keep in mind that, "...what do you mean by that?" is NOT a slam.

New Tools
File this one under "oh, cr*p..."...

Seems setmace.exe has been released...if you haven't seen this yet, it apparently overcomes some of the issues with timestomp.exe; in particular, it is reportedly capable of modifying the time stamps in both the $STANDARD_INFORMATION and the $FILE_NAME attributes within the MFT.  However, it does so by creating a randomly-named subdirectory within the same volume, copying the file into the new directory, and then copying it back (Note: the description on the web page uses "copy" and "move" interchangeably).

Okay, so what does this mean to a forensic analyst, if something like this is used maliciously?  I'm going to leave that one to the community...

The folks at SimpleCarver have released a new tool to extract contents from the CurrentDatabase_327.wmdb file, a database associated with the Windows 7 Windows Media Player.   If you're working an exam that involves the use of WMP (i.e., you've seen the use of the application via the Registry and/or Jump Lists...), then you may want to consider taking a look at this tool.

You might also want to check out some of their other free tools.

Melissa posted to her blog regarding a couple of interesting tools for pulling information from memory dumps; specifically, pdgmail and Skypeex.  Both tools apparently require that you run strings first, but that shouldn't be a problem...the cost-benefit analysis seems to indicate that it's well worth running another command line tool.  An alternative to running these tools against a memory dump would be using Volatility or the MoonSols Windows Memory Toolkit to convert a hibernation file to a  raw dump format, and then run these tools.

Speaking of tools, Mike posted a list of non-forensics tools that he uses on Windows systems to his WriteBlocked blog.  This is a very good list, with a lot of useful tools (as well as tools I've used) on that list.  I recently used Wireshark to validate some network traffic...another tool that you might consider using alongside Wireshark is NetworkMiner...it's described as an NFAT tool, so I can see why it's not on Mike's list.  I use VirtualBox...I have a copy of the developer's build of Windows 8 running in it.

Wiping Utilities
Claus is back, and this time has a nice list of wiping utilities.  As forensic analysts, many times we have to sanitize the media that we're using, so having access to these tools is a very good thing.  I've always enjoyed Claus's posts, as well, and hope to see him posting more and more often in 2012.

Can anyone provide a technical reason why wiping with 7 passes (or more) is "better" than wiping with just 1 pass?

File Formats
I was reading over Yogesh Khatri's posts over at SwiftForensics.com, and found this post on IE RecoveryStore files.  Most analysts who have done any work with browser forensics are aware of the value of files that allow the browser to recover previous sessions...these resources can hold a good deal of potentially valuable data.

About halfway down the post, Yogesh states:

All files are in the Microsoft OLE structured storage container format.

That's awesome...he's identified the format, which means that we can now parse these files.  Yogesh mentions free tools, and one of the ones I like to use to view the contents of OLE files is MiTeC's SSV, as it not only allows me to view the file format and streams, but I can also extract streams for further analysis. 

Another reason I think that this is cool is that I recently released the code I wrote to parse Windows 7 Jump Lists (I previously released code to parse Win7 Sticky Notes), and the RecoveryStore files follow a similar basic format.  Also, Yogesh mentions that there are GUIDs within the file that include 60-bit UUID v1 time stamps...cool.  The Jump List parser code package includes LNK.pm, which includes some Perl code that I put together to parse these artifacts! 

I don't have, nor do I have access to at this time, any RecoveryStore files to work with (with respect to writing a parser)...however, over time, I'm sure that the value of these artifacts will reach a point such that someone writes, or someone contributes to writing, a parser for these files.