There have been some exciting developments recently on the Windows digital forensic analysis front, and I thought it would be a good idea to bring them all together in one place.

Recover CMD sessions from the pagefile
If you perform analysis of Windows systems at all, be sure to check out Robert's blog post that discusses how to use page_brute (which I'd mentioned previously here) to recover command prompt sessions from the Windows pagefile.  In the post, the author mentions quite correctly that grabbing a memory image still isn't something that's part of standard incident response procedures.  If you receive a laptop system (or an image thereof) you may find a hibernation file, which you can then analyze, if doing so is something that will help you attain your goals.

Page_brute is based on Yara rules, and Robert shares the rule that he wrote...if you look at it, and follow his reasoning in the post, it's amazingly simple AND it works!

This sort of analysis can be very valuable, particularly if you don't have a memory dump available.  As we learned at OMFW 2013, Volatility is moving in the direction of incorporating the pagefile into analysis, which is fantastic...but that's predicated by the responder's ability to capture a memory dump prior to shutting the system down.

I got yara-python installed (with some help...thanks!) and I then extracted the pagefile from an image I have available.  I had also copied the rule out of Robert's blog post, and pasted it into the default_signatures.yar file that is part of page_brute, and ran the script.  In fact, page_brute.py worked so well, that as it was running through the pagefile and extracting artifacts, MS Security Essentials "woke up" and quarantined several extracted blocks identified as Exploit:js/Blacole, specifically KU and MX variants.  I then opened a couple of the output files from the CMDscan_Optimistic_Blanklines folder, and I wasn't seeing any of the output that Robert showed in his blog post, at least not in the first couple of files.  So, I ran strings across the output files, using the following command:

D:\Tools>strings -n 5 H:\test\output\CMDscan_Optimistic_Blanklines\*.page | find "[Version"

I didn't get anything, so I ran the command again, this time without the "[", and I got a number of strings that looked like Registry key paths.  In the end, this took some setup, downloading a script and running two commands, but you know what...even with that amount of effort, I still got 'stuff' that I would not have gotten as quickly.  Not only has page_brute.py proved to be very useful, it also illustrates what can be done when someone wants to get a job done.

Resources
Excellent Yara post; look here to get the user manual and see how to write rules.

Registry Forensics Class
If you're interested in an online course in analyzing the Windows Registry, Andrew Case, Vico Marziale, and Joe Sylve put together the Registry Analysis Master Class over at The Hacker Academy.  If you're interested in the course, take a look at Ken Pryor's review of the class to see if this is something for you.

Windows Application Experience and Compatibility
Corey's got a new blog post up where he discusses the Windows Application Experience and Compatibility feature, and how the RecentFileCache.bcf file can serve as a data source indicating program execution.  As usual, Corey's post is thorough, referencing and building on previous work.

Corey shared a link to his blog post over on the Win4n6 Yahoo group, and Yogesh responded that he's doing some research along the same lines, as well, with a specific focus on Windows 8 and the AmCache.hve file, which follows the same file format as Windows Registry hives.  Yogesh's blog post regarding the AmCache.hve file can be found here.  Why should you care about this file?  Well, from the post:

This file stores information about recently run applications/programs. Some of the information found here includes Executable full path, File timestamps (Last Modified and Created), File SHA1 hash, PE Linker Timestamp, some PE header data and File Version information (from Resource section) such as FileVersion, ProductName, CompanyName and Description.

This information can be very valuable during analysis; for example, using the SHA-1 hash, an analyst could search VirusTotal for information regarding a suspicious file.  The file reference number from the key name could possibly be used to locate other files that may have been written to the system around the same time.

Yogesh has been posting some great information over on his blog recently, specifically with respect to Registry and Windows Event Log artifacts associated with USB devices connected to Windows 8 systems.  Be sure to add it to your daily reading, or to your blog roll, in order to catch updates.

New HEFCBlog book is out!
David Cowen posted that his new book is out!  The book is titled, Computer Forensics InfoSec Pro Guide (Beginner's Guide).  David's also got a new web site to go along with the book...learndfir.com.  There isn't a great deal of information available about this book or its contents yet, but Dave has always been a fount of great things for DFIR, so keep your eyes on the site.  David did state on his blog that he's working on some "links, documents, and forensic images", so look for good things to come.

If you're going to get David's book, I would recommend that you also consider Brett Shaver's book, Putting the Suspect Behind the Keyboard, which provides an investigator's perspective and insight into determining who was sitting at the keyboard.

CyberThreat Detection
Lesley Carhart posted this article over on the Motorola Solutions Community site, mentioning the need for log monitoring, particularly in the face of Mandiant's APT1 report.  A lot of what Lesley says in the post has been mentioned before, but I tend to think that it's important to keep the same message consistent and repeated...just look around and see all of the organizations that get hit and don't have any of what she mentions implemented.

One statement made in the article that caught my attention was:

Attackers frequently spread laterally, system to system, using legitimate accounts and services. Would your organization detect this?

The reason this caught my attention was that as far back as I can remember, even going back to the 2012 DoD CyberCrime Conference, one of the primary complaints about the mention of "lateral movement" is that there is a dearth of information regarding what that looks like...so, how would an organization be able to detect this sort of activity if the folks who know what it looks like aren't sharing the information?  This was the case at DC3 2012...I heard a couple of attendees lamenting the fact that for all of the presentations that included "APT" in the title, none of them actually provided actionable information.  I can only say that I attended three of those presentations, and not one of the authors actually listed what that lateral movement within the infrastructure looks like to an analyst.

Using RegRipper
Ken posted the Work Smarter, Not Harder article to his blog this weekend, which, in part, raises awareness of how to make the most effectively use of RegRipper.  In his post, Ken discusses using some basic functionality of RegRipper...creating custom profiles...and ties that to another recent blog post.  I greatly appreciate the time that Ken took to not only use the tool, but to write about his experience and use of the tool...I think that this really validates how easy-to-use these tools can be, and how effective their use can be in pursuing an examination.  It's one thing for me to write about how to use the tool, it's something else entirely for someone like Ken to share a real-world example of how he used the tool to complete analysis.

One thing that Ken says in the post is:

Running rip.exe -r ntuser.dat -f ntuser-all, for example, will run every ntuser.dat specific plugin against the ntuser.dat file.

A bit of clarification is required here...the command will run every "ntuser.dat-specific plugin listed in the ntuser-all profile against the ntuser.dat file".  My point is that analysts should not assume that every plugin intended to be run against the NTUSER.DAT file is listed in the ntuser-all profile.  This file is a flat text file, with no extension (which simply means that it does not end in ".txt" or ".dat", or...anything) that contains a list of plugins that you'd like to run, in the order that you'd like to run them.  It's always good to check and ensure that the plugins you want to be included in the profile are actually listed.  If not, they're very easy to add, as Ken described in his post.

My own custom RegRipper profile for retrieving program execution artifacts from the NTUSER.DAT hive includes the following plugins:

userassist
sysinternals
compatassist
applets
autorun
muicache
runmru

As many folks are aware, I teach a couple of courses.  During the courses, I invariably meet people who "use" RegRipper on a regular basis...what this most often amounts to is downloading RegRipper v2.5 (if you watched the SANS webcast from January 2013 closely, you could see that Mandiant is still on v2.02...) and simply running the UI version of RegRipper.  But there's so much more available through the tool, as Ken described in his post.

For example, I get asked, "...is there a list of available plugins?" on a regular basis.  This is why I provided a very simple facility through rip.exe to output a list of plugins (described in this blog post), including an option for CSV output.  An example of a command line that I discuss in the courses, for providing just a list of plugins that retrieve information from the NTUSER.DAT hive is:

C:\tools>rip -l -c | find ",NTUSER,DAT," /i > ntuser.csv

Run this command, and then open the resulting .csv file in Excel for easy review.  An alternative would be to simply drop the "find" portion of the command, open the resulting .csv file in Excel, and then sort of the third column to list the plugins based on the hive file.

You can also take this same approach to create specific profiles for USB device tracking within various hives, as well.

Side Note: One question is regularly ask users of RegRipper is, what would make RegRipper a 'better' tool. More/better documentation?  Some additional functionality?  If there's a specific plugin that you'd like to see created, you can take a look at Adam's 3RPG site (he blogged about creating four RR plugins in 15 min.), or you can contact me and request the plugin - all I'll need is a concise description of what you're looking for, and some sample data.  If you provide this information, I'm able to get plugins turned around rather quickly.  There is a LOT of information out there embedded in Registry hive files, and relying on a small group of people to create the plugins, when we're not seeing this information, amounts to a significant loss for the community.

"Cyber" Insurance
Something I've been watching with a bit of fascination is the spread of "cyber" insurance.  Looking back over the response and analysis engagements that I've performed or been involved with over the years, including PCI forensic audits, this is a very interesting development.  You'd need to review the annual reports from companies such as Mandiant, Trustwave and Verizon to see the effect that compliance regulations have had on organizations getting compromised...based on previous year's reports, one might think that there hasn't been much of an effect.

What's clear is that the issue of organizations getting "hacked" is getting even more attention.

CyberGuardians post
I did not attend the SANS Cyber Thread Intelligence Summit 2013, but I did get to read about it at the CyberGuardians blog.  Having been engaged in DFIR work for some time, I thought that both the presentations and the reviews of them were very insightful, and that the focus of DFIR work was moving in the right direction.  So many times as an emergency responder, I would show up and find that the on-site IR team was completely hamstrung, with no ability to get any sort of meaningful information during an incident.  In many cases, even the most basic information needed to simply assess systems had to be requested from network or systems ops folks...this was true not only at commercial and private sector sites, but also within the federal government.

What I really took away from the post is the realization that a mainstream organization such as SANS is now espousing the need for organizations to not only effectively consume (i.e., make use of) threat intelligence, but to also produce and share threat intelligence, as well. A number of consulting organizations offer this as a service, but some of them focus solely on one are of the IR spectrum (i.e., network sources, and not bringing memory- or host-based artifacts into the equation).  Part of the problem with this is that, while these are excellent services, many of the potential consumers of this intelligence are simply neither prepared nor equipped to make effective use of this information.

ImDisk
A new version of the ImDisk Toolkit is available, which works on Windows up to Win8 (32- and 64-bit).

Training
There are still seats available for the 9-10 April offering of Timeline Analysis at our Reston location, as well as for the Windows Forensic and Registry Analysis course combo to be held at the Santa Cruz PD training facility.  If you're interested in any of these courses, but cannot make it to the Reston location, contact us about sponsoring the training at your location.

Being socked in by the weather, I thought it would be a good time to throw a couple of things out there...

Mounting an Image
Folks...in order to test or make use of the Forensic Scanner, you first need to have an image.  If you don't have an image available, you can download sample images from a number of locations online.  Or you can image your own system, or you can use virtual machine files (FTK Imager will mount a .vmdk file with no issues).  However, the Forensic Scanner was not intended to be run against your local, live system.

Once you have an image to work with, you need to mount it as a volume in order to run the Forensic Scanner against it.  If you have a raw/dd image, a .vmdk or .vhd file, or a .E0x file, FTK Imager will allow you to mount any of these in read-only format.

If you have a raw/dd format image file, you can use vhdtool to add a footer to the file, and then use the Disk Manager to attach the VHD file read-only.  If you use this method, or if you mount your image file as VMWare virtual machine, you will also be able to list and mount available VSCs from within the image, and you can run the Scanner against each of those.

If you have any version of F-Response, you can mount a remote system as a volume, and run the Forensic Scanner against it.  Don't take my word for it...see what Matt, the founder of F-Response, says about that!

If you have issues with accessing the contents of the mounted image...Ken Johnson recently tried to access a mounted image of a Windows 8 system from a Windows 7 analysis system...you may run into issues with permissions.  After all, you're not accessing the  image as a logical volume...so, you might try mounting the image as "File System/Read-Only", rather than the default "Block Device/Read-Only", or you may want to run the Scanner using something like RunAsSystem in order to elevate your privileges.

If your circumstances require it, you can even use FTK Imager (FTK Imager Lite v3.x is now available and supports image mounting) to access an acquired image, and then use the export function to export copies of all of the folders and files from the image to a folder on your analysis system, or on a USB external drive, and then run the scanner against that target.

Okay, but what about stuff other than Windows as your target?  Say that you have an iDevice (or an image acquired from one...)...the Forensic Scanner can be updated (it's not part of the current download, folks) to work with these images, courtesy of HFSExplorer.  Caveat: I haven't tested this yet, but from the very beginning, the Forensic Scanner was designed to be extensible in this manner.

Again, if you opt to run the Forensic Scanner against your local drive (by typing "C:\Windows\system32" into the tool), that's fine.  However, I can tell you it's not going to work, so please don't email me telling me that it didn't work.  ;-)

Forensic Scanner Links
Forensic Scanner Links - links where the Forensic Scanner is mentioned:
F-Response Blog: F-Response and the ASI Forensic Scanner
Grand Stream Dreams: Piles o' Linkage
SANS Forensics Blog: MiniFlame, Open Source Forensics Edition

Apparently, Kiran Vangaveti likes to post stuff that other people write...oh, well, I guess that imitation really is the sincerest form of flattery!  ;-)

Observables
The good folks over at RSA have had some interesting posts of late to their "Speaking of Security" blog, and the most recent one by Branden Williams is no exception.  In the post, Branden mentions "observables", as well as Locard's Exchange Principle...but what isn't explicitly stated is the power of correlating various events in order to develop situational awareness and context, something that we can do with timeline analysis.

An example of this might be a failed login attempt or a file modification.  In and of themselves, these individual events tell us something, but very little.  If we compile a timeline using the data sources that we have available, we can begin to see much more with regards to that individual event, and we go from, "...well, it might/could be..." to "...this is what happened."

SANS Forensic Summit 2013
The next SANS #DFIR Summit is scheduled for July 2013 (in Austin, TX) and the call for speakers is now open.

Prefetch Analysis
Adam posted recently regarding Prefetch file names and UNC paths, and that reminded me of my previous posts regarding Prefetch Analysis.  The code I currently use for parsing Prefetch files includes parsing of paths that include "temp" anywhere in the path (via grep()), and provides those paths separately at the end of the output (if found).  Parsing of UNC paths (any path that begins with two back slashes, or begins with "\Device") can also be included in that code.  The idea is to let the computer extract and present those items that might be of particular interest, so that the analyst doesn't have to dig through multiple lines of code.

Windows 8 Forensics Guide
You can now find a free Windows 8 forensics guide over on the Propeller Head Forensics blog.  Amanda's guide is a great way to get started learning about some of the new things that you're likely to see in Windows 8 (if you aren't already running the Consumer Review edition)

I had an opportunity to meet and listen to Christopher Ard of MS talk about some of the neat new features of Windows 8 recently at the Massachusetts Attorney General's Cyber Crime Conference.  I also sat in on Chris Brown's presentation on ProDiscover, and he stated that he's working on adding support for the new ReFS file system to ProDiscover.  Looks like there are lots of cool things on the horizon with Windows 8 forensic analysis.

Timelines
The Sploited blog has posted part 2 (part 1 is here) of the Forensic Timelines for Beginners series, in which they discuss creating timelines using the tools and techniques illustrated in chapter 7 of Windows Forensic Analysis Toolkit 3/e. 

File System Behavior
There's an interesting thread over on the Win4n6 Yahoo Group regarding file system behavior when files are deleted, including removed from the Recycle Bin.  During the thread, one of members made the statement that during some vendor training, they'd been told that when files are deleted, Windows will automatically securely wipe the files.  This is, in fact, not the case, as Troy Larson clearly states during the thread.

What this does being up, as Troy says later in the thread, is that Windows systems are extremely active under the hood.  During the thread, several members say that they did their own testing and found that files were not securely deleted...what this comes back to is that some files may be very quickly overwritten by normal system activity.  This is something that I've pointed out in my books and presentations for some time, particularly when talking about the need for immediate response.  Troy even mentions in a follow-up post that "just opening and editing a Word file creates several temporary and scratch files--more than you would image."  Even with no specific user interaction, Windows systems have a great deal of activity that go on behind the scenes...look at some of the performance enhancements for XP described here, and in particular in the "Prefetch" section.  Windows 7 is very similar, in that it ships with a Scheduled Task that performs a defrag once a week, and another that backups up the main Registry hives every 10 days.  Add to that all of the other activity that occurs on Windows systems, and it's not surprising that some folks are seeing, on an inconsistent basis, that Windows appears to be securely wiping files upon deletion.  This is very important for DF analysts to keep in mind while performing analysis and file or record carving, but also for incident responders to keep in mind, particularly when developing IR procedures...the more immediate the response, the fresher and more pristine data you will be able to preserve.

Resources
MS File System Behavior Overview

SQLite WAL Files
The DigitalInvestigation blog has an excellent post on SQLite Write Ahead Log files, and their potential as a forensic resource.  I've seen these, as well, in the course of forensic impact analysis, and this is a very good read for folks who want to get a little bit familiar with what these files are all about, and how they can be useful during an examination.

Scripting
Melissa's got a very good post up that demonstrates how useful scripting skills (or "skillz") can be.  Over the years that I've done infosec work, I've found that an ability to write scripts has been invaluable, and I've found that to be even more true in the DFIR realm.  I once held an FTE position where I wrote a Perl script that would reach out across the enterprise, locate all systems that were turned on, query certain Registry keys and return the results to me.  As I began investigating my findings, I was able to develop a white list, and within relatively short order got to the point where I could launch the script before lunch, and return to find a report that was about half a page in length. 
I was able to provide a viable solution that worked extremely well in my environment (rather than fitting the problem to a commercial tool), for free.

If you're interested in trying out some of the things she demonstrates on your Windows box, check out the Resources section below.

Resources
Unix Command Line Tools for Windows
Utilities and SDK from MS
Unix Utilities

Encryption
Encryption has long been a thorn in the side for examiners.   I've had a number of engagements where I was asked to acquire images of systems known to be encrypted, and more than a few where we found out after we got on-site that some of the systems employed whole disk encryption.  In those cases, we opted for a live acquisition via FTK Imager (fully documented, of course).  It appears that Jesse has found found a free program that can reportedly decrypt BitLocker-protected volumes.

PE Files
If you do PE analysis, check out the CorkAmi Google Code site.  There's a good deal of very good information there, as well as detailed information regarding the PE file format.

Locard's
I don't often read the Security Ripcord blog, but when I do, it's because there's something interesting there to read.  See what I did there?  That opening line was just a sneaky way to work a graphic into this post.  Seriously...I do read Don's blog...just not his tweets.  Okay, okay, I'm kidding.  Anyway, check out Don's post...as I read through it, the third paragraph really jumped out at me as a fantastic example of Locard's Exchange Principle, applied to the digital realm. Specifically:

It is also logical to conclude that their activities generated system and network-based artifacts that outlined their activity, even if that activity mimicked normal and authorized operational activity. Understanding these system and network-based artifacts is an important step to preventing and detecting attempts to infiltrate a network.

Now, I added my own emphasis to the above quote, but Don makes an excellent point.  When an intruder interacts with your infrastructure, there's going to be digital material exchanged between their system, and the nodes on your infrastructure with which they're interacting.  Also, the intruder is going to leave digital detritus on your infrastructure...in some cases, it may be extremely transient or volatile, and in other cases it may look very similar to legitimate traffic or activity.  However, Don's point is extremely well-taken...you need to understand these artifacts so that you can

IntoTheBoxes
Speaking of Don, he recently tweeted that he's interested in bringing the ITB back.  When Don was producing this (two issues), it was a very good e-zine, as articles were contributed by folks from the DFIR field.  It's one thing to have a list of links with no commentary or insight, but it's completely different...and I think, highly beneficial...to have something contributed by folks from the field who are not only doing the work, but doing some of the primary research, as well.

If you'd like to contribute to the ITB, take a look at the ITB WordPress site, maybe take a look at the previous editions, and contact Don at @cutaway on Twitter.

Artifacts and Presentations
While we're on the topic of artifacts...I've attended several conferences over the years that include presentation titles that refer to network or system artifacts for various incidents (intrusions, APT, etc.).  As of yet, I have yet to see a single presentation that actually gives those artifacts.  I attended a presentation not long ago, the title of which referred to intrusion artifacts found in the Windows Registry; however, the presentation including nothing more than a bunch of "look here..." references, with no real explanations as to why an analyst would look at those keys or values.  Several of the referenced Registry keys or values were dependent upon the intruder having shell-based access to your systems, such as via RDP or VNC (yes, this does happen), but that isn't something that was really discussed during the presentation.

In general, the artifacts left during an intrusion are heavily dependent upon how the intrusion occurred.  For example, I have seen incidents where an employee's home system was compromised, and their remote access (RDP) credentials "stolen" via a keylogger.  The intruder logged in via RDP, activated a dormant domain admin account, and began hopping to systems across the enterprise.  We were able to track the activity via Registry analysis...the Remote Desktop client on Windows XP maintains an MRU list of systems connected to in the Registry (on Windows 7, the MRU is in the Jump Lists).

Now, if the intruder is able to gain access to a system on your infrastructure (via an infected document in an email attachment, or a link to a malicious site in an email), and ultimately gain access to the system and run commands via the command line, most normal systems may have very limited capability (i.e., lack of sufficient Event Logging, etc.) for detecting this sort of activity.  In these cases, you'd likely be looking for secondary or indirect artifacts (this term is discussed in chapter 1 of Windows Forensic Analysis 3/e).

GSR
As most folks on Twitter are aware, the TrustWave Global Security Report is out...and just looking at page 6, it's a very interesting read.  Page 6 addresses the issue of detection, and states that 84% of the organizations included in the report relied (or depended) on external third party reporting in order to identify compromises to their infrastructure.  That number is actually up slightly from the previous year...the report speculates that this maybe a resource issue...I would also consider that it may include a lack of understanding of threats.

Further, from reading through the information presented in the report, I can see a huge opportunity for IOCs.  For example, simply looking at the packers used (pg 17), it should be easy to create a series of indicators that folks can look for with respect to these artifacts.  The same is true with respect to the Aggregation section of the report (pg 9)...there is some pretty significant potential for IOCs in just that one paragraph.

Thoughts on Report Stats and Revelations
Following right along with the TrustWave GSR report, I ran across Wendy's blog post (via Twitter and LinkedIn) that shines some light on some of the realities behind these reports.  When reading these reports, we need to keep in mind who the customers of the organization are...the TrustWave guys do a LOT of PCI forensic work, and some of that is done for smaller organizations.  Wendy makes it clear in her post what some of the folks who get compromised are thinking and why they don't appear to have any idea of how to do security. 

Another area that isn't covered as much in Wendy's post are the larger infrastructures that get compromised...those that may not have security that's much better than a mom-and-pop shop, simply because they are so big.  In such organizations, change is most often glacial, and can be mired down by cultural and political issues within the infrastructure.  A misconception about a lot of large organizations, including the federal government, is that they have the resources to throw at the information security problem...this simply isn't the case.  Years ago, I supported a federal agency that had two DF analysts for the entire (global) organization.

Okay...but so what?  Like Wendy said, don't let the statistics bother you, particularly if you're a security pro, because getting upset about it isn't going to change anything.  As long as people are looking for the easiest way to achieve a "good enough" solution, there's going to be someone right there to take advantage of that, regardless of the technology used.

Case Studies
As I've worked to develop my writing style (for my books) over the years, one of the things that I've noticed is that folks in this community love case studies.  I've also noticed that as much as folks ask for case studies, very few are willing to offer up case studies of their own.  One of the forums recently had a discussion thread that involved posted case studies, and the forum admin started a different thread to gauge the interest in such things.  Unfortunately, that thread didn't really go anywhere.

I'd like to encourage DFIR folks to consider either sharing case studies, or sharing and engaging in discussion regarding what they'd like to see.  I know that some folks can't share their actual case findings (even if customer references are redacted or simply not mentioned) due to the nature of where they work...sadly, many can't even state where their primary source of evidence was found.  However, for those who can't share those things, one of the things you may be able to share is requests such as, "...where would I look for...", or "...on Windows 7, what data sources would I look to in order to determine...".

Another example of sharing can be seen at Corey's blog...many of Corey's posts regarding exploit artifacts are very detailed, but are not specific to a case; rather, he's posted information about his research, which in turn is highly beneficial.

Tools
USB Write Protect is a nifty little GUI utility you can use to enable write protection on USB devices on your Windows systems.  Even though this is software-based write-protection and should not replace a hardware write-blocker, having the ability to

Speaking of USB devices, check out Mark Woan's USBDeviceForensics utility.  You can use this utility to import or point to the Software, System, and NTUSER.DAT Registry hives (found in mounted images, or extracted from an acquired image), collect a lot of the information available in Rob Lee's USB Analysis profiles, and even some additional information not specifically listed in the profiles.

David Hull posted recently regarding innovative approach to "finding evil"; using several tools and a bash script, he hashes what's found via AutoRuns and submits the hashes to VirusTotal.  What I like about this is that David has clearly identified/defined the issue he was facing, and then developed an innovative solution to the issue. Many times I've talked to analysts who talk about "doing Registry analysis" without any clear understanding of what they're looking for, and not know if what they're looking for is even in the Registry.  David has clearly decided that he wants to use automation to achieve a modicum of data reduction...of all of the data he has access to, his approach is, "just show me the bad stuff."

For anyone who's been watching, Corey's posted quite a bit on ripping VSCs, providing a lot of great information about not just what artifacts are available on a system, but what you can find in the VSCs on a Vista+ system, and how to get at those artifacts.  Corey's taken a big step forward with this, tying free and open source tools together via batch files to make this data collection much more automated, and now Jason's thrown his hat in the ring by creating the VSC Toolset, a GUI interface for these tools.  This is all very cool stuff and provides a capability that isn't necessarily available via some of the commercial products.


There was an excellent post from Christiaan Beek recently regarding using Volatility to analyze a hibernation file...check it out.  Christiaan gives a step-by-step walk-through on how to analyze a hibernation file...something that should be strongly considered (and a skill that should be developed), particularly when the situation and goals of your exam warrant it.

This is a little off-topic, but if you're analyzing Android phones, you might want to check out Open Source Android Forensics.  This is a bit more of an open source link than it is a Windows forensics link, but consider it in the context of DFwOST.

Often we run across interesting posts or articles on the Internet, and this leads us to other sites that interest us and may often be applicable to the work that we do.  As such, blogging provides better approach to presenting and sharing this information, and the thoughts that are generated, because we not only have the site itself (as with a bookmark), but we can also include why we found it interesting, or some additional, supporting commentary to make the information a bit more useful and relevant.

Registry Artifacts
Andreas Schuster recently stood up a Scoop.It site for DFIR topics, and from that, I found this post at Pragmatic Forensics.  The title of the post is somewhat off with respect to the actual content, but the content itself is interesting.  In short, an analyst created a timeline and ran across an IRL example of the use of the Image File Execution Options Registry key as a persistence mechanism.

This key is addressed starting on page 133 of Windows Registry Forensics, and the RegRipper imagefile.pl plugin.

Along the same lines, I recently read this Cheeky4n6Monkey blog post, which discusses using SIFT tools to perform a diff of Registry hives.  The example provided in the post is excellent, and can be easily translated for use in analyzing hives on a Windows 7 system, particularly when you want to know what changed following a VSC being created, or between VSCs.

Writing
Like many folks, I wasn't a big fan of writing.  I know that's hard to believe...but the fact is that I didn't like to write.  I wasn't good at it, and it was always a chore.  Even when I did put effort into what I was writing, the results were often not what I'd hoped.

Over time, however, I was in positions and situations where I had to write.  While I was in the military, there were JAG Manual investigations, fitreps, awards, log entries, etc.  I had to write during my graduate program.  When I got out of the military, and moved to private industry, I had analysis plans and reports to write.

Perhaps the most succinct description of why we (DFIR analysts) should write is  encapsulated in the 7 Real Ways Writing Increases Expertise blog post.  Take a look at the points mentioned...I think what's really powerful about this is that writing does allow us to clarify our thoughts, and you have to admit, you don't HAVE to hit the Send button until you're satisfied.

Self-Inflicted Artifacts
Over 6 years ago, I wrote a blog post regarding the MUICache key.  At the time, I was wondering why I was seeing a reference to malware creating this key in AV vendor write-ups.

This System Forensics blog post provides an excellent example of self-inflicted artifacts.  The post as a whole is an excellent resource for using Volatility in malware analysis, but very early on in the post, the author mentions a value being added to the MUICache key, as well as UserAssist subkey entries being created.  These are self-inflicted artifacts, and a result of how the malware was executed for testing (i.e., place it on the Desktop, and double-click).

Okay...so why does any of this matter?  I came across the following Registry key:

HKLM\SOFTWARE\Microsoft\RFC1156Agent\CurrentVersion\Parameters

"MiB".  Get it?

According to the timeline I'd created, the key had been modified during a specific time period that was potentially of interest.  When I checked the key, it had a single value named "TrapPollTimeMilliSecs".  I am familiar with SNMP, so I know about traps and MiBs (per RFC1156), but I ran a Google search for the value name, I got a number of hits associated with malware.  In fact, I found one AV write-up that indicated that this was the only artifact associated with the malware.  Ultimately, the analysis did not reveal indications of malware on the system (included scans with multiple AV scanners).

None of the sites I found could provide a clue as to how the value in question is used by malware.  Many of the write-ups I found stated that the value (and it's data) were created by the malware, and my timeline indicated that the key had been modified at a certain time, which could mean that the value was created...or it could mean something else.  And no, I don't have a sample of the malware to analyze.

Overall, I'm beginning to think that the value is a "self-inflicted" artifact, and that the same might be true for some other artifacts that I've observed.

Shoutz to Cory Altheide for using "self-inflicted" in a sentence, and allowing me to bogart the term.

Vulture Research
I was reading this news article recently (yes, I admit it, I'm a closet CSI fan), and it got me to thinking...how often do we, as analysts, misinterpret what we have in front of us?  How often do we draw conclusions based on the data that we have, given the possibility that the data is incomplete?

So...in case you didn't want to read the article I linked to, it's about research that was conducted with respect to scavenger predation of bodies, and how it can affect homicide investigations.  If you watch the crime shows (CSI, NCIS, Bones, etc.), you can probably recount episodes in which a skeleton was found in the open and the conclusion was drawn that the body had been there for months.  Well, this new research indicates that vultures can denude all flesh from a body in a couple of hours...and this can have a significant impact on the assumptions made about the timeline of the crime.

So, this got me to thinking...how often does this happen with what we do?  This "new" research with respect to the vultures is simply something that's been happening for a while, but investigators perhaps haven't considered it.  After all, these birds come down and feed for a few hours, you'd think that there'd be some sort of evidence of this...tracks, feathers, etc.  But what if these artifacts were not noted or simply ignored, or obscured by weather?

Now, consider digital analysis.  Who has received a Windows 7 system to analyze in the past year (or more) and their investigation involved tracking user activity?  When you examined the system, did you include Jump Lists in your analysis?  Registry artifacts?  If you had to track USB devices connected to the system, did you include the EMDMgmt Registry key in that analysis? 

Also, consider Corey Harrell's recent post on Jump Lists; even though he's worked backwards in our usual sequence (starting with a known task first...), he's shown what's possible on systems, and allows other analysts to connect the dots and fill in some gaps.  If you'd looked at a Windows 7 system recently and had to determine authorship of a document, did you consider something along the lines of what Corey pointed out?  Did you collect metadata from the document itself?

How often have we made and reported conclusions based on incomplete analysis, and how often have we used assumptions to fill in the gaps?

One of the ways to overcome this is to use checklists for certain types of data collection, particularly those that are complicated and repetitive.  Notice I don't say "analysis"...that's because data gets collected, and then someone analyzes it; a checklist provides the ability to duplicate the data collection phase, and provides that data for analysis.  The key to this is that a documented process can be updated and modified...you can't evaluate or replicate something that you don't have written down.  Examples of where you might use a checklist include (but are not limited to) USB device analysis, malware detection, authorship of or access to documents, etc.

As  a side note, I've taken some time recently update my malware detection checklist, offline, including some input from some of the recent and excellent malware analysis books that have been published.

Registry Parsing
Andrew Case, developer of Registry Decoder, recently posted regarding using reglookup for Registry analysis.  There are a number of links in Andrew's post to some of Tim Morgan's papers regarding such topics as looking for deleted Registry keys, so be sure to take a look.

PFIC 2011
I had an opportunity to meet a lot of great folks in Park City, many of whom I had only known about via their online presence.  One of those is fellow DFIR'er and fellow former Marine Corey Harrell. Corey's one of those impressive folks that you want to reach to and find in the community; rather than just sitting quietly, or just clicking "+1" or "Like", Corey goes out and does stuff, a good deal of which he's posted to his blog.

Corey posted his PFIC 2011 Review to his blog recently (Girl, Unallocated posted her thoughts and experiences, as well)...this is great stuff, for a couple of reasons.  First, some conferences, like PFIC, have a number of good topics and speakers, often during the same time slot.  As such, you may not be able to get to all of the presentations that you'd like to, and having someone post their "take-aways" from the presentation you missed is a good way to get a bit of insight beyond simply downloading the slide pack.  Taking that a step further, not everyone can attend conferences, so this gives folks who couldn't attend an opportunity to peek behind the curtain and see what's going on.  Finally, this gets the word out about next year's conference, as well, and may get someone over the hump of whether to attend or not.

DoD CyberCrime
Speaking of presentations, I got word recently that my DoD CyberCrime Conference presentation on timeline analysis on 25 Jan 2012, from 8:30-10:20am.  The last (and first) time I attended DC3 was in 2007, and unfortunately, within less than an hour of finishing my presentation, I was on an incident call, and off the next day to another major city.  Ah...such was the life of an emergency responder.

My timeline analysis presentation (an example of a previous presentation can be found here) is a bit different from most of those that I find available online, in part because I don't focus on using the SANS SIFT Workstation.  That's not to say that SIFT isn't a great resource...because it is.  Rob's done a great job of assembling a range of open source tools, and getting them all set up and ready to use.  However, the approach I tend to take is to start by attempting to engage the audience and discussing with them the reasons why we'd want to do timeline analysis in the first place, discussing concepts such as context and increased relative confidence in the data.  Understanding these concepts can often be what gets folks to see the value of creating a timeline, when "...because this guy said so..." just isn't enough.  From there, we walk through using the tools, and demonstrate how timelines can be used as part of your analysis process...keeping in mind that like any other tool, this is just a tool and needs to be used accordingly.  Creating a timeline when it doesn't make sense to do simply...well...doesn't make sense.

Anyway, I'm really looking forward to this opportunity, and hopefully seeing a bunch of really good presentations, as well.  Looking at the conference agenda as it is so far, it looks like there's a couple of good social events, as well, which will lead to some great networking.

MMPC Updates
The Microsoft Malware Protection Center (MMPC) recently posted regarding some new MSRT definitions, including Win32/Cridex, another bit of malware that steals online banking credentials.  Cridex uses the user's Run key for persistence, and apparently stores data in the Default value of the HKCU\Software\Microsoft\Windows Media Center\ key.  Figure 3 of the MMPC post includes a screen capture of what this data looks like.

Duqu
Although I haven't had an opportunity to analyze a system infected with Duqu, as always, I remain interested in what's out there, particularly from a host-based perspective.  I ran across a set of open source tools for detecting Duqu files (readme here).  There's also the Symantec write-up on Duqu, which is very interesting, as it defines the Duqu "load point", which is a driver loaded as a Windows service, specifically HKLM\SYSTEM\CurrentControlSet\Services\JmiNET3.  Apparently, configuration information is maintained in the FILTER subkey beneath this key.

Interestingly, the load point is described as "JmiNET7.sys", but the Symantec paper goes on to say that the service name is "JmiNET3".

The Symantec paper goes on to describe the loading techniques for the payload loader, and method 3 involves a section within a DLL called ".zdata".

Finally, the Diagnostics section of the paper includes another Registry key that is supposed to indicate an infected system; specifically, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\”CFID”.

Anyone interested in learning more about Duqu should take a look at the Symantec paper, as well as anything else that's out there.  There seem to be some interesting (and possibly unique) indicators that you can use to scan your infrastructure for infected systems; per the Symantec paper, part of the Duqu threat involves infostealers.

Tool Updates
There've been some updates to the SysInternals tools recently, in particular to AutoRuns (new v 11.1), including some new autostart locations.  Check them out.

Andreas has updated his Evtx Parser tool (written in Perl), as well.

ImDisk was recently updated to version 1.5.2.

I updated my maclookup.pl WiFi geolocation script to macl.pl.   The previous version of the script used Skyhook to perform lookups, in an attempt to translate a WiFi WAP MAC address (found in the Windows Registry) to a lat/long pair.  I found out recently that this stopped working, so I sought out...and found...a way to update the script.

Reading
The e-Evidence.info what's new site was updated recently, and as always, there's lots of great reading material.  This presentation on using open source tools for digital forensic analysis spends a good couple of slides demonstrating how to use RegRipper.  David Hull has a timeline presentation available that discusses the use of SIFT v2.0 to create super timelines.

Not long ago, I started a FOSS page for my blog, so I didn't have to keep going back and searching for various tools...if I find something valuable, I'll simply post it to this page and I won't have to keep looking for it.  You'll notice that I really don't have much in the way of descriptions posted yet, but that will come, and hopefully others will find it useful.  That doesn't mean the page is stagnant...not at all.  I'll be updating the page as time goes on.

Volatility
Melissa Augustine recently posted that she'd set up Volatility 2.0 on Windows, using this installation guide, and using the EXE for Distorm3 instead of the ZIP file.  Take a look, and as Melissa says, be sure to thoroughly read and follow the instructions for installing various plugins.  Thanks to Jamie Levy for providing such clear guidance/instructions, as I really think that doing so lowers the "cost of entry" for such a valuable tool.  Remember..."there're more things in heaven and earth than are dreamt of in your philosophy."  That is, performing memory analysis is a valuable skill to have, particularly when you have access to a memory dump, or to a live system from which you can dump memory.  Volatility also works with hibernation files, from whence considerable information can be drawn, as well.

WDE
Now and again, you may run across whole disk encryption, or encrypted volumes on a system.  I've seen these types of systems before...in some cases, the customer has simply asked for an image (knowing that the disk is encrypted) and in others, the only recourse we have to acquire a usable image for analysis is to log into the system as an Admin and perform a live acquisition.

TCHunt
ZeroView from Technology Pathways, to detect WDE (scroll down on the linked page)

You can also determine if the system had been used to access TrueCrypt or PGP volumes by checking the MountedDevices key in the Registry (this is something that I've covered in my books).  You can use the RegRipper mountdev.pl plugin to collect/display this information, either from a System hive extracted from a system, or from a live system that you've accessed via F-Response.

Timelines
David Hull gave a presentation on "Atemporal timeline analysis" at the recent SecTorCA conference (can find the presentation .wmv files here), and posted an abridged version of the presentation to the SANS Forensic blog (blog post here).

When I saw the title, the first thing I thought was...what?  How do you talk about something independent of time in a presentation on timeline analysis?  Well, even David mentions at the beginning of the recorded presentation that it's akin to "asexual sexual reproduction"...so, the title is meant to be an oxymoron.  In short, what the title seems to refer to is performing timeline analysis during an incident when you don't have any sort of time reference from which to start your analysis.  This is sometimes the case...I've performed a number of exams having very little information from which to start my analysis, but finding something associated with the incident often leads me to the timeline, providing a significant level of context to the overall incident.

In this case, David said that the goal was to "find the attacker's code".  Overall, the recorded presentation is a very good example of how to perform analysis using fls and timelines based solely on file system metadata, and using tools such as grep() to manipulate (as David mentions, "pivot on") the data.  In short, the SANS blog post doesn't really address the use of "atemporal" within the context of the timeline...you really need to watch the recorded presentation to see how that term applies.

Sniper Forensics
Also, be sure to check out Chris Pogue's "Sniper Forensics v3.0: Hunt" presentation, which is also available for download via the same page.  There are a number of other presentations that would be very good to watch, as well...some talk about memory analysis.  The latest iteration of Chris's "Sniper Forensics" presentations (Chris is getting a lot of mileage from these things...) makes a very important point regarding analysis...in a lot of a cases, an artifact appears to be relevant to a case based on the analyst's experience.  A lot of analysts find "interesting" artifacts, but many of these artifacts don't relate directly to the goals of their analysis.  Chris gives some good examples of an "expert eye"; in one slide, he shows an animal track.  Most folks might not even really care about that track, but to a hunter, or someone like me (ride horses in a national park), the track tells me a great deal about what I can expect to see.

This applies directly to "Sniper Forensics"; all snipers are trained in observation.  Military snipers are trained to quickly identify military objects, and to look for things that are "different".  For example, snipers will be sent to observe a route of travel, and will recognize freshly turned earth or a pile of trash on that route when the sun comes up the next day...this might indicate an attempt to hide an explosive device.

How does this apply to digital forensic analysis?  Well, if you think about it, it is very applicable.  For example, let's say that you happen to notice that a DLL was modified on a system.  This may stand out as odd, in part because it's not something that you've seen a great deal of...so you create a timeline for analysis, and see that there wasn't a system or application update at that time. 

Much like a sniper, a digital forensic analyst must be focused.  A sniper observes an area in order to gain intelligence...enemy troop movements, civilian traffic through the area, etc.  Is the sniper concerned with the relative airspeed of an unladen swallow?  While that artifact may be "interesting", it's not pertinent to the sniper's goals.  The same holds true with the digital forensic analyst...you may find something "interesting" but how does that apply to your goals, or should you get your scope back on the target?

Data Breach 'Best Practices'
I ran across this article recently on the GovernmentHealthIT site, and while it talks about breach response best practices, I'd strongly suggest that all four of these steps need to be performed before a breach occurs.  After all, while the article specifies PII/PHI, regulatory and compliance organizations for those and other types of data (PCI) specifically state the need for an incident response plan (PCI DSS para 12.9 is just one example).

Item 1 is taking an inventory...I tell folks all the time that when I've done IR work, one of the first things I ask is, where is your critical data.  Most folks don't know.  A few that have have also claimed (incorrectly) that it was encrypted at rest.  I've only been to one site where the location of sensitive data was known and documented prior to a breach, and that information not only helped our response analysis immensely, it also reduced the overall cost of the response (in fines, notification costs, etc.) for the customer.

While I agree with the sentiment of item 4 in the article (look at the breach as an opportunity), I do not agree with the rest of that item; i.e., "the opportunity to find all the vulnerabilities in an organization—and find the resources for fixing them." 

Media Stuff
Brian Krebs has long followed and written on the topic of cybercrime, and one of his recent posts is no exception.  I had a number of take-aways from this post that may not be intuitively obvious:

1.  "Password-stealing banking Trojans" is ambiguous, and could be any of a number of variants.  The "Zeus" (aka, Zbot) Trojan  is mentioned later in the post, but there's no information presented to indicate that this was, in fact, a result of that specific malware.  Anyone who's done this kind of work for a while is aware that there are a number of malware variants that can be used to collect online banking credentials.

2.  Look at the victims mentioned in Brian's post...none of them is a big corporate entity.  Apparently, the bad guys are aware that smaller targets are less likely to have detection and response capabilities (*cough*CarbonBlack*cough*).  This, in turn, leads directly to #3...

3.  Nothing in the post indicates that a digital forensics investigation was done of systems at the victim location.  With no data preserved, no actual analysis was performed to identify the specific malware, and there's nothing on which law enforcement can build a case.

Finally, while the post doesn't specifically mention the use of Zeus at the beginning, it does end with a graphic showing detection rates of new variants of the Zeus Trojan over the previous 60 days; the average detection rate is below 40%.  While the graphic is informative,

More Media Stuff
I read this article recently from InformationWeek that relates to the recent breach of NASDAQ systems; I specifically say "relates" to the breach, as the article specifies, "...two experts with knowledge of Nasdaq OMX Group's internal investigation said that while attackers hadn't directly attacked trading servers...".  The title of the article includes the words "3 Expected Findings", and the article is pretty much just speculation about what happened, from the get-go.  In fact, the article goes on to say, "...based on recent news reports, as well as likely attack scenarios, we'll likely see these three findings:".  That's a lot of "likely" in one sentence, and this much speculation is never a good thing.  


My concern with this is that the overall take-away from this is going to be "NASDAQ trading systems were hit with SQL injection", and folks are going to be looking for this sort of thing...and some will find it.  But others will miss what's really happening while they're looking in the wrong direction.

Other Items
F-Response TACTICAL Examiner for Linux now has a GUI
Lance Mueller has closed his blog; old posts will remain, but no new content will be posted

Malware
Evild3ad has an excellent writeup of the Federal (aka, R2D2) Trojan via memory analysis using Volatility.  The blog post gives a detailed walk-through of the analysis conducted, as well as the findings.  Overall, my three big take-aways:

1.  An excellent example of how to use Volatility to conduct memory analysis.
2.  An excellent example of case notes.
3.  Detailed information that can be used to create a plugin for either RegRipper, or a forensic scanner.

There is also a link to a Rar archive containing the memory image at the site, so you can download it and try running the commands listed in the blog post against the same data.

M-Trends
The Mandiant M-Trends 2011 report is available...I received a copy yesterday and started looking through it.  Very interesting information in the report...as a host-based analysis guy, I found some of the information on persistence mechanisms (starting on pg 11 of the report) to be very interesting.  Some may look at the use of Windows Services and the ubiquitous Run key as passe, but the fact is that these persistence mechanisms work.  After all, when the threat actors compromise an infrastructure, they are not trying to remain hidden from knowledgeable and experienced incident responders.

Interestingly, the report includes a side note that the authors expect to see more DLL Search Order Hijacking used as a persistence mechanism in the future.  I tend to agree with the statement in the report, given that (again, as stated in the report) that this is an effective technique that is difficult to detect.

Another interesting persistence mechanism described in the report was services.exe being modified (without changing the size of the binary) to point to an additional (and malicious) DLL.  This technique has been seen being used with other binaries, including other DLLs. 

A major section (section III) of the report discusses visibility across the enterprise; I think that this is an extremely important issue.  As I've performed incident response over the years, a common factor across most (if not all) of the incidents I've responded to has been a lack of any infrastructure visibility whatsoever.  This has been true not only for initial visibility into what goes on on the network and hosts, but it has also affected response capabilities.  Network- and host-based visibility of some kind needs to be achieved by all organizations, regardless of size, etc.  I mean, think about it...any organization that produces something has some sort of visibility into processes that are critical to the business, right?  A company that manufactures widgets has controls in place to ensure that the widgets are produced correctly, and that they're shipped...right?  I mean, wouldn't someone notice if trucks weren't leaving the loading docks?  So why not have some sort of visibility into the medium where your critical information assets are stored and processed?

Looking at the information provided in the M-Trends report (as well as other reports available from other organizations), I can see the beginning an argument for incident preparation being built up; that is to say that while the report may not specifically highlight this (the M-Trends report mentions the need for "...developing effective threat detection and response capabilities..."), it's clear that the need for incident preparation has existed for some time, and will continue to be an issue.

Addendum: Pg 13 of the M-Trends report mentions some "interesting" persistence mechanisms being used, one of which is "use of COM objects"; however, the rest of the report doesn't provide much of a description of this mechanism.  Well, I ran across this post on the ACROS Security Blog that provides some very good insight into using COM objects for persistence.  Both attacks described are something of a combination of the use of COM objects and the DLL Search Order hijacking, and very interesting.  As such, there needs to be tools, processes, and education of analysts in these techniques so that they can be recognized or at least discovered through analysis.  I would suggest that these techniques have been used for some time...it's simply that most of us may not have known to (or "how to") look for them.

Resources
Verizon DBIR
TrustWave GSR

Incident Preparation
I recently gave a talk on incident preparation at ETCSS, and overall, I think it was well received.  I used a couple of examples to get my point across...boxing, fires in homes...and as the gears have continued to turn, I've thought of another, although it may not be as immediately applicable or understandable for a great many folks out there.

Having been a Marine, and knowing a number of manager- and director-types that come from prior military experience, I thought that the USS Cole would be a great example of incident preparation.  The USS Cole was subject to a bombing attack on 12 October 2000, and there were 56 casualties, 17 of which were fatalities.  The ship was stuck by a bomb amidships, and a massive hole was torn in her side, part of which was below the waterline.  However, the ship did not sink.

By contrast, consider the RMS Titanic.  On 15 April 1912, the Titanic struck an iceberg and shortly thereafter, sank.  According to some sources, a total of six compartments were opened to the sea; however, the design of the Titanic was for the ship to remain afloat with only the first four compartments opened to the sea.  As the weight of the water pulled the ship down, more water was allowed to flood the ship, which quickly led to her sinking.

So, what does this have to do with incident preparation and response?  Both ships were designed with incidents in mind; i.e., it was clear that the designers were aware that incidents, of some kind, would occur.  The USS Cole had some advantages; better design due to a better understanding of threats and risk, a better damage control team, etc.  We can apply this thinking to our current approach to infrastructure design and assessments.

How would the USS Cole have fared had, at the time of the bombing, they not had damage control teams and sailors trained in medical response and ship protection?  What would have happened, do you think, if they'd instead done nothing, and gone searching for someone to call for help?

My point in all this goes right back to my presentation; who is better prepared to respond to an incident - the current IT staff on-site, who live and work in that environment every day, or a consultant who has no idea what your infrastructure looks like?

Determining Quality
Not long ago, I discussed competitive advantage and how it could be achieved, and that got me to thinking...when a deliverable is sent to a customer of DFIR services, how do they (the customer) judge or determine the quality of the work performed?

Over the years, I've had those engagements where a customer says, "this system is infected", but when asked for specifics regarding why they think it was infected, or what led them to think it was infected, most often don't have anything concrete to point to.  I'll go through, perform the work based on a malware detection checklist and very often come up with nothing.  I submit a report detailing my work activity and findings, which leads to my conclusions of "no malware found", and I simply don't hear back.

Consulting is a bit different from the work done in LE circles...many times, the work you do is going to be reviewed by someone.  The prosecution may review it, looking for information that can be used to support their argument, and the defense may review it, possibly to shoot holes in your work.  This doesn't mean that there's any reason to do the work or reporting any differently...it's simply a difference in the environments.

So, how does a customer (of consulting work) determine the quality of the work, particularly when they've just spent considerable money, only to get an answer that contradicts their original supposition?  When they receive a report, how do they know that their money has been well-spent, or that the results are valid?  For example, I use a checklist with a number of steps, but when I provide a report that states that I found no indication of malware on the system, what's the difference between that and another analyst who simply mounted the image as a volume and scanned it with an AV product?

Attacks
If you haven't yet, you should really consider checking out Corey's Linkz about Attacks post, as it provides some very good information regarding how some attacks are conducted.  Corey also provides summaries of some of the information, specifically pointing out artifacts of attacks.  Most of them are Java-based, similar to Corey's exploit artifact posts.

This post dovetails off of a comment that Corey left on one of my posts...

I've seen and hear comments from others about how it's difficult (if not impossible) and time consuming to determine how malware ended up on the system.

Very often, this seems to be the case.  The attack or initial infection vector is not determined, as it is deemed too difficult or time consuming to do so.  There are times when determining the initial infection vector may be extremely difficult, such as when the incident is months old and steps have been taken (either by the attacker or local IT admins) to clean up the indicators of compromise (IoCs).  However, I think that the work Corey has been doing (and providing the results of publicly) will go a long way toward helping analysts narrow down the initial infection vector, particular those who create detailed timelines of system activity.

Consulting
Hal Pomeranz has an excellent series of posts regarding consulting and issues that you're likely to run into and have to address if you go out on your own.  Take a look at part 1, 2, 3, and 4.  Hal's provided a lot of great insight, all of which comes from experience...which is the best teacher!  He also gives you an opportunity to learn from his mistakes, rather than your own...so if you're thinking about going this route, take a look at his posts.

Carbon Black
I recently gave a presentation at ETCSS, during which we discussed the need for incident preparedness in order to improve the effect of incident response efforts.  In that presentation, I mentioned and described Carbon Black (Cb), as well as how it can be used in other ways besides IR.

While I was traveling to the venue, Cb Enterprise was released.  Folks, if you don't know what Carbon Black is, you really should take a look at it.  If you use computers in any capacity beyond simply sitting at a keyboard at your house...if you're a dentist's office, hospital, law firm, or a national/global business...you need to take a good hard look at Cb.  Cb is a small, light-weight sensor that monitors execution on a system...remember Jesse Kornblum's Rootkit Paradox paper?  The paradox of rootkits is that they want to hide, but they must run...the same is true with any malware.  Cb monitors program execution on Windows systems.  The guys at Cb have some great examples of how they've tracked down a three-stage browser drive-by infection in minutes, where it may have taken an examiner doing just disk forensics days to locate the issue.

If you have and use computers, or you have customers who do, you should really take a hard look at Cb and consider deploying it.  Seriously...check out the site, give the Kyrus Tech guys a call, and take a good hard look at what Cb can do for you.  I honestly believe that Cb is a game changer, and the Kyrus Tech guys have demonstrated that it is, indeed, a game changer, but not just for IR work.

Timeliner
Jamie Levy has posted documentation and plugins for her OMFW talk (from last July) regarding extracting timeline data from a memory dump using the Volatility framework.  This is a great set of plugins for a great memory analysis framework, folks.  What's really cool is that with a little bit of programming effort,  you can modify the output format of the plugins to meet your needs, as well.  A greatbighuge THANKS to Jamie for providing these plugins, and for the entire Volatility team/community for a great memory analysis framework.

Exploit Artifacts
Speaking of timelines...Corey has posted yet another analysis of exploit artifacts, this one regarding a signed Java applet. This is a great project that Corey works on, and a fantastic service that he's providing.  Using available tools (i.e., MetaSploit), he compromises a system, and then uses available tools and techniques (i.e., timeline analysis) to demonstrate what the artifacts of the exploit "look like" from the perspective if disk analysis.  Corey's write-up is clear and concise, and to be honest, this is what your case notes and reports should look like...not exactly, of course, but there are lot of folks that use the "...I don't know what standard to write to..." as an excuse to not do anything.  Look at what Corey's done here...don't you think that there's enough information to replicate what he did?  Does that work as a standard?

Also, take a look at the technique Corey used for investigating this issue...rather than posting a question online, he took steps to investigate the issue himself.  Rather than starting with an acquired image and a question (as is often the case during an exam), he started with just a question, and set out to determine an answer.  Information like this can be extremely valuable, particular when it comes to determining things such as the initial infection vector of malware or a bad guy, and a good deal of what he's provided can be added to an exam checklist or a plugin for a forensic scanner.  I know that I'm going to continue to look for these artifacts...a greatbighuge THANKS to Corey, not just for doing this sort of work, but posting his results, as well.

DFF
DFF 1.2 is available for download.  Take a look at this for a list of the updates; check out batch mode.  Sorry, I don't have more to write...I just haven't had a chance to dig into it yet.

Community
One of the things I see a great deal of, whether it's browsing the lists or reading questions that appear in my inbox, is that when asking questions regarding forensic analysis, many of us still aren't providing any indication of the operating system that we're analyzing.  Whether its an application question (P2P, FrostWire, a question about MFT entries, etc.), many of us are still asking the questions without identifying the OS, and if it's Windows, the version.

Is this important at all?  I would suggest that yes, it is.  The other presentation I gave at ETCSS (see the Carbon Black entry above) was titled What's new in Windows 7: An analyst's perspective.  During this presentation, we discussed a number of differences, specifically between Windows XP and Win7, but also between Vista and Win7.  Believe it or not, the version of Windows does matter...for example, Windows 2003 and 2008 do not, by default, perform application prefetching (although they can be configured to do so).  With Windows XP, the searches a user executed from the desktop were recorded in the ACMru key; with Vista, the searches were NOT recorded in a Registry key (they were/are maintained in a file); with Windows 7, the search terms are maintained in the WordWheelQuery key.

Still not convinced?  Try analyzing a Windows 7 memory dump with Volatility, but don't use the Windows 7 profile.  

So, it you're asking a question that has to do with file access times, then the version of Windows is very important...because as of Vista, by default, updating of last access times on files is disabled.  This functionality can be controlled by a Registry value, which means that this functionality can also be disabled on Windows XP systems.

I also see a number of questions referring to various applications, many of which are specific to P2P applications.  Different applications behave differently...so saying, "I'm doing a P2P investigation" doesn't really provide much information if you're looking for assistance.  I mean, who's going to write an encyclopedic if/then loop with all of the possibilities?  Not only is the particular application important, but so is the version...for the same reasons that the OS version is important.  I've dealt with older versions of applications, and what those applications do, or are capable of doing, can be very important to an investigation...that is, unless you're planning to fill in the gaps in your investigation with speculation.

In short, if you've got a question about something, be sure to provide relevant background information regarding what you're looking at...it can go a long way toward helping someone answer that question and provide you with assistance.


Tools
I've started a new page for my blog, listing the FOSS forensic tools that I find, come across, get pointed to, and use.  It's a start...I have a good deal of catching up to do.  I've started listing the tools, and provided some descriptions...I'll be updating the tools and descriptions as time goes on.  This is mostly a place for me to post tools and frameworks so that I don't have to keep going back and searching through my blog for something, but feel free to stop by and take a look, or email me a tool that you like to use, or site with several tools.

Endorsements
One final thing...and this is for Mr. Anonymous, who likes to leave comments to some of my blog posts...I get no benefit, monetarily or otherwise, for my comments or endorsement of Volatility, nor for DFF...or any other tool (FOSS or otherwise) for that matter.  I know that in the past, you've stated that you "...want to make sure that it is done with the right intentions".  Although you've never explicitly stated what those intentions are, I just wanted to be up front and clear...I have used these tools, and I see others discovering great benefit from them, as well...as such, I think that it's a great idea to endorse them as widely as possible, so that others don't just see the web site, but also see how they can benefit from using these tools.  I hope that helps.