Links and Updates

iTunes Forensic Analysis
I ran across a very interesting read regarding the forensic analysis of an iTunes installation via DFINews.  One of the things I see consistently within the community is that folks really want to see how someone else has done something, how they've gone about conducting an exam or investigation, and this is a good example of that.

Volatility Updates
Keep your eye on the Volatility site for updates that include support for Windows 8, thanks to the efforts of @iMHLv2, @gleeda, @moyix, and @attrc.

Speaking of Volatility, the folks at p4r4ni0d take a look at Morto.  Great work, using a great tool set.  If you want to see how others using Volatility, take a look at the blog post.

NetworkMiner
A new version of NetworkMiner has been released.  If your work involves pcap capture and analysis, this is one tool that I'd definitely recommend that you have in your kit.

Registry
Andrew Case (@attrc) put together a very good paper (blog post here) on how he went about recovering and analyzing deleted Registry hives.  Now, this is not recovering deleted keys from within hive files...Andrew recovered entire hive files from unallocated space after (per his paper) the system had been formatted and the operating system reinstalled.  Take a look at the process he went through to this...this may be something that you'd want to incorporate into your tool kit.

If you're read Windows Registry Forensics, you'll understand Andrew's approach; Registry hive files (including those from Windows 8) start with 'regf' at the first 4 bytes of the file.  The hive files are broken into 4k (4096 bytes) pages, with the first one beginning with 'regf'; the subsequent pages start with 'hbin'.  

I've done something similar with respect to Windows XP Event Logs, carving specifically for individual records rather than entire Event Log (.evt) files.  In much the same way, Andrew looked that goals of his examination, and then used the tools he had available to accomplish those goals.  Notice that in the paper, he didn't discuss re-assembling every possible hive file, but instead only those that might contain the data/information of interest to his examination.  Nor did he attempt to carve every possible file type using scalpel; he only went after the types of files that he thought were necessary.

When I wrote my event record carving tool, I had the benefit of knowing that each record contains the record size as part of its metadata; Andrew opted to grab 25MB of contiguous data from the identified offset, and from his paper, he appears to have been successful. 

Also, page 4 includes a statement that is extremely important; "This is necessary as USBSTOR keys timestamps are not always reliable."  As you're reading through the paper, you'll notice that Andrew focused on the USBStor keys in order to identify the devices he was looking for, but as you'll note from other sources (WRF, as well as Rob Lee's documentation), the time stamps on the USBStor keys are NOT a reliable indicator of when a USB device was last connected to (or inserted into) a system.  This is extremely important, and I believe very often confused.

More importantly, I think that Andrew deserves a great big "thanks" for posting his process so clearly and concisely.  This isn't something that we see in the DFIR community very often...I can only think of a few folks who do this work who've stepped up to share this sort of information.  Clearly, this is a huge benefit to the community, as I would think that there will be folks reading his paper who will think to themselves, "wow, I could've used that on that examination!", just as others will likely be using it before 2011 closes out.  Notice that there's nothing in the write-up that specifically identifies a customer or really gives away any case-specific data.

Andrew's paper is an excellent contribution to the community, and provides an excellent look at a thorough process for approaching and solving a problem using what you, as an examiner, have available to you.  Something else to consider would be to look for remnants of the (for Windows XP) setupapi.log file, which would provide an indication of devices that had been connected (plugged in, attached, inserted into) to the system.  I've done something similar with both the pagefile and unallocated space...knowing what I was looking for, I used Perl to locate indications of the specific artifacts, and then grab X number of bytes on either side of that artifact.  As an example, you could use the following entry from a setupapi.log file:

#I121 Device install of

Now, search for all instances of the above string, and then grab 200 or more bytes on either side of that offset and write it to a file.  This could provide some very useful information, as well.

Timelines
Corey has an excellent post up regarding the thought processes behind putting a timeline together.  I'd posted recently on how to go about creating mini-timelines from a subset of data; in his post, Corey discusses the thought process that he goes through when creating timelines, in general...he also provides an example.  If you look at the "Things to consider" section of his post, you'll notice some similarity to stuff I've written, as well as to Chris Pogue's Sniper Forensics presentations; in particular, the focus on the goals of the examination.

In his post, Corey mentions two approaches to timelines; the "kitchen sink" (including everything you can, and then performing analysis) and the "minimalist" approach.  From my perspective, the minimalist approach is very similar to what Corey describes in his post; you can add data sources to a timeline via a "layering" approach, in that you can start with specific data sets (file system metadata, Event Logs, Prefetch file metadata, Registry metadata, Jump Lists, etc.), and then as you begin to develop a more solid picture, add successive layers, or even just specific items, to your timeline.  The modular approach to the tools I use and have made available makes this approach (as well as creating mini-timelines) extremely easy.  For example, during an examination involving a SQL injection attack, I put together a timeline using just file system metadata and pertinent web server log entries.  For an incident involving user activity on a system, I would create a timeline using file system metadata, Registry key LastWrite times (as well as specific entries, such as UserAssist data), Event Log entries, Prefetch file metadata, and if the involved system were Windows 7, Jump List metadata (including parsing the DestList stream and sorting the entries in MFU/MRU order).  In a malware detection case, I may not initially be interested in the contents of any user's web surfing activity, with the exception of the LocalService or "Default User" user accounts.

This is not to say that one way is better or more correct than another; rather, the approach used really depends upon the needs of the examination, skill set of the analyst, etc.  I've simply found, through my own experience, that adding everything available to a timeline and then sorting things out doesn't provide me with the level of data reduction I'm looking for, whereas a more targeted approach allows me to keep focused on the goals of the examination.

Links...and whatnot

How'd you do that??
One thing I've found to be very true about the community is that folks love to see how other analysts have done things.  This is very helpful to know when it comes to writing articles or giving presentations.

Frank Boldewin recently posted CSI:Internet Episode 3: A trip into RAM, which provides an excellent walk-through on how he collected the contents of physical memory from a live Windows system, and then used Volatility (including the malfind, volshell, apihooks plugins) to locate malware.  Frank's article is well worth a look, as it is an excellent read.

Advice
Need advice or input on getting started in DFIR work?  Corey recently posted links to various articles and posts (including my own), and provided some considerable (and excellent) advice of his own.  Even if you're already in the field, this is an excellent source of advice.

HowTos
I posted a quick-and-dirty blog post recently on how to create mini-timelines, and received a comment asking for more of these types of posts.  I've considered writing "HowTo" posts in the past, but quickly found myself running short on topics.  I'm considering posting more of these, but like I said...I'm kind of running short of topics.

Windows 8
I recently installed the available developer build of Windows 8 into VirtualBox (running on 64-bit Windows 7) using these instructions.  So far, so good.  During the setup, I opted to use the .vhd disk format (rather than the VirtualBox .vdi, or .vmdk) so that I could later add the .vhd file to a Windows system to see what things look like.  I installed the OS, poked around a bit, and then shut the VM down and opened the .vhd file in FTK Imager.  The Registry hives that I looked at (NTUSER.DAT) appear to follow the same format as previous versions; as Windows 8 is running in a VM, I won't be able to see things like wireless connectivity, etc.  It also appears that Windows 8 uses Jump Lists (good thing I wrote that code to parse those bad boys, eh?); I'll definitely have to take a closer look at them, that's for sure.  Looking at the Jump List files in the FTK Imager hex view, I see the file signature for the OLE/compound document binary format file, as well as the "Root Entry" and "DestList" stream names.

From the TwitterVerse, it seems that I'm not the only one moving along these lines...moyix has taken the first steps toward adding Win8 support to Volatility (see it working here).

APT
I know, I know...no one wants to hear about the "Advanced Persistent Treat" anymore.  However, it appears that there was an APT Summit in DC this past summer, and RSA recently published an overview document of the findings from the summit.  The PDF doc is 3 pages long, and pretty interesting read.

Windows Post-Exploitation
Thanks to Chad Tilbury, I was directed to this page (at pentestmonkey.net) which discusses various means of getting from Local Admin to Domain Admin once a system has been compromised.  Looking for artifacts of these approaches can provide indications of what the intruder may have been up to.

Updates and Links

NoVA Forensic Meetup
The most recent NoVA Forensics Meetup was a great time! Mitch Harris gave a great "Botnets 101" presentation and opened the door for 201.  Mitch described botnets and their command-and-control (C2) structures, and is leaving mitigation techniques for his follow-on presentation.  A huge thanks to Mitch for presenting, and everyone for showing up, especially those who came by because they were in the area.  We're looking forward to having Mitch come back for that follow-on presentation in the future.

BIOS Malware
Speaking of Mitch's presentation, he also mentioned malware that infects systems by writing to the BIOS.  Oddly enough, I ran across Mebromi this morning, which Norman describes as a "BIOS-flashing Trojan". 

An excellent point brought up in the writeup is also something that we discussed during the meetup; that is that the reason why we're not all infected with malware that writes to the BIOS (or to the GPU on our graphics card, etc.) is that this sort of malware is "hard to do", because it's very hardware-specific.  In fact, the writeup also indicates that the Trojan attempts to modify Award BIOS's only.  Mebromi also apparently infects the MBR, as well.

Here is Symantec's writeup on Mebromi.

VirusTotal
Okay, this is the last thing I'm going to say about malware in this post...seriously.  I ran across this ComputerWorld article this morning, which mentioned that the same spearphish attack code used against RSA had also been used against other organizations; in fact, the first sample of that code had actually been submitted on 4 March, whereas (according to the article) it wasn't until 19 March that a sample was submitted from someone at EMC (the company that owns RSA). 

Folks, what this tells us is that those tools that we use to quickly gather intelligence about stuff we find on our systems can then be used against us.  In spearphishing attacks, you can be sure that the attackers know exactly to whom the emails were sent...that's sort of the nature and definition of a spearphishing attack, and is also why we don't simply call it "random-spray-and-pray".  Remember, "public" websites are usually exactly that...public.  And available to everyone.  This is why you might want to develop an organic, in-house malware analysis capability.

Also, there was apparently some metadata analysis of the actual spreadsheets that had been submitted, as well...take a look at the article and see if you agree with what was said about that...

Jump Lists
The new 4n6k blog has a post up that extends Jump List Analysis by adding a whole bunch of AppIDs.  I posted recently regarding using timeline analysis to fill in the gaps in analysis when you're either attempting to determine the app associated with an unknown AppID, or if the user had deleted the application itself prior to the acquisition of the system. 

Community
One of the comments to the blog post that I mentioned above was along the lines of, hey, locating indications of apps being run has been discussed before...my thought along those lines is, okay, but do we do it enough?  Seriously.  How often do we really share analysis techniques, or findings?   Something may have been discussed before...but where, and with whom?

What would have happened within the community if no one took USB device analysis any further after the first research was published?  What if Rob Lee had never decided to take what was published a step or two further?  What if the first iterations of the Volatility Framework had never been developed?

It's important that we discuss these things, and keep discussing them.  The problem that we face as a community is that nothing about what we do is static; everything's changing all the time.  Discussing analysis techniques and findings allows us to not only engage other analysts who may not have seen what we've seen (or didn't know that they did), but it also allows us to metaphorically go beyond the next ridge and see if the world really is flat.

ProDiscover
ProDiscover recently turned 7...that's right, version 7 was released, adding MacOSX support (HFS+ file system, DMG images), EVTX Event Log format support, and there's a Fedora Linux live boot disk, as well.  Chris Brown has graciously provided me with a license for ProDiscover IR since version 3, so I've seen this application go through a lot of growth, as Perl ProScripting support was added, as well as support for parsing PST/OST files.  Just prior to version 7, Chris added support for parsing Windows 7 Jump Lists, making PD the first commercial forensic analysis application (that I'm aware of) to support parsing this artifact.  ProDiscover was also the first commercial app to include native parsing of VSCs...right clicking on the partition within the app gives you a list of VSCs to choose from, and the ones you selected would appear as volumes/drive letters right there in the app UI.

Timelines
Corey's got a great post up called "What's a Timeline", which is a very good post that helps explain what a timeline is, or should be.  It doesn't matter whether you're new to timelines or not, it's worth a look.

ESEDB Format
BugBear posted recently regarding using Joachim Metz's libesedb project tools to parse data from the Windows Desktop Search database, based on the Extensible Storage Engine (or 'ESE').  Joachim also wrote a paper that documents the format of the database.  While Joachim's tools are Linux-based, Mark Woan provides his EseDbViewer for Windows systems.

From reading the materials available, it would appear that the ESE DB format, particularly for the Windows Desktop Search, may provide some very interesting forensic artifacts.  It would be good to hear if any analysts out there are already using information from within the ESE database in their examinations.

If you're interested in developing your own code, iiobo has an ESE library and toolkit (C++/C#) available.

Updates and Links

Report Writing
One of the hardest parts of what we do is writing reports; technical people hate to write.  I've seen this fact demonstrated time and again over the years.

Paul Bobby wrote up a very interesting blog post about criteria for an effective report.  As I read through it, I found myself agreeing, and by the time I got to the end of the post, I noticed that there were some things that I see in a lot of reports that had not been mentioned...for example,

One section of the post that caught my eye was the Withstand a barrage of employee objections section...I think that this can be applied to a number of other examinations.  For example, CP cases will sometimes result in "Trojan Defense" or remote access claims (I've seen both).  Adding the appropriate checklists (and training) to your investigative process can make answering these questions before they're asked an easy-to-complete task.

At the end of the post, Paul mentions adding opinions and recommendations; I don't really so much have an issue with this, per se, as long as the opinions are based on and supported by clearly documented analysis and findings, and clearly and concisely described in the report.  In many of the reports I've reviewed over the years, the more prolific the author attempts to be, the less clear the report becomes.  Also, invariably, the report becomes more difficult of the author to write.

CyberSpeak Podcast
Ovie's posted another CyberSpeak podcast, this one with an interview of Chris Pogue, author of the "Sniper Forensics" presentations.  Chris talks about the components of "Sniper Forensics", including Locard's Exchange and the Alexiou Principles.

Another thing that Chris talks about is Occam's Razor...specifically, Chris (who loves bread pudding, particularly a serving the size of your head...) described a situtation that we're all familiar with, in that an analyst will find one data point, and then jump to a conclusion as to the meaning of that data point, not realizing that the conclusion is supported by that one data point and a whole bunch of assumptions.  When I find something that is critical to addressing the primary goal of my examination, I tend to look for other supporting artifacts to provide context, as well as a stronger relative level of confidence, to the data I'm looking at, so that I can get a better understanding of what is actually happening.

At  the beginning of the podcast, Ovie addresses having someone review your analysis report before heading off to court, sort of a peer review thing.  Ovie said that Keith's mention (in a previous podcast) of this review probably referenced folks in your office, but this sort of thing can also include trusted outside analysts.  Ovie mentioned that you have to be careful about this, in case the analyst then goes about talking/blogging about their input to your case.  I agree that this could be an issue, but I would also suggest that if the analyst were trusted, then you could trust them not to say anything.

One thing to remember from the podcast is that there is no such thing as a court-approved tool...the term is simply marketing hype.

Finally, Chris...HUGE thanks for the RegRipper (and ripXP) shout-out!  And a HUGE thanks to Ovie and the CyberSpeak team for putting together such a great resource to the community.

Morto
I recently blogged regarding Jump Lists, and in that post had indicated what artifacts are available when the user uses the Remote Desktop Client to connect to other systems via RDP.  Another thought as to how this might be useful came with F-Secure's announcement of a worm called Morto, which appears to use RDP to spread.  How Jump Lists might come into play is if RDP connections are observed between systems (or in the logs of the system being accessed); an investigation might show no Jump Lists associated with the Remote Desktop Client for the primary user on that system.  This goes back to what I was referring to earlier in this post...let's say you see repeated RDP connections between systems, and go to the system from which they originated.  Do you assume that the connections were the result of malware or the user?  Examining the system will provide you with the necessary supporting information, giving you that context.

Mentions of Morto can also be found at Rapid7,  as well as MMPC.


NoVA Forensics Meetup Reminder
The next NoVA Forensics Meetup is set for 7 Sept.  We're scheduled to have a presentation on botnets from Mitch Harris...I'm really looking forward to it!

Tools
I posted recently regarding StickyNotes analysis, and also recently completed my own StickyNotes parser.  It works very well, and I've written it so that the output is available in a listing, CSV, and TLN formats.  Not only does it print out information about the embedded notes within the StickyNotes.snt file but it also provides the modification date/time for the "Root Entry" of the .snt file itself.  This would be useful if the user had deleted all of the sticky notes as it would provide an indication of user activity on the system (i.e., the user would have to be logged in to delete the sticky notes).  In order to write this tool, I followed the MS OLE/Compound Document binary format spec, and wrote my own module to parse the Sticky Notes.  As I didn't use any proprietary modules (only used the Perl seek(), read(), and unpack() functions) the tool should be cross-platform.

Anyway, the tool parses out the notes out of the .snt file, and presents information such as the creation and modification dates, and the contents of the text stream (not the RTF stream) of the note.  It also displays the modification date for the Root Entry of the OLE document, as well...

C:\Perl\sticky>sn.pl -f stickynotes.snt
Root Entry
  Mod Date     : Fri Aug 26 11:51:35 2011

Note: a4aed27b-cfd9-11e0-8
  Creation Date: Fri Aug 26 11:51:35 2011
  Mod Date     : Fri Aug 26 11:51:35 2011
  Text: Yet another test note||1. Testing is important!

Note: e3a17883-cfd8-11e0-8
  Creation Date: Fri Aug 26 11:46:18 2011
  Mod Date     : Fri Aug 26 11:46:18 2011
  Text: This is a test note

I also have CSV and TLN (shown below) output formats:

C:\Perl\sticky>sn.pl -f stickynotes2.snt -t
1314359573|StickyNote|||M... stickynotes2.snt Root Entry modified

In the above example, all of the notes had been deleted from the .snt file, so the only information that was retrieved was the modification date of Root Entry of the document.

Addendum: I've posted the Windows binary of the Sticky Notes parsing tool to my Google Code site.  Note that all times are displayed in UTC format.

More Updates

Scanning Hosts
There's a great post over on the SANS ISC blog regarding how to find unwanted files on workstations...if you're a sysadmin for an organization and have any responsibilities regarding IR, this is a post you should really take a look at.

As a responder, one of the things I've run across is that we'd find something on a system that appeared to be a pretty solid indicator of compromise (IoC) or infection.  Sometimes this is a file, directory name, or even a Registry key or value.  This indicator may be something that we could use to sweep across the entire enterprise in order to look for it on other systems...and very often the question becomes, is there a tool that I can use to scan my infrastructure for other compromised/infected systems?  Well, there is...it's called a "batch file".

Forensics
One of the things most of us are aware of as analysts is that in many cases, deleted stuff really isn't; files, Registry keys, etc., get deleted but are often recoverable if you know what you're looking for.  Well, here's a great example of that was used recently. 

CyberSpeak Podcast
I was listening to Ovie's latest CyberSpeak podcast, and very early on in the show, Ovie read a listener email from a LEO who does forensics as a collateral duty.  Now, this is really nothing new...I've met a number of LEOs for whom forensics is an additional duty.  Also, for a lot of LEOs, digital forensics isn't the primary task of the job, even if it is the primary assignment, as LEOs need to remain qualified as LEOs in order to get promoted, and they very often do.  This means that someone will come into the digital forensics field as a seasoned investigator, and several years later move out to another aspect of the law enforcement field. 

I had an opportunity to sit down with some LEOs a couple of weeks ago, and one of the things we came up with as a resource is the LEO's rolodex; if you run into something that you have a question or thought on, call someone you know and trust that may have detailed knowledge of the subject, or knows someone who does.  No one of us knows everything, but there may be someone out there that you know who knows just a little bit more about something...they may have read one or two more articles, or they may have done one more bit of research or testing. 

Ovie also mentioned the ForensicsWiki as a resource, and I completely agree.  This is a great resource that needs to be updated by folks with knowledge and information on the topic areas, so that it will become a much more credible resource.

Also, I have to say that I disagree with Ovie's characterization that there are two different types of forensics; "intrusion forensics" and "regular forensics".  I've heard this sort of categorization before and I don't think that that's really the way it should be broken out...or that it should be broken out at all.  For example, I spoke to a LEO at the first OSDFC who informed me that "...you do intrusion and malware forensics; we do CP and fraud cases."  My response at the time was that I, and others like me, solve problems, and we just get called by folks with intrusion problems.  In addition, there's a lot of convergence in the industry, and you really can't separate the aspects of our industry out in that way.  So let's say that as a LEO, you have a CP case, and the defense counsel alludes to the "Trojan Defense"...you now have a malware aspect to your case, and you have to determine if there is a Trojan/malware on the system and if it could have been responsible for the files having been placed on the system.  Like many examiners, I've done work on CP cases, and the claim was made that someone accessed the system remotely...so now I had an intrusion component of the examination to address.

I went on and listened to Ovie's interview with Drew Fahey...great job, guys!

Time and Timelines
When I give presentations or classes on timeline analysis, one of the things I discuss (because it's important to do so) is those things that can affect time and how it's recorded and represented on a system.  One of the things I refer to is file system tunneling, which is a very interesting aspect of file systems, particularly on Windows.  In short, by default, on both FAT and NTFS systems, if you delete a file in a directory and create a new file of the same name within 15 seconds (default setting), then that new file uses the original files creation dates from both the $STANDARD_INFORMATION and $FILE_NAME attributes. 

This is just one of the things that can affect time on systems.  Grayson, a member of the Trustwave team along with Chris, recently posted to his blog regarding his MAC(b) Daddy presentation from DefCon19, and in that post, linked to this Security BrainDump blog post.

Tools
There's a "new" version of Autopsy available...v3.0.0beta.  Apparently, this one is Windows-only, according to the TSK download page.  I've been using the command line TSK tools for some time, in particular mmls, fls, and blkls...but this updated version of Autopsy brings the power of the TSK tools to the Windows platform in a bit of a more manageable manner.

Similarly, I received an email not long ago regarding a new version of OSForensics beta version 0.99f being available for testing.  I'd taken a look at this tool earlier this year...I haven't looked at this new version yet, but it does seem to have some very interesting capabilities.  There's some capability in the tool to interact with a live system, in that it appears to be able to capture and parse memory.  Also, the tool still seems to be written primarily to interact with a live system...I'll have to take another look at this latest version.

For mounting images, PassMark also makes their OSFMount tool available for free, as well.  This tool is capable of mounting a variety of image formats, which is great...generally, I look for "read-only", but OSFMount has the ability to mount some image formats "read-write", as well.

In chapter 3 of Windows Registry Forensics, I mentioned some tools that you can use to gather information about passwords within an image acquired from a Windows system.  This included tools that would not only quickly illustrate whether or not a user account has a password, but also allow you to do some password cracking.  Craig Wright has started a thread of posts his blog regarding password cracking tools; this thread goes into a bit more detail regarding the use, as well as pros and cons of each tool.

Thoughts on Tool Validation
Now again I see something posted in the lists and forums regarding tool validation, followed by a lot of agreement, but with little discussion regarding what that actually means.  I have also been contacted by folks who have asked about RegRipper validation, or have wanted to validate RegRipper.

When I ask what that means, often "validation" seems to refer to "showing expected results".  Okay, that's fine...but what, exactly, are the expected results?  What is the basis of the reviewer's expectation with respect to results?  When I was doing PCI work for example, we'd have to scan acquired images for credit card numbers (CCNs), and we sort of knew what the "expected result" should look like; however, we very often found CCNs that weren't actually CCNs (they were GUIDs embedded in MS PE files), but has passed the three tests that we used.  When looking for track data, we were even more sure of the accuracy of the results, as the number of tests were increased.  Also, we found that a lot of CCNs were missed; we were using the built-in isValidCreditCard() function that was part of the commercial forensic analysis tool we used, and it turned out that what the vendor considered to be a valid CCN (at the time) and what Visa considered to be a valid CCN were not completely overlapping or congruent sets.  We ended up seeking assistance to rewrite the functionality of that built-in function, and ended up sacrificing speed for accuracy. 

The point of this is that we found an issue with respect to the expected results returned by a specific bit of functionality, and compared that what we considered a "known good".  We knew what the expected result should look like, and as part of the test, we seeded several test files in an image to run side-by-side tests between the built-in function and our home-brew function.  In this case, we knew what the expected result should look like and had purposely seeded the data set with examples of data that should have been correctly and accurately parsed.

When someone takes it upon themselves to "validate" a tool, I have to ask myself, on what are they basing this validation?  For example, if someone says that they need to validate RegRipper (and by extension, rip.pl/.exe), what does that mean?  Does the person validating the tool understand the structures of Registry keys and values, and do they know what the expected result of a test (data extraction, I would presume) would be?  Validation should be performed against or in relation to something, such as a known-good standard...so, in this case, what standard would RegRipper be validated against?  If the validation is against another tool, then is the assumption made that the other tool is "correct"?

Another question to consider is, is the function and design of the tool itself understood?  With respect to RegRipper, if the test is to see if a certain value is extracted and it isn't, is the tool deemed a failure?  Did the person making the assessment ever check to see if the there was a plugin to retrieve the value in question, or did they simply assume that any possible condition they established was accounted for by the tool? The same thing would be true for tools such as Nessus...in a validation, are the properly constructed plugins available for the test?  RegRipper is open-source, and it's functionality isn't necessarily limited by any arbitrary measure.

Why do we validate tools?  We should be validating our tools to ensure that not only do they return the expected results, but at the same time, we're validating that we understand what that expected result should be.  Let's say that you're looking at Windows 7 Jump Lists, and your tool-of-choice doesn't give the expected result; i.e., it chokes and spits out an error.  What do you do?  I know what I do, and when I hear from folks about tools (either ones I've written or ones I know about) that have coughed up an error or not returned an expected result, I often find myself asking the same round of questions over and over.  So, here's what I do:

1.  Based on my case notes, I attempt to replicate the issue.  Can I perform the same actions, and get the same results that I just saw?

2.  Attempt to contact the author of the tool.  As I have my case notes currently available (and since my case notes don't contain any sensitive data, I can take them home, so "...my case notes are in the office..." is never an excuse...), I know what the data was that I attempted to access, where/how that data was derived, which tool and version I was using, and any additional tools I may have used to perform the same task that may have given the same or similar results.  I can also specify to the author the process that I used...this is important because some tools require a particular process to be correctly employed in their use, and you can't simply use it the way you think it should be used.  An example of this is ripXP...in order properly use the tool, you need to either mount the XP image via FTK Imager v3.0 in "file system/read-only" mode, or you have to extract all of the RPx subdirectories from the "_restore{GUID}" directory.  Doing it any other way, such as extracting the System hive files from each RP into the same directory (renaming each one) simply won't work, as the tool wasn't designed to address the situation in that manner.

3.  Many times, I'm familiar with what the format of the data should look like...in particular, Registry hive files, Jump Lists, etc.  Now, I do NOT expect every analyst to be intimately familiar with binary file formats.  However, as a professional analyst, I would hope that most of us would follow a troubleshooting process that doesn't simply start and end with posting to a list or forum.  At the very least, get up from your workbench or cubicle and get another analyst to look at what you're trying to do.  I've always said that I am not an expert and I don't know everything, so even with a simple tool, I could be missing a critical step, so I'll ask someone.  In a lot of cases, it could be just that simple, and reaching out to a trusted resource to ask a question ends up solving the problem.  I once had a case where I was searching an image for CCNs, and got several hits "in" Registry hive files.  I then opened the suspect hive files in a Registry viewer and searched for those hits, but didn't find anything.  As I am somewhat familiar with the binary format of Registry keys and values, I was able to determine that the hits were actually in yet-to-be-allocated sections of the hives...the operating system had selected sectors from disk for use as the hive files grew in size, and those sectors had once been part of a file that contained the potential CCNs.  So, the sectors were "added" to the hive files, but hadn't been completely written to by the time the system was acquired.

So, the point is, when we're "validating" tools, what does that really mean?  I completely agree that tools need to be validated, but at what point is "validating" a buzzword, and at what point is it meaningful?

Updates and Links

ECSAP
I had a great time speaking on timeline analysis at an event last week...it was a great opportunity to get out in front of some folks and talk about this very important and valuable analysis technique.  My impression was that most of the folks in the room hadn't really done this sort of analysis beyond perhaps entering some interpreted times and data into a spreadsheet.

One take-away for me from the conference speaking is that people like to get free stuff.  In this case, I had one DiskLabs Find Evidence keyboard key left, and as I tend to do with conferences where I speak, I also gave away copies of my books...I gave away one copy of DFwOST and one of WRF (both of which were signed).  I hope that the continuing promises of free stuff kept folks coming back into the room from breaks... 

Along those lines, something I would offer back up to conference attendees is that speakers are people just like you, and they like to get free stuff, too...in particular, feedback.  Did what they say make sense?  Was the presentation material something that you feel you can use?  A simple "yes" doesn't really constitute feedback.  Some of us (not just me) have also written books or tools, which we may refer to...and getting feedback on those is always a bonus.  But again..."cool" isn't really "feedback".

I can't speak for every presenter, but I value honest, considered feedback, even if it's negative, over a positive albeit empty statement.  If what I talked about simply isn't useful, please...let me know.  If it's too easy or too hard to understand...let me know.  I think that most folks who present would welcome some honest feedback on what they covered.

Investigation Plans
Chris posted recently on the need to develop an investigation plan prior to doing any analysis.  Chris even outlines an exercise to clarify that, and to keep it firmly planted in your mind while you conduct your analysis.  I tend to do something very similar...I copy what I'm supposed to do (the goals) from the statement of work or contract to the top of the MSWord document I use for case notes, usually right below my description of the exhibits I've received.  From there, I also write a description of my initial approach to the analysis...keyword searches I may want to run, as well as anything of note that I may have available, such as a time frame to work with (i.e., "online banking fraud was found to have begun on 20 March, so begin timeline analysis of the system prior to that date...").

Analysis plans are not set in stone...they are not rigid scripts that you need to follow lock-step, beginning to end.  We all know that no plan survives first contact...the idea of an analysis plan is to get us started and keep us focused on the end goal, what we hope to achieve and what question(s) we need to answer for our customer.  Too many times, we won't have a plan and we'll find something "interesting" and begin running ourselves down that rabbit hole, and by the time we take a breath to look around, the original goals of the exam are nowhere in sight, but we've consumed considerable time getting there.

Timelines
Having presented recently on the topic of timelines, and working on some code to more fully exploit Windows 7 Jump Lists as forensic resources, the creation and use of timelines have been on my mind a lot recently.  I prepared and delivered a 2-day, hands-on course in timelines in June, and recently (ECSAP) presented a 2-hr compressed version of the class...which really doesn't do the subject justice (next time I'll push for at least a 4 hr slot).  One of the things I've been thinking about is how useful timelines can be from both an investigative and an analytic perspective, and how a timeline can be used to answer a wide range of questions.

One example involves artifacts from the use of USB devices on Windows systems; I've seen a number of questions in forums and lists in which the original poster (OP) identifies an anomaly that is either interesting, or needs to be explained as part of the examination...something appears odd with respect to the observed artifacts.  Often the question is, "what could have caused this?", and the answer may be found by developing a timeline of system activity, and identifying surrounding events and context to the observed artifacts.

Malware
Here's a great write-up on the Malware FreakShow 3 presentation provided by two TrustWave SpiderLabs researchers at DefCon19.  The presentation addresses malware found on Windows-based point-of-sale ("POS"...take that any way you like...) devices.

Tools
Need to find Facebook artifacts?  Take a look over on the TrustedSignal blog...there's a post indicating that a Python script has been updated and is available.  You never know when you're going to need something like this...

Resources and Links
Ken's (re)view of GFIRST...what I really like about this post is the amount of his perspective that Ken encapsulates in his post, giving his views and insights of what he saw and experienced.  Too many times in the community when someone talks about an event they attended or a book they read, the review is very mechanical..."the speaker talked about..." or "the book contains eight chapters; chapter 1 covers...".  I think this is odd, in a way, because when I talk to folks about what they want to see in a presentation or book, very often when they're looking for is the author's insights...so, in a way, this sort of goes back to what I was saying in the ECSAP section of this post.

Here's an interesting post regarding not just a trick used by malware to confuse a potential victim, but the post also describes the use of MoonSol's DumpIt and the Volatility Framework.

The DFS guys posted their materials from GFIRST and OMFW...thanks to Andrew and Golden for doing that.  There are a couple of great slide decks available; if you want to see how they investigated a data exfil incident (speaking of analysis plans), take a look at their slide pack from GFIRST...it's like reading their case notes from an exam.  You'll have to excuse a misspelling or two (slide 19 mentions the setup.api log file; spelled correctly on slide 40), but for the most part, their examination of the USB history, et al, from an XP system is a very good view into an actual investigation, and well worth writing into a process or checklist.

A couple of thoughts from the presentation:
slide 38 - instead of writing a "wrapper script" to import the information into Excel, it might be easier to modify the usbstor.pl plugin (use of a "wrapper script" mentioned again in slide 79)
slide 40 - the LastWrite times of the USBStor subkeys are not used to determine the last time the devices were plugged into the system; this is further indicated by the USB Analysis Process illustrated in slide 43
slide 90 - path should read HKLM\System\CurrentControlSet\Services\lanmanserver\Shares

Speaking of OMFW, gleeda posted to her blog and included links to her, MHL, and Moyix's slides.

DFwOST
Richard Bejtlich posted his impressions (not a full-on review) of DFwOST.  Thanks for the vote of confidence on a second edition, Richard...also, I do agree with what he mentioned with respect to the images, but as with WRF, there's not a lot that the authors can do about what the publisher or printer does with images.

Links and Updates

Working Remotely
Thanks to a tweet from Richard Bejtlich, I ran across this very interesting post titled, "Working Remotely".  The post makes a great deal of sense to me, as I joined ISS (now part of IBM) in Feb, 2006, and that's how we rolled at the time.  My boss lived about 2 miles from me, and there was an office in Herndon (with a REALLY great, albeit unused, classroom facility), but we had team members all over...Atlanta, Kansas City, Norfolk, and then as we expanded, Chicago, Corpus Christi, and Tulsa.  We lived near airports (our job was to fly out to perform emergency incident response), and FedEx (or insert your favorite shipment vendor) rounded out our "offices".

Even when we weren't flying, many of us were constantly in touch...so much so that when one person needed assistance with an engagement, it was easy for us to provide whatever support was needed.  Encryption made it very easy to send data for analysis, or for someone to provide insight to, or to write a script to parse a much wider sample of data.  Imagine being on an engagement and needing support...so you send someone a sample of data, and when you wake up, there's a parsing tool in your inbox. 

Something that the article points out is that it takes a certain kind of person to work remotely and that's very true...but when you find them, you need to do everything you can to not just keep them, but grow them.  The article also points out that if you want the best of the best, don't restrict yourself to your local area, or to those who are willing to relocate.  And in today's age, remote communications is relatively easy...if you don't want to bring everyone together once a year (more or less) due to the cost of gas and air fare, Skype and $20 web cam can do a LOT!

Jump Lists
Jimmy Weg has done some testing of Windows 7 Jump Lists (and shared his findings on the Win4n6 group list), and found (thus far) that the DestList stream structure within the Automatic Destination (autodest) Jump List does appear to be an MRU of sorts.  In his testing using Notepad to open text files, the FILETIME object written to the structure for each file correlated to when he opened the files.

When testing Windows Media Player, Jimmy found that there were no MRU entries for the application in the user's Registry hive, nor were any Windows shortcuts/LNK files created in the user's Recent folder.  Jimmy also found that applications such as OpenOffice (AppID: 1b4dd67f29cb1962) created Jump Lists, as well. 

Jimmy mentions Mark Woan's JumpLister application in his post for viewing numbered stream information found within the autodest Jump Lists; this is a very good tool, as is the MiTeC Structured Storage Viewer, although SSView doesn't parse the contents of each stream.  I like to use SSView at this point, although I have written Perl code that will parse the "autodest" Jump List files (those ending in "*.automaticDestinations-ms"), as it is based on the MS OLE format, and each numbered stream is based on the LNK file format.  I have also written code for parsing the DestList stream structure, as well, and thanks to Jimmy's testing, the validity and usefulness of that code is beginning to come to light.  My hope is that by having shared what I've found with respect to the DestList structure thus far, others will continue the research and identify other structure elements that can be of value to an analyst, and share that information.  I've also found some deprecation issues with Perl 5.12, with respect to some of the current Perl modules that handle parsing OLE documents; as such, I've taken a look at the MS documentation on the compound document binary specification, and I'm working on writing a platform-independent Jump List parser.

Troy Larson, senior forensic analyst at Microsoft, added that the DestList stream entries are either an MRU or MFU (most frequently used) list, depending upon the application, and that the order of activities in the DestList stream is reflected when you right-click on a pinned application (to the TaskBar).  The order of items in the DestList stream is apparently determined by how recently/frequently the activity (document opened, etc.) is performed.  Troy went on to mention that as of Windows 7, other methods of tracking files have been deprecated in favor of the API used to create Jump Lists.

CyberSpeak
Ovie's posted a new CyberSpeak podcast, this one addressing the launch of CDFS, which I mentioned in my last blog post.  If you have any questions about this organization, I'd recommend that you download the podcast, and give it a listen. Ovie interviews Det. Cindy Murphy, who's been a member of LE since 1985, and invited me to WACCI last year.

If you want to learn more about CDFS, give this podcast a listen.

Ovie, it's good to have you back, my friend.

Hostile Forensics
Mark Lachniet has released a whitepaper through the SANS Forensics blog site titled, "Hostile Forensics". This is the name given to "penetration-based forensics", in which the forensic analyst uses penetration techniques in order to gain access to a computer system in order to further exploit that system through forensic analysis techniques.

The PDF whitepaper, currently in version 1.0, is available online here.  The paper is 43 pages long, but if this is something that you're interested in, it's well worth the time it takes to read it.  Mark lays out the structure for his proposal, which he states is the result of a "thought experiment". 

Tools

It looks as if x0ner has released PDF X-RAY, an API for static analysis of PDF documents for malicious code.


On a similar note, Cuckoo is a freely available sandbox for analyzing PDF files and malware that runs in VirtualBox.  Cuckoo has it's own web site, as well.  If you're performing malware analysis, this may be something that you'd like to take a look at, along with Yara.  These are all great examples of the use of open-source and free tools for solving problems. 

Updates and Links

Meetup
Just a reminder to everyone who wasn't able to make it to any of the big conferences going on in New Orleans or Las Vegas this week (or if you returned in time)...the NoVA Forensics Meetup for Aug 2011 will be Wed, 3 Aug, starting at 7pm. 

Be sure to check out the NoVA Forensics Meetup page to see what's going on.

Remember, anyone can come, and you don't need to be part of a group or anything.  There are no fees or anything like that.

All Things Open Source
Sergio Hernando posted some Perl code for performing Chrome forensics, specifically processing the history file via Perl.  For me, it's not so much that Sergio wrote this in Perl, because I can follow instructions and get Python or whatever else installed...no, what I like about this is that not only did Sergio take the time to explain what he was doing, but he shows it through an open-source mechanism.

I really like solutions to DFIR problems that use free or open-source tools, because in most cases, they also don't add so many layers of abstraction that ultimately, all you really know that went on was, "I pushed a button."  Solutions such as what Sergio has provided give us more than just that abstract view into what was done...in this case, it's more along the lines of "...I accessed this SQLite database because it contained this information, and this is what was found/determined, in the context of this other data over here...".

The script can be found at Sergio's Google Code site.

Also, be sure to take a look at Sergio's blog post on using Perl to parse the Firefox Download Manager database.

Techniques
For those of you who weren't able to make it to any of the conferences going about this time of the year (OMFW/DFRWS, BlackHat, etc.), looking out across the landscape of presentations, there were definitely some very interesting topics and titles.  While actually being at the conference affords you the opportunity to experience the flavor of the moment, and to mingle with others in the community, many of the conferences do provide copies of the presentations after the conference, and there's always supporting information available from additional sources.

For example, take this presentation on document exploitation attacks...this sounds like a very interesting presentation.  However, there's also some other information available, as well...for example, take a look at this post from the Cisco Security blog; I found this to be a very interesting open-source solution for extracting EXEs from (in this case, MS Word) documents.  Let's also not forget the Didier Stevens has done considerable work on detecting and extracting suspicious elements from PDF documents.

RegRipper
Speaking of open source and techniques, Corey Harrell put together a great post on how he uses RegRipper to gather information about the operating system he's analyzing.  This is a great use of the tool, and another great example of how an analyst can use the tools that are available to get the job done.

Volatility
For those of you who many not have known, the Open Memory Forensic Workshop (OMFW) was held recently, just prior to DFRWS in New Orleans.  Perhaps one of the most exciting things to come out of the conference (for those of us who couldn't attend) is Volatility 2.0! If you notice, under Downloads, there's a standalone Win32 executable available.

Volatility is one of the best of the open source projects out there.  Not only is the framework absolutely amazing, providing the capability to analyze Windows physical memory in ways that aren't available anywhere else, but it's also a shining example of how a small community of dedicated folks can come together and make this into the project that it is.  If you have any questions at all, start by checking out the Wiki, and if you do use this framework, consider contributing back to the project.

Updates

WRF Review
Andrew Hay posted a glowing review of Windows Registry Forensics on Amazon recently.  I greatly appreciate those who have purchased the book and taken the time to read it, and I especially appreciate those who have taken the time to write a review.

DFwOST
Speaking of books, it looks as if DFwOST has been picked up as a text book!  Pretty cool, eh?  I certainly hope Cory's proud of this...this is a great testament to the efforts that he put into the book, as he was the lead on this...I was just along for the ride.

One of the interesting things about this is that I've heard that other courses may be picking this book up as a resource, in part due to the focus on open source...many of the digital forensics courses out there are held at community colleges that simply cannot afford to purchase any of the commercial forensic analysis applications.  Also, I do appreciate the "tool monkey" comment from the blog post linked above...let's start folks out with an understanding of what's going on under the hood, and progress from there.  The age of Nintendo forensics is over, folks!

If that's the case for you, either as an instructor or individual practitioner, consider my other books, as well...I focus on free and open source tools almost exclusively, because...well...I simply don't have access to the commercial tools.

NoVA Forensics Meetup
Just a reminder...our next meetup is Wed, 3 Aug, starting at 7pm.  One of our members who attended our last meetup has offered to facilitate a discussion regarding some recent cyber activity and how it affects what we do.  I'm really looking forward to this, as I think that it's a great way for everyone to engage.

For location information, be sure to check out the NoVA Forensics Meetup page on the right-hand side of this blog.

PFIC
The agenda for PFIC 2011 has been posted, and I'll be presenting on Tuesday afternoon.  My presentation will be (hopefully) taking the "Extending RegRipper" presentation a bit further.  It works as it is now, but one of the things I want to do is provide a means for the analyst to designate (via both the UI and CLI) to select which user profiles to include in scans.

Bank Fraud
Yet another bank is being sued by a small business following online banking fraud.  Brian Krebs had done considerable work in blogging about other victims (most recently, the town of Eliot, ME).  What should concern folks about this is that once the victim is breached and the money transfers complete, a battle ensues between the victim and the bank.  What isn't happening is this equation is that even with all the press surrounding this, there continue to be victims, and instead of focusing on better security up front, efforts are expended toward suing the bank for "inadequate security measures". Should the bank have had some sort of anomaly detection in place that said, "hey, this connection isn't from an IP address we recognize..."?  Sure.  Should there be some other sort of authentication mechanism that isn't as easily subverted?  Sure.  There are a lot of things that should have been in place...just ask anyone who does PCI forensic assessments, or even just IR work.

One of the things Brian has recommended in his blog is to do all online transactions via a bootable live CD.  I think that this is a great idea...say your Windows system gets infected with something...if you boot the system to a live Linux distribution, this won't even "see" the malware.  Conduct your transactions and shut the system down, and you're done.

Another measure to consider is something like Carbon Black.  Seriously.  Give the guys at Kyrus a call and ask them about their price point.

Cell Phones As Evidence
Christa Miller recently had a Cops2.0 article published regarding how LEOs should approach cell phones/smart phones.  Reading the article, I think that all of it is excellent advice...but you're probably wondering, "what does this have to do with Windows IR or DF work?"  Well, something for analysts to consider is this...if you're analyzing a Windows computer (ie, laptop) confiscated as part of a search warrant, be sure to look to see if a phone has been sync'd to the system.  Did the user install iTunes, download music, and then load the music on their iPhone?  If so, the phone was likely synced/backed up, as well.  Is the Blackberry Desktop Manager installed?  Did the user back their phone up?  If so, the backup files may proved to be significant and valuable resources during an investigation.

Did you map all of the USB removable storage devices that had been connected to the system?  You don't need to have the management software installed to copy images and videos (hint, hint) off of a phone...just connect it via a USB cable and copy the images (which will likely have some very useful EXIF data available).

analyzemft 2.0 Released!
Matt Sabourin updated David Kovar's analyzemft.py to make it completely OO!  David has done some great work putting the tool together, and Matt's extended it a bit by making it OO, so that it can be called from other Python scripts.

The project is now hosted on Google Code.

More Links, Updates

Meetup
Our 6 July NoVA Forensic Meetup went very well, and I wanted to thank Tom Harper for putting in the time and effort that it takes to provide his presentation, and to also thank the ReverseSpace folks for hosting our meetings!  This time, we had about 20 or so folks show up...some new...and I wanted to thank everyone who took the time out to come by and take part in our event.

What I liked about Tom's presentation was the fact that Tom's a practitioner, and he approaches solutions from that perspective.  Tom was at OSDFC, and after the conference mentioned that some of the presentations we saw that day were from folks from the academic side of DFIR, and not so much the practitioner side.  I agree with that sentiment...and Tom's approach is practical and all about gettin' the job done.

I should also note that the ReverseSpace location doesn't say "ReverseSpace" on the outside, nor is there a sign by the road.  The address is 13505 Dulles Technology Drive, Suite 3, in Herndon, VA, and the facility says "Cortona Academy" on the outside.  Don't worry about writing this address down...simply check out the "NoVA Forensics Meetup" page associated with this blog.

Our next meetup is scheduled for 3 August (same time, 7-8:30pm) and we're looking for presentation or discussion ideas, as well as presenters.  @sampenaiii suggested via Twitter that we have a discussion on LulzSec and the impact of their activities on security and forensics; this sounds like a great idea, and I think that we'll need to have a slide or two with some background for those who may not be familiar with what happened. 

Cory-TV
Cory Altheide recently provided a link to the video of a presentation he gave in Italy on 2 May 2011.  The presentation is titled, "The death of computer forensics: digital forensics after the singularity", and is very interesting to watch.  Cory is a very smart guy, and as Chris Pogue recently tweeted, Cory is the bacon of the DFIR community, because he makes everything better!

Cory presents some very interesting thoughts regarding what were once thought to be "forensics killers", and the future of digital forensic analysis. One of the things that Cory mentioned was the existence of metadata, which is not often removed, simply because the user doesn't know about it.  There have been some pretty interesting instances where metadata has played a very important role (here, and here), and I agree with Cory that it will continue to do so, particular due to the fact that we have new formats, devices, and applications coming out all the time.

Clearly, Cory talked about much more than just metadata in his presentation, and I simply can't do justice to it through any sort of concise description.  Instead, I highly recommend that you take the hour+ to sit down and watch it.  I think that the overall point that Cory makes is that as available drive space increased (every time it did) and decreased in price, and as platforms to be analyzed have become more complex and varied, there have been those who've claimed that these things would be the "death of digital forensics"; instead, analysts have adapted. 

MBR Analysis
Speaking of Chris Pogue, he recently posted to his blog regarding MBR Analysis, referring to a discussion he and I had had not long ago.  What I like about Chris's post is that he's talking about it, and by him doing so, my hope is that the things we talked about reach more analysts.  Chris is the author of the Sniper Forensics presentations (here's the one he gave at DefCon18), and he's been getting a lot of mileage from the series, and presents to a lot of people.  As such, my hope is that more people will hear about MBR analysis, how it can be used, and start looking at this as a viable part of a malware detection process/checklist.

When you read the post, don't get caught up in the terminology...what I mean by that is, to clarify a couple of things, the TSK mmls reads the partition table within an image of a physical disk (you don't have one of these if you acquire a logical image of the C:\ volume, for example), and provides you the offsets to the partitions.  The offset to the active partition is often 63 sectors (indexed at 0), not "0x63".

Speaking of the Sniper Forensics presentations, Chris also has another post up on the SpiderLabs Anterior blog that's worth a read.

Additional Thoughts
I recently posted some thoughts regarding how the structure that data is stored in (as well as where within that structure) can provide context to the data that you're looking at, and an email exchange with James, who commented on that post, led to some thoughts regarding timelines.

James (I hope you don't mind me pointing this out...) in a comment that log2timeline doesn't provide enough context.  I was curious about this, and in the ensuing email exchange, at least part of what James was referring to was things like, if an image file was created on the system, provide a link to that file, that would then be opened in a viewer.  In this way, the analyst would have access to additional context.

I thought that this was an interesting idea...and I still do.  Having my own process for creating timelines (taking nothing away from Kristinn's efforts with log2timeline, of course) I thought about how you could implement something like this...and got stuck.  Here's why...let's say that you completely restructured timeline creation and had the timeline itself available with either the image itself mounted as a volume, or files extracted from the image...would you provide links to all files that were created on the system?  I'm thinking not.  Also, if a file is modified, what do you link to?  What value or context is there if you don't know what was modified in the file?  The same would be true for Registry keys.

However, I do think that there are some benefits to this idea, but it really depends upon how you implement it.  For example, let's say that you found some time stamped data in the pagefile or in unallocated space, and wanted to include it in your timeline.  You could do that, and then include a link to the data...but not to the offset within the image; instead, extract the data (plus 100+ bytes on either side of the data) into a separate file, and provide a link to that file.  The same might be true for other files...for example, if your timeline analysis leads you to determine that the infection vector was spear phishing via a PDF file, rather than copying the PDF file out of the image and linking to it, maybe what you could do is copy the PDF file out of image, and parse the offending portions of that file out, emasculate them (i.e., extract them to a text format, etc.), and then link to that.  You might extract images, and link to those...it all depends on how you want to present the data.  But my point is, this may not be something that you would want to completely automate; instead, use the timeline to perform your analysis, and once you've isolated the appropriate entries in your timeline, provide links to relevant data (either the file, a portion of a file, or to your analysis of the file) in order to add context and value to your timeline.

Links and Updates

CyberSpeak
Ovie's got a new podcast up, be sure to check it out. In this podcast, Ovie interviews John Goldfoot, lawyer and author of the new paper, The Physical Computer and the 4th Amendment, published in the Berkeley Journal of Criminal Law.  The overall idea is of the paper is to no longer view the computer as a system of containers, but simply as a container, in itself.

Ovie's podcasts are great listening and very educational.  If you're one of those people who has to have a bit of coffee before becoming coherent in the morning, the CyberSpeak podcast is a great accompaniment for your Starbucks.

I especially like John's reference to the dog that did not bark, which is a Sherlock Holmes reference to the fact that the absence of evidence that would be present to something that happened, thus suggesting that it did not happen.  This is very similar to something I've said and published in my books for a long time...the absence of an artifact where you would expect to find one is, itself, an artifact.

Take away from the podcast...don't use the S-word!

Anti-Malware Tools of Note
Klaus is back, with a great post pointing out anti-malware tools of note!  I've always found Klaus's posts to be chock full of great information about the various tools that he finds, and in many cases, has tried and posted his sort-of-Consumer-Reports version of the tool.  I find posts like this to be very useful, particularly as I tend to get a lot of "...we think this computer has/had malware on it; find it..." cases, and as such, I have what I believe to be a comprehensive process, in a checklist, that includes (but is not limited to) running AV scans.  In that process, I specifically steps that require me to check the timeline of the system to determine which AV scanner(s), if any, have already been run on the system.  Many times, the system will have a fairly up-to-date scanner (Symantec or McAfee) running (find Application Event Logs records, AV logs, etc.), and in a good number of cases, I've found that an Administrator had also installed and run Spybot Search & Destroy, and maybe even the MalwareBytes Anti-Malware scanner.  If none of the tools that have already been used on the system found any threats, then it's incumbent upon the analyst to NOT use any of those tools; after all, if scanner A didn't find anything, how much value are you really providing to the customer to run your edition of scanner A on the mounted image and not finding any threats?

Compromises
I recently ran across this little gem, which states some pretty interesting "statistics".  In this case, I use quotes around that last term, as I'm not entirely sure that something wasn't edited out of the article prior to publication.  For example, the biggest issue I see with the article is that I don't understand is how you can survey 583 businesses, and then extrapolate their responses to "90% of US businesses"; this suggests that the 583 respondents, without any indication of their makeup, are a representative sampling of all US businesses.  The article does point to this Ponemon Institute report.

Based on the survey results, there seem to be some interesting, albeit not surprising  findings...

"...59% of respondents claimed that the worst consequences of the attacks were theft of information, followed by business disruption in second place."

This is interesting, as more and more organizations seem to be coming to this conclusion, that data theft is an issue.  It wasn't so long ago that data theft was something of an afterthought for many of the organizations I encountered

Another interesting quote from the article:

"Employee mobile devices and laptops are believed to be the most likely entry point through which serious attacks are unleashed."

I found this particularly interesting, because as a responder, in most of the cases I've worked, there is very often little done to attempt to determine the "most likely entry point".  I'm guessing that terms such as "believed" and "most likely" are intended to convey speculation, rather than assertions supported by fact.

One particular quote stood out from the article; Dr. Larry Ponemon reportedly stated, “conventional network security methods need to improve in order to curtail internal and external threats.”

Now, I realize that this is likely taken out of context, but "conventional network security methods" are likely not those things that security professionals have been harping on for years; these security methods are most likely what the respondents have in place, not what they should have in place.  The fact is that many organizations may not have the ability to detect and effectively respond to incidents, which not only makes the threats appear to be extremely sophisticated, but also ends up costing much more in the long run.

The Value of Data
My last blog post, in which I asked, who defines the value of data, generated some interesting comments and discussion.  Based on the discussion and further thought, I'm of the opinion that, right or wrong, and due to several factors, the value of data is entirely subjective and most often up to the analyst.

Think about it...how do most analysis engagements start?  Ultimately, regardless of where or how the overall engagement originates, an analyst is presented with data (an acquired image, logs, etc.) and a set of requirements or goals.  Where did these goals come from?  Many times, the "customer" (business organization, investigator, etc.) has stated their goals, from their perspective, with little to no translation or understanding of/expertise in the subject (beyond what they've read in the industry trade journal du jour, that is...).  These are then passed to the analyst via a management layer that often similarly lacks expertise, and the analyst is left to discern the goals of the analysis without any interaction or exchange with the "customer" or "end user". 

Now, consider the issue of context...who determines the contextual value of the data?  Again...the analyst.  Isn't it the analyst who needs to know about the data in the first place?  And then isn't it the analyst who presents the data to someone else, be it a "customer" or "end user"?  If the analyst's training has made them an expert at calculating MFT data runs, but that training didn't address the Windows Registry, then who determines the contextual value of all of the available data if not all of the data is analyzed and/or presented?

No, I'm not busting on analysts, not at all...in fact, I'm not making derogatory remarks about anyone.  What I am suggesting is that we take a look at the overall DFIR process and consider the effect that it has on studies and surveys such as was mentioned earlier in this post.  Incidents of all kinds are clearly causing some pretty significant, detrimental effects on organizations, but IMHO and based on my experience over the years, as well as talking with others in the industry, it's pretty clear to me that incidents and compromises are becoming more targeted and focused, and the battle ensues between the attacker and the target's management.

Early this year, I read and wrote a review for CyberCrime and Espionage, by John Pirc and Will Gragido.  Two statements I made in that review are:

What is deemed "adequate and reasonable" security is often decided by those with budgeting concerns/constraints, but with little understanding of the risk or the threat.

Compliance comes down to the auditor versus the attacker, with the target infrastructure as the stage.  The attacker is not constrained a specific compliance "standard"; in fact, the attacker may actually use that "standard" and compliance to it against the infrastructure itself.

I believe that these statements still apply, and do so, in fact, quite well.  However, I'd like to combine them into, A data breach comes down to the management versus the attacker.  Attackers are neither concerned with nor constrained by budgets.  Attackers pry the cover off of technologies such as Windows XP, Windows 7, Windows Media Player, Adobe Reader, etc., and dig deep into internal workings, knowing that their targets don't do the same.  Management determines the overall security culture of their organization, as well as the use of resources to implement security.  Management also determines whether their organization will focus on protecting their data, or simply meeting the letter of the law with respect to compliance.

Don Weber, a former US Marine, recently tweeted, "In their minds #LULZSEC ~== WWII French Resistance".  That's very appropriate...when the Germans invaded France, they didn't know the lay of the land the way the resistance fighters did; sure, they could navigate from point to point with a compass, and move in force with tanks and troops, but the resistance fighters knew the land, and knew how to move from point to point in a stealthy manner, remaining out of site by using the terrain to their advantage.

Tool Update
John the Ripper, a password cracker for Unix, Windows, DOS, BeOS, and OpenVMS has seen an update, intended to make it a bit faster with respect to cracking passwords.  There's a great deal of information available in the OpenWall wiki for the tool.

Selective Imaging
I ran across a reference to this thesis paper from Johannes Stüttgen via Twitter this morning.  The paper is well-worth reading, and very informative, but at the same time, I can say from experience that there are a LOT of responders and analysts out there (myself included) who have already gone through the same sort of thought process and come up with our own methods for addressing the same issues raised by the author.  Now, that is not to say that the paper doesn't have value...not at all.  I think that after having read through the paper, it's going to provide something to everyone; for example, it's going to present a thought and exploration process to the new analyst who doesn't have confidence in his or her own abilities and experience.  We often work in isolation, on our teams, and may not have someone more experienced to "bounce" things off, and if you don't feel that you can reach out to someone else in the community, this paper is a great resource.  I also think that the paper may open the eyes of some more experienced analysts, providing insights to things that may not have been considered during the development of their own processes.

Updates, Links, Etc.

OSDFC
I'm slotted to speak at the Open Source Digital Forensics Conference (put on by Brian Carrier) in McLean, VA, on 14 June.  I'll be presenting on "Extending RegRipper", and I've posted to slides to the WinForensicAnalysis site.

You'll notice something a bit uncharacteristic (or me) about the presentation...I put a LOT of text in the slides.  I sorta figured I needed to do this, as when I've talked about this topic to others, I think I get a lot of head knodding and "okays" so that I'll just stop talking.  I wanted to have the text on the slides for folks to look at, so that when someone was noodling these ideas over (as opposed to deciding whether or not to stay for the rest of the presentation...), they can refer back to what's on the slides, and not have to go with, "...but you said...".

Fresh off of attending the SANS Forensic Summit, Cory Altheide will be providing training on 13 June, and speaking at OSDFC on 14 June.  Corey and I will also be available to sign your copy of DFwOST, if you'd like. 

RegRipper
Speaking of open source tools, Mark Morgan posted "Using RegRipper inside EnCase Enterprise"...jokes aside, I think that this is a great use of resources!  I mean, it wasn't part of the design of RegRipper, but hey, I think things worked out pretty well, and Mark (like others before him) found a way to get the most out of the tools he's using.  Great job!

VSCs
Stacey Edwards has a great post up over on the SANS Forensic blog that demonstrates how to extract file system metadata/MAC times from files in Volume Shadow Copies, using LogParser.  The cool thing about what she discussed is that it can all be scripted through batch files...that's right, you can have a batch file that will run through designated VSCs, mount each one, run the LogParser command against it, unmount the VSC, and move on to the next one.  Pretty cool stuff.  Think of all of the other stuff you could script into a batch file, too...like RegRipper/rip, etc. 

MetaData
Corey Harrell has another really good post over at the jIIr blog, regarding why certain document metadata could possibly look the way it does.  He's taken the time to do some testing, lay out and describe what he did, and then present it clearly.  That kind of sounds like what we all have to do in our jobs, right?  ;-)

EVTX
Andreas has updated his EVTX parser code to v1.0.8.  He's put considerable effort into figuring out the binary format for the Windows Event Logs ("new" as of Vista) and provided his open source code for parsing them.  I've also found LogParser to be very helpful with this.

NoVA Forensics Meetup
Keep 6 July on your calendar for our next meetup.  Tom Harper has graciously offered to present on setting up a dynamic malware analysis platform, so come on by, bring a friend, and join us!