I realize that I've talked a bit about timeline creation and analysis, and I know that others (Chris, as well as Rob) have covered this subject, as well.

I also realize that I may have something of a different way of going about creating timelines and conducting analysis. I don't think that, out of the ways I've seen so far that there's a wrong way, I just think that we approach things a bit differently.

For example, I am not a fan of adding everything to a timeline, at least not as an initial step. I've found that IMHO, there's a lot of noise in just the file system metadata...many times, by the time I get notified of an incident, an admin has already logged into the system, installed and run some tools (including anti-virus), maybe even deleted files and accounts, etc. When interviewed about the incident and the specific question of "what actions have you performed on the system?" is asked, that admin most often says, "nothing"...only because they tend to do these things every day and they are therefore trivial. To add to that, there's all the other stuff...automatic updates to Windows or any of the applications, etc., that also adds a great deal of stuff that needs to be culled through in order to find what you're looking for. Adding a lot of raw data to the timeline right up front may mean that you're adding a lot of noise into that timeline, and not a lot of signal.

Goals
Generally, the first step I take is to look at the goals of my exam, and try to figure out which data sources may provide me the best source of data. Sometimes it's not a matter of just automatically parsing file system metadata out of an image; in a recent exam involving "recurring software failures", my initial approach was to parse just the Application Event Log to see if I could determine the date range and relative frequency of such events, in order to get an idea of when those recurring failures would have occurred. In another exam, I needed to determine the first occurrence within the Application Event Log of a particular event ID generated by the installed AV software; to do so, I created a "nano-timeline" by parsing just the Application Event Log, and running the output through the find command to get the event records I was interested in. This provided me with a frame of reference for most of the rest of my follow-on analysis.

Selecting Data Sources
Again, I often select data sources to include in a timeline by closely examining the goals of my analysis. However, I am also aware that in many instances, the initial indicator of an incident often is only the latest indicator, albeit the first to be recognized as such. That being the case, when I start to create a timeline for analysis, I generally start off by creating a file of events from the file system metadata, as well as available Event Log records, as well as running the .evt files through evtrpt.pl to get an idea of what I should expect to see from the Event Logs. I also run the auditpol.pl RegRipper plugin against the Security hive in order to see (a) what events are being logged, and (b) when the contents of that key were last modified. If this date is pertinent to the exam, I'll be sure to include an appropriate event in my events file.

Once my initial timeline has been established and analysis begins, I can go back to my image and select the appropriate data sources to add to the timeline. For example, during investigations involving SQL injection, the most useful data source is very likely going to be the web server logs...in many cases, these may provide an almost "doskey /history"-like timeline of commands. However, adding all of the web server logs to the timeline means that I'm going to end up inundating my timeline with a lot of normal and expected activity...if any of the requested pages contains images, then there will be a lot of additional, albeit uninteresting, information in the timeline. As such, I would narrow down the web log entries to those of interest, beginning with an interative analysis of the web logs, and add the resulting events to my timeline.

That's what I ended up doing, and like I said, the results were almost like running "doskey /history" on a command prompt, except I also had the time at which the commands were entered as well as the IP address from which they originated. Having them in the timeline let me line up the incoming commands with their resulting artifacts quite nicely.

Registry Data
The same holds true with Registry data. Yes, the Registry can be a veritable gold mine of information (and intelligence) that is relevant to your examination, but like a gold mine, that data must be dug out and refined. While there is a great deal of interesting and relevant data in the system hives (SAM, Security, Software, and System), the real wealth of data will often come from the user hives, particularly for examinations that involve some sort of user activity.

Chris and Rob advocate using regtime.pl to add Registry data to the timeline, and that's fine. However, it's not something I do. IMHO, adding Registry data to a timeline by listing each key by its LastWrite time is way too much noise and not nearly enough signal. Again, that's just my opinion, and doesn't mean that either one of us is doing anything wrong. Using tools like RegRipper, MiTec's Registry File Viewer, and regslack, I'm able to go into to a hive file and get the data I'm interested in. For examinations involving user activity, I may be most interested in the contents of the UserAssist\Count keys (log2timeline extracts this data, as well), but the really valuable information from these keys isn't the key LastWrite times; rather, it's the time stamps embedded in the binary value data within the subkey values.

If you're parsing any of the MRU keys, these too can vary with respect to where the really valuable data resides. In the RecentDocs key, for example, the values (as well as those within the RecentDocs subkeys) are maintained in an MRU list; therefore, the LastWrite time of the RecentDocs key is of limited value in and of itself. The LastWrite time of the RecentDocs key has context when you determine what action caused the key to be modified; was a new subkey created, or was another file opened, or was a previously-opened file opened again, modifying the MRUListEx value?

Files opened via Adobe Reader are maintained in an MRU list, as well, but with a vastly different format from what's used by Microsoft; the most recently opened document is in the AVGeneral\cRecentFiles\c1 subkey, but the name of the actual file is embedded in a binary value named tDIText. On top of that, when a new file is opened, it becomes the value in the c1 subkey, so all of the other subkeys that refer to opened documents also get modified (what was c1 becomes c2, c2 becomes c3, etc.), and the key LastWrite times are updated accordingly, all to the time that the most recent file was opened.

Browser Stuff
Speaking of user activity, let's not forget browser cache and history files, as well as Favorites and Bookmarks lists. It's very telling to see a timeline based on file system metadata with a considerable number of files being created in browser cache directories, and then to add data from the browser history files and get that contextual information regarding where those new files came from. If a system was compromised by a browser drive-by, you may be able to discover the web site that served as the initial infection vector.

Identifying Other Data Sources
There may be times when you would want to determine other data sources that may be of use to your examination. I do tend to check the contents of the Task Scheduler service log file (schedLgU.txt) for indications of scheduled tasks being run, particularly during intrusion exams; however, this log file can also be of use if you're trying to determine if the system were up and running during a specific timeframe. This may much more pertinent to laptops and desktop systems than to servers, which may not be rebooted often, but if you look in the file, you'll see messages such as:

"Task Scheduler Service"
Started at 3/21/2010 6:18:19 AM
"Task Scheduler Service"
Exited at 3/21/2010 9:10:32 PM

In this case, the system was booted around 6:16am EST on 21 March, and shut down around 9:11pm that same day. These times are listed relative to the local system time, and may need to be adjusted based on the timezone, but it does provide information regarding when the system was operating, particularly when combined with Registry data regarding the start type of the service, and can be valuable in the absence of, or when combined with, Event Log data.

There may be other data sources available, but not all of them may be of use, depending upon the goals of your examination. For example, some AV applications record scan and detection information in the Event Log as well as in their own log files. If the log file provides no indication that any malware had been identified, is it of value to include all scans (with "no threats found") in the timeline, or would it suffice to note that fact in your case notes and the report?

Summary
Adding all available data sources to a timeline can quickly make that timeline very unwieldy and difficult to manage and analyze. Through education, training, and practice, analysts can begin to understand what data and data sources would be of primary interest to an examination. Again, this all goes back to your examination goals...understand those, and the rest comes together quite nicely.

Finally, I'm not saying that it's wrong to incorporate all available data sources into a timeline...not at all. Personally, I like having the flexibility to create mini-, micro- or nano-timelines that show specific details, and then being able to go back to the overall timeline to be able to see what I learned viewed in the context of the overall timeline.

I like to be open to different tools that can be used to assist in analysis, and for those of you who know me, sometimes I write my own. However, I wanted to take a moment to point out some tools that I've found recently that appear to be and have been very useful...

From Claus, I learned about a little tool called DiskDigger from Dymitry Bryant which reportedly allows you to recover deleted files from drives. I thought, wow, this is pretty cool...something to try out with respect to recovering deleted files. So I downloaded a copy and fired it up, and with the first version, saw that it only identified the two physical disks on my system. I had mounted an image file as a read-only drive letter via SmartMount and wondered why this "drive" hadn't been detected. I reached out to Dmitry, expecting to maybe hear back within a couple of days...instead, within relatively short order, Dmitry returned my email with a link to an updated version of DiskDigger, as well as to another tool I'd looked at, NTFSWalker. Now, both tools will recognize drives and volumes, and there is a separate tab for pointing the tool to an image file. Very cool! I thanked Dmitry for his quick response, and he pointed out that he's a one-man shop (wow, THAT sounds familiar...) and that if you find something amiss with a tool or if you have a question, his turn-around time is pretty quick...which is something I can personally attest to.

From JADSoftware comes Internet Evidence Finder, a nice little tool that searches for Facebook chat messages and page fragments, Yahoo chat, and MSN chat messages on drives and within memory dumps. I found my initial reference to this tool on the Forensics from the Sausage Factory blog, where the DC1743 says that he ran the tool against a mounted drive image.

If you're interested in extracting MSOffice OLE document metadata, take a look at OLEDeconstruct from Sanderson Forensics. The sample used to demonstrate the tool is the ever popular Blair document from the ComputerBytesMan. The wmd.pl and oledmp.pl Perl scripts I wrote are still freely available and provided on the DVD accompanying Windows Forensic Analysis, both the first and second editions.

So, MS says that XP's going to be supported at least through 2014...nice. So this means great things for examiners and analysts...great things because there's no reason to give up the tools and research you've done on XP!

One of the unique things about XP is its use of System Restore Points. For users, these take up drive space and allow you to recover from issues, but for an analyst, Restore Points are a veritable treasure trove of historical data!

So, one of the challenges (albeit minor) presented to analysts is how to extract information about (and from) Restore Points from an acquired image. Well, this is actually pretty easy. A while back, I wrote a ProScript for ProDiscover that would run through an image and extract data about Restore Points to include when and why they had been created. This ProScript is called SysRestore.pl and is located on the DVD that accompanies the Windows Forensic Analysis book (both the currently available edition, as well as the second edition, due out in early June 2009).

As an alternative, I came up with another method for extracting the same data, one that does not require a commercial forensic analysis application. So, the first thing you do is mount the acquired image via SmartMount or ImDisk, as a read-only drive letter (in this case, G:\).

Next, get a copy of PSExec and put it on your analysis system. Go to the directory where you saved it and type:

D:\tools>psexec -s cmd

This will open the command prompt to your C:\Windows\system32 directory with the prompt now running with System privileges. Now, cd to the G:\ drive, and type the following commands:

G:\>cd syst*

G:\System Volume Information>cd _resto*

G:\System Volume Information\_restore{GUID}>

At this point, you should be "in" the directory that contains the restore point directories (ie, RP0, RP1, etc.). Select the directory path in the command prompt, right-click to save it to the clipboard, and then cd to the directory where you have your tools.

Note: By default, ACLs on the system only allow access to the System Volume Information directory to System, which is why we use PSExec.

The acquired image I'm using (see the above SmartMount graphic) is one of Lance Mueller's practicals. So at this point, I type in the following command:

C:\tools>rp.pl -d "G:\System Volume Information\_restore{}"

The path to the RP directory has to be in quotes due to the spaces; the output appears as follows:

RP1 Thu Jan 31 04:33:11 2008 Z System Checkpoint
RP2 Thu Jan 31 04:43:38 2008 Z Installed VMware Tools
RP3 Wed Jan 30 14:09:49 2008 Z Installed WinZip 11.1

Pretty neat! Now, we know when the RP was created, and why. If I want to have output that i can add to an event file for my timeline analysis, I add the '-t' switch and I get:

1201753991|RP|||Restore Point created - System Checkpoint
1201754618|RP|||Restore Point created - Installed VMware Tools
1201702189|RP|||Restore Point created - Installed WinZip 11.1

Once again, for timeline analysis, we see our familiar five field format. Note that the system/host and user name fields are blank. Rp.pl does have '-s' and '-u' switches for adding that information (respectively), although only the system name really applies, as Restore Points aren't specific to a user. Use of the '-s' switch will automatically populate the third field with whatever system name you enter.

This code was pretty easy for me to work up last night because I simply extracted it from ripXP, the tool I demo'd at the first SANS Forensic Summit. I'll be demonstrating that same tool again at the next Summit, in July of this year.

One of the things I've run across regarding generating timeline data from the file system is that there has to be more than one way to do this.

For example, what happens if you have an image that you can open in FTK Imager, but for some reason, you cannot get any meaningful data from the TSK tools mmls and fls? Or, what happens if you don't have an image, but are instead accessing a live system? While you can use tools like FTK Imager to extract Registry hive files, and use the copy command to get copies of the EVT (and other) files, you may have to find an alternative method by which to obtain file system data.

Well, that's no problem at all, really. First off, if you have an image and you can open that image in FTK Imager, you can export the directory listing. Simply right-click on the image and choose Export Directory Listing. You can also do this from the command line, via the /CreateDirListing=filename switch, as described in the user manual. The resulting output is tab-delimited and goes to a .csv file which you can easily open in Excel...although that isn't entirely useful, really. Instead, you'll want to parse it in Perl (of course). The format of the directory listing output by FTK Imager includes the filename, full path, size, created, modified and accessed dates (no "entry modified" date), and if the file "is deleted". As it's tab-delimited it can be easily parsed and placed in the necessary format for use in our timeline.

Another thing we'll need to do, though, is translate the time format output by FTK Imager into a Unix epoch time...which is pretty simple with the proper application of the split() function and the use of the DateTime module. Through repeated tests, I've found this module to be more accurate than Time::Local, which has actually had several of my converted timestamps off by a month. Installing the DateTime module is as easy as ppm install datetime, if you're running ActiveState Perl.

Okay, that's one way, how about some others?

You can probably just extract the MFT from an image and use Mark Menz's MFTRipper (discussed in the 22 March CyberSpeak podcast) to extract the data you need.

If you're accessing a live system, you can use Perl (or Python...that's what the illustrious Don Weber prefers) and the stat() funtion to get data from each file on the system, without having to actually access the file itself. However, this will just get the live file system...you won't get things like entry modified times and deleted files, and you will be prevented from accessing some directories by default. You can use this same code to do the exact same thing with an image mounted via Andy Rosen's SmartMount, but you may want to first open a command prompt via psexec -s cmd, so that you can run the Perl script from that command prompt, with System-level privileges. This will be particularly important if you want to get not only file system data from Windows XP System Restore Points, but also if you want to parse the rp.log file in each Restore Point for when and why the RP was created, or run tools such as ripXP.

Finally, if you're read my book, you'll know that I've written a number ProScripts for use with ProDiscover. Writing one to create a timeline bodyfile shouldn't be too difficult, although at this point, I'm not sure why you'd need to with the other methods listed.

A couple of things to remember when creating these timelines...

First, the output of fls.exe is pipe-delimited, and includes the fields:

MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime

In most instances, the "MD5" entry is 0, although if you're writing your own code, you can definitely populate it. Populating this field can let you do all sorts of analysis besides just looking at the timeline, such as determining if Windows File Protection was subverted to modify "protected" files.

The timestamps are in Unix epoch time, and consist of the last access time, the last modified time, the "entry modified" (ie, ctime), and the creation date (ie, crtime) of the file. This order is important, not only when parsing the bodyfile, but also when creating a tool to assemble your own bodyfile; putting these various times in the wrong locations can throw off your timeline analysis.

Finally, an interesting side effect of conducting this analysis is that timeline assembly and analysis can be run in parallel to other activities, particularly those that consume a great deal of time, such as scanning for PCI data. Also, as the output is largely text based and in most instances the filenames and other necessary files (INFO2, EVT, AV logs, etc.) do not themselves contain sensitive data, this information can be extracted from an image, compressed and protected as necessary, and sent to another analyst to conduct the assembly and analysis. What this leads to is a faster response time, answers delivered to the customer faster, and much quicker resolution of an incident.

Been watching the 'net recently to see what's new? I have. Saw the MMPC write-up on Conficker.E recently, and it occurred to me that the authors of this bit of malware are really going out of their way to "protect" the systems they infect. After all, look at the list of process names that it terminates if found. Now, from that list, how many of those tools do YOU use when troubleshooting a system or performing incident response? How about dynamic malware analysis?

Okay, so this is nothing new is it? By "new", I mean the need to adapt our tools and techniques to the current environment and climate. Back in the day (or in the "Old Corps", as the case may be...), malware would maintain persistence by writing to the Registry, in particular, to the Run key. Once enough folks became familiar with that technique, then there was a move to maintain persistence via other Registry keys, including the Services keys. Then, to make things even more fun, the Services were added as randomly-named DLLs, loaded as part of SvcHost. We're even seeing WFP subverted or disabled, or bypassed completely by modifying "protected" files in memory only (as with Conficker.E, apparently). Oh, yeah, and while I'm off looking in the Registry for a persistence mechanism, some malware author is using Scheduled Tasks, instead.

This is all the continuing evolution of (cyber)warfare. Students of military history have seen this throughout the ages. Build a tank, then build an armament or weapon to take it out. Add armor to the tank, someone builds a missile. Reactive armor is added to the tank, and then a probe is added to the missile...and back and forth we go. The IR/CF world is really no different, as the same sorts of tactics are used.

It's never a good time to rest on your laurels. Just when you think you've got it licked and all wrapped up, that's when you know its time to change how you're doing things again.

So far, I've posted twice (see Resources below) on this subject, each time giving sort of a general overview of a process, but without getting down-and-dirty. One of the difficult things about putting together a process or a "best practice" is that very often, what's "best" for one person (or group) may not be "best" for another. So, with respect to malware detection (not analysis...at this point, we're still looking for the "bad stuff"), there several techniques you can use when going about this sort of process.

First, many times we may be looking for malware for different reasons. One reason would be that we suspect that a system may be infected with malware, while another may be that by looking for malware, we're attempting to nail down an intrusion or compromise (like following the trail of artifacts back to the original compromise vector), with the malware being a byproduct of the intrusion.

Another thing to keep in mind is that malware, in general, has four main characteristics:
1. An initial infection vector - how it got on the system in the first place; this can be through browser download (even on a secondary or tertiary level), email attachment, etc. Conficker, for example, can infect a system when the user opens Explorer on drive (USB thumb drive, mapped share, etc.) that has been infected. In some SQL injection compromises, I've seen malware placed on a system by the intruder sending tftp commands or creating and launching an FTP script, all via SQL injection. I've also seen the bad guy load the malware into a database table in 512 byte chunks, and then have the database reassemble the file in the file system so they could launch it.

2. Artifacts - what actions does the malware take upon infection and what footprints does it leave? Many time, we can determine these ourselves through dynamic malware analysis, but often its sufficient (and quicker) to use what's available from AV sites. Sometimes these "footprints" can be unique to a malware family (Conficker, for example). Also, these artifacts do not have to be restricted to a host; are there any network-based artifacts that you can use when analyzing logs?

3. Propogation Mechanism - How does the malware get about? Is it a worm that exploits a known (or unknown) vulnerability? Or is it like Conficker, infecting files at the root of drives and adding autorun.inf files? Understanding the propogation mechanism can help you fight the tide, as it were, or develop a mechanism to block or detect further infections.

4. Persistence Mechanism - As Jesse Kornblum points out in his "Rootkit Paradox" paper, malware likes to remain persistent, and the simple fact is that there are a finite number of ways to do that on a Windows system. The persistence mechanism can relate back to Artifacts; however, this would be an artifact specifically intended to allow the malware to survive reboots.

These characteristics act as a framework to help us visualize, understand, and categorize malware. Over the years, I have used these four characteristics to track down malware and help others do the same. In one instance in particular, after a customer had battled with a persistent (albeit fairly harmless) worm for over a month, I was told that they would delete certain files, reboot the system, and the files would be back. It occurred to me that they hadn't adequately tracked down the persistence mechanism, and once we found it, they were able to clean their systems!

Okay, so how can we go about tracking down malware, detecting its presence? I'm going to start with the idea that we have an acquired image, and we need to determine if there's malware on the system. I'm going to list several mechanisms for doing so, and these are not listed in order of priority. It will be incumbent upon you, the reader, to determine which steps work best for you, and in which order...that said, away we go!

Targeted Artifact Analysis
A lot of times, we may not know exactly what we're looking for, but if we know the persistence mechanism or other artifacts of malware, we can do a quick, surgical scan that malware. Tools such as RegRipper can make this a fast and extremely easy process (remember, for live systems, you can use RegRipper in combination with F-Response!). Take Conficker...while there are changes in artifacts based on the variant, the set of unique artifacts is pretty limited. As the variants have changed so as to obviate both AV scans and hash comparisons (at this point, everyone should be aware that hash comparisons for malware are marginally less effective than AV scanning with a single engine), artifacts have remained fairly static (Registry modifications) with some new ones (Scheduled Task) being added. The addition of unique artifacts helps narrow down the false positives.

Log Analysis
There are a number of logs on Windows systems that may provide some insight into malware detection. For example, maybe the installed AV product detected and quaratined a tertiary download...depending on the product, this may appear in the AV product logs as well as the Event Log. Or perhaps the AV scanner's real-time protection mechanism was disabled and the user ran a scan at a later time that detected the malware. Either way, check for an installed AV or anti-spyware product, and check the logs. Also, examine the Event Logs. And don't forget mrt.log!

Scans
Another way to go about detecting the presence of malware on systems is to scan for it using AV products. Yes, there are commercial AV products available, but as many have seen over the past couple of months, particularly with Conficker and Virut, sometimes using just one commercial AV product isn't enough. The key to running scans is to know what the scan is looking for so that you can better interpret the results.

For example, look at tools such as sigcheck and missidentify; both are extremely useful, but each tool looks for certain things. Another scanning tool that can be extremely useful is Yara, and anyone looking at using Yara should consider using the Yara-Scout Sniper release from the illustrious Don Weber! Yara can use packer rules (from the public PeID signatures) to detect packed files, and Don has added fuzzy hashing to Scout Sniper.

As a side note, while fuzzy hashing is obviously predicated on having a sample of the malware to hash, it is still a much preferable technique over "normal" hashing using MD5 or SHA-1 hashes. In one instance, I had two examinations about 8 months apart where I found files of the same name on both. Traditional (MD5) hashes didn't match, but using ssdeep, I was able to determine that the files were 99% similar.

So, other than scanning for not-normal files (with "normal" being somewhat amorphous), there are other ways to scan for possible malware infections. With the amount of malware that subverts Windows File Protection (WFP) in some manner, tools like wfpcheck can be used to determine if something on the system modified any of the "protected" files.

But again, keep in mind that scanning in general is a broad-brush approach and scans don't find everything. The idea is to have some idea of what you're looking for, and then selecting the proper tool (or tools) to build a comprehensive process. As part of that process, you'll need to document what you did, what you looked for, and what tools you used...because without that documentation, how to describe what you did in a repeatable manner, and how do you go about improving your process in the future?

Resources
Looking for "Bad Stuff", pt I and pt II
Claus's post on Portable AV tools
Free-av.com
Free AVG
PCTools

After part I of what looks like it may become a series of Looking for "Bad Stuff" posts, I thought it would be a good idea to address this topic a bit more; clearly, one of the biggest issues most analysts may have, regardless of affiliation (LE, corporate consultant, etc.), will be simply where to begin analysis in the absence of specific guidance or criteria. Sometimes even repeated and detailed interviews of IT staff do not provide you with the information you need (or worse, may send you off in the wrong direction) and hence, you need to start by casting a wide net through malware scans (AV, anti-spyware, rootkit detectors, etc.).

So, in an attempt to develop a codified process as a response to this question, we need to start by addressing a couple of things. First, at some point before you actually start performing analysis, even before you begin the engagement, you need to ask yourself, What do I hope to achieve? Many times, this may be defined, to some degree, for you by a customer...other times, it may not. Once you start to understand your own goals, you then need to ask, What data do I need to achieve it? Whether you're beginning an engagement and scoping your acquisition, or you're sitting down to begin analysis of a single acquired image, DOCUMENTING these questions and their answers is paramount! I know, I know..."you s*ck because you make me write stuff down!" Believe me, I've heard it all before...but the fact of the matter is, if you don't write it down, it didn't happen!

Casting Your Net
Once you're ready to kick off your analysis, there are a number of ways to get started. In my previous post, I mentioned mounting the acquired image as a read-only file system and scanning it with AV software. Chris added booting the acquired image with LiveView and scanning with live rootkit detection tools such as GMER. All of this is a great way to really cast a net, but the whole idea behind a net is that it's designed and created based on a current understanding of what you're trying to catch. Early fishermen created nets based on the size of the fish they were trying to catch, and anyone who watches Man vs Wild or Survivorman has seen Bear and Les try to catch pretty small stuff (really, just about anything). As we've seen with many of the malware outbreaks lately (really, over the years), some malware isn't detected by AV products until someone else finds it and submits a sample...so if multiple malware scans come up empty, don't think that this definitely means that there is NO malware on the system.

So, there's malware (AV, anti-spyware, etc.) scans, and there's also other ways to scan for unusual or suspicious files. In the previous post, I mentioned a couple of tools...missidentify, by Jesse Kornblum, and sigcheck, from MS/SysInternals. Both of these tools can be used to attempt to identify suspicious files on a system, particularly where executable files tend to reside (system32 dir, in a Program Files subdirectory, etc.). These tools are by no means definitive...they still require someone looking at the results to determine what's legit and what's not. The reason for this is that malware authors and intruders put a lot of time and effort into remaining persistent on systems, and a tool written six months ago to detect a specific set of techniques will no longer be sufficient. Besides, to be completely honest, in a great many engagements I've been on, the easiest thing to do has been to hide in plain sight.

Another tool I mentioned was WFPCheck...you'll notice that this tool doesn't have a link. This is something I wrote a while ago to help detect the presence of malware that subverts or disables Windows File Protection (WFP), and subsequently modifies "protected" files. Now, WFP is clearly not meant as a security or protection mechanism, and there are ways (albeit a finite number of them) to subvert or disable WFP (for example, see here and here); however, detecting the artifacts of an infection is sometimes the only way we have available of determining if there was an infection.

Speaking of artifacts, another means of getting started in our analysis that we can do in parallel with the malware scans is to extract important files (Registry hive files, EVT files) from the image before mounting it, and then do some targeted analysis of those files. Tools like RegRipper and the Evt2Xls tools are extremely valuable for this kind of work, in that they are fast, efficient, and depending on the user (or perhaps more accurately, the user community), can be very, very targeted. I've written a number of plugins over the past several months that look specifically for artifacts left by specific families of malware.

What NOT To Do
One of the most often used means of "analysis" that I've seen with customers (and in user forums...forii...whateva!!) is, "I found a file and searched for the file name on Google...". Folks, this is NOT an analysis technique. Sure, it's a way to start, but it should not be all you do. There are plenty of sources out there that provide a basic understanding of things like the PE header format, both on the web and in books (hint, hint). So all I'm sayin' here is, don't let a Google search for the file name or a string you found in the file be the end of your analysis.

As a follow-on to my previous post regarding OMFW, there have been some developments in the area of memory dumping and parsing (ie, collection and analysis) that have occurred over the past couple of months.

Lance Mueller posted on the new standalone memory dumping tool that is part of EnCase 6.11. Interesting tool as it apparently dumps the contents of physical memory from Windows (Windows 2000 through Vista) to an EnCase .E0x file format, for inclusion in a case. According to the documentation, there's functionality to extract that memory dump from the .E0x file format to something usable by HBGary's Responder product. Note: Initial testing indicates that FTK Imager will successfully convert the resulting .E0x files to a dd-style format for use with other tools.

Jesse Kornblum referred mdd to me. This one looks promising...captures memory from Windows versions through Vista and 2008. Jesse posted some clarifications about this tool on his blog. As it stands, this appears to be the first free tool to dump RAM from Windows 2000 through 2008, inclusive, in a dd-style format. Note: Updated version 1.1 was released on 17 June.

So available tools for collecting the contents of physical memory are becoming more available. From an analysis standpoint, I really think that you want to keep your eyes on the guys over at Volatility Systems, though.

Addendum: win32dd is available from Matthieu Suiche. I just found out about this so I haven't had an opportunity to try it...but I am looking forward to adding it to the list of tools to test!

Andreas blogs on the new tools...great stuff, very comprehensive view of where this all stands at the moment.

To continue adding to the list of free tools (earlier posts here and here), here are a couple of gems I found recently...

NetworkMiner - a free network forensic analysis tool that takes analysis of network traffic captures to another level. Very cool tool...I love how WireShark lets you reassemble streams, but NetworkMiner lets you do a bit more, and it's Windows-based. Don't have any packet captures available to try it with? Check out the HoneyNet Project's SotM #27.

Thanks goes to Claus for pointing these out...

Stinger and MVC...these are NOT full-bore AV applications, but rather free tools meant to target specific malware. Use these on a live system, or mount the acquired image as a live file system (as opposed to booting the image...) and scan the files.

OpenFilesView - Neat little tool to see which files are open on a system; GUI based but comes with command line options, making it a great tool for use in IR batch files. Say you've got a suspected intrusion and you need to know if sensitive data (pursuant to PCI, HIPAA, etc.) is being siphoned off of the system...well, grab process information w/ tools like tlist.exe and correlate that information to files opened on the system by process...

MUICacheView - The NirSoft site says, "Each time that you start using a new application, Windows operating system automatically extract the application name from the version resource of the exe file, and stores it for using it later, in Registry key known as the 'MuiCache'." This is one of those things I've looked into, and I'm not able to find what the OS would use this for...but hey, who am I to complain about it, right?

By the way, RegRipper has a plugin for this key, which means that you can parse the contents of this key by either extracting the hive from an image, or by firing up F-Response. ;-)

Addendum: Claus posted some of his own bloggy goodness about Evidence Collector, and from that post I learned about USBHistory, a nice little tool that extracts historical information about USB devices connected to a live system. The author even gives a shout out to ol' watashe-wa and his book! Very cool!

What??!? "Free" (as in 'beer') analysis? A bit ago, I blogged about Forensic Analysis on the Cheap, and I wanted to revisit that topic, particularly to mention a couple of tools I've run across since then...

Event Logs
In an earlier post, I mentioned some tools you could use to perform Event Log analysis. I still like the functionality in EvtUI (although I may be seen as biased because I wrote it), but if tools like this scare you, there are other options available. For example, Event Log Explorer is a nice little little app, and you can obtain a free license for its use. In direct mode, it works just like EvtUI, accessing the event records directly within a .evt file extracted from an acquired image.

Registry Analysis
I have to say that I'm really partial to RegRipper and its associated CLI utility, rip.exe. A couple of minor tweaks, as well as some new plugins, both of which were recently added, make this an immensely useful (not to mention unique) tool.

When looking for things I may want/need to add as plugins to RegRipper, my favorite Registry Viewer to use is MiTeC's RFV. I can go through the hive file and look at things, and fire rip.exe off against it without having to unload the hive or anything like that. RFV is a great Registry Viewer that facilitates the development of plugins.

File Carving
I've mentioned scalpel before as a tool for file carving...XaberSoft provides a GUI interface for setting up the scalpel config file

Another useful tool for file carving is PhotoRec. Even though its intended for extracting image files, I'm sure that there are a number of folks out there interested in doing just that...

Other Tools
Shadow Explorer - I haven't had an opportunity to try this tool yet, but I'm told that it's great for recovering files using Vista's Volume Shadow Copy Service. If you can boot an acquired image using LiveView, and log into the running image, you may be able to get some useful information or recover some files using this tool.

Do I need to say it again? The age of Nintendo Forensics is gone, long past.

Acquiring a system is no longer as simple as removing the hard drive, hooking it up to a write blocker, and imaging it. Storage capacity is increasing, devices capable of storing data are diversifying and becoming more numerous (along with the data formats)...all of which are becoming more ubiquitous and common-place. As the sophistication and complexity of devices and operating systems increases, the solution to the issue of backlogs due to examinations requiring additional resources is training and education.

Training and education lead to greater subject-matter knowledge, allowing the investigator to ask better questions, and perhaps even make better requests for assistance. Having a better understanding of what is available to you and where to go to look leads to better data collection, and more thorough and efficient examinations. It also leads to solutions that might not be readily apparent to those that follow the "point and click execution" methodology.

Take this article from Police Chief Magazine, for example. 1stSgt Cohen goes so far as to specifically mention the collection of volatile data and the contents of RAM. IMHO, this is a HUGE step in the right direction. In this instance, a law enforcement officer is publicly recognizing the importance of volatile data in an investigation.

It's also clear from the article that training and education has led to the use of a "computer forensics field triage", which simply exemplifies the need for growth in this area. It's also clear from the article that a partnership between law enforcement, the NW3C and Purdue University has benefited all parties. It would appear that at some point in the game, the LEs were able to identify what they needed, and were able to request the necessary assistance from Purdue and NW3C...something known in consulting circles as "requirements analysis". At some point, the cops understood the importance of volatile memory, and thought, "we need this...now, how do we collect it in the proper manner?"

So what does this have to do with alternative methods of analysis? An increase in knowledge allows you to seek out alternative methods for your investigation.

For example, take the Trojan Defense. The "purist" approach to computer forensics...remove the hard drive from the system, acquire an image, and look for files...appears to have been less than successful, in at least one case in 2003. The effect of this decision may have set the stage for other similar decisions. So, let's say you've examined the image, searched for files, even mounted the image as a file system and hit it with multiple AV, anti-spyware, and hash-comparison, and still haven't found anything. Then lets assume you had collected volatile data...active process list, network connections, port-to-process mapping, etc. Parsing that data, wouldn't the case have been a bit more iron-clad? You'd be able to show that at the time the system was acquired, here are the processes that were running (along with their command line options, etc.), installed modules, network connections, etc.

At that point, the argument may have been that the Trojan included a rootkit component that was memory-resident and never wrote to the disk. Okay, so let's say that instead of running individual comments to collect specific elements of memory (or, better yet, before doing that...), you'd grabbed the contents of RAM? Tools for parsing the contents of RAM do not need to employ the MS API to do so, and can even locate an exited or unlinked process, and then extract the executable image file for that process from the RAM dump.

What if the issue had occurred in an environment with traffic monitoring...firewall, IDS and IPS logs may have come into play, not to mention traffic captures gathered by an alert admin or a highly-trained IR team? Then you'd have even more data to correlate...filter the network traffic based on the IP address of the system, isolate that traffic, etc.

The more you know about something, the better. The more you know about your car, for example, the better you are able to describe the issue to a mechanic. With even more knowledge, you may even be able to diagnose the issue and be able to provide something more descriptive than "it doesn't work". The same thing applies to IR, as well as to forensic analysis...greater knowledge leads to better response and collection, which leads to more thorough and efficient analysis.

So how do we get there? Well, someone figured it out, and joined forces with Purdue and NW3C. Another way to do this is through online collaboration, forums, etc.

It's been a while since I've blogged on memory analysis, I know. This is in part due to my work schedule, but it also has a bit to do with how things have apparently cooled off in this area...there just doesn't seem to be the flurry of activity that there was in the past...

However, I could be wrong on that. I had received an email from someone telling me that certain tools mentioned in my book were not available (of those mentioned...nc.exe, BinText, and pmdump.exe, only BinText seems to be no longer available via the FoundStone site), so I began looking around to see if this was, in fact, the case. While looking for pmdump.exe, I noticed that Arne had released a tool called memimager.exe recently, which allows you to dump the contents of RAM using the NtSystemDebugControl API. I downloaded memimager.exe and ran it on my XP SP2 system, and then ran lsproc.pl (a modified version of my lsproc.pl for Windows 2000 systems) against it and found:

0 0 Idle
408 2860 cmd.exe
2860 3052 memimager.exe
408 3608 firefox.exe
408 120 aim6.exe
408 3576 realsched.exe
120 192 aolsoftware.exe(x)
1144 3904 svchost.exe
408 2768 hqtray.exe
408 1744 WLTRAY.EXE
408 2696 stsystra.exe
244 408 explorer.exe

Look familiar? Sure it does, albeit the above is only an extract of the output. Memimager.exe appears to work very similar to the older version of George M. Garner, Jr's dd.exe (the one that accessed the PhysicalMemory object), particularly where areas of memory that could not be read were filled with 0's. I haven't tried memimager on a Windows 2003 (no SPs) system yet. However, it is important to note that Nigilant32 from Agile Risk Management is the only other freely available tool that I'm aware of that will allow you to dump the contents of PhysicalMemory from pre-Win2K3SP1 systems...it's included with Helix, but if you're a consultant thinking about using it, be sure to read the license agreement. If you're running Nigilant32 from the Helix CD, the AgileRM license agreement applies.

I also wanted to followup and see what AAron's been up to over at Volatile Systems...his Volatility Framework is extremely promising! From there, I went to check out his blog, and saw a couple of interesting posts and links. AAron is definitely one to watch in this area of study, and he's coming out with some really innovative tools.

One of the links on AAron's blog went to something called "Push the Red Button"...this apparently isn't the same RedButton from MWC, Inc. (the RedButton GUI is visible in fig 2-5 on page 50 of my first book...you can download your own copy of the "old skool" RedButton to play with), but is very interesting. One blogpost that caught my eye had to do with carving Registry hive files from memory dumps. I've looked at this recently, albeit from a different perspective...I've written code to locate Registry keys, values, and Event Log records in memory dumps. The code is very alpha at this point, but what I've found appears fairly promising. Running such code across an entire memory dump doesn't provide a great deal of context for your data, so I would strongly suggest first extracting the contents of process memory (perhaps using lspm.pl, found on the DVD with my book), or using a tool such as pmdump.exe to extract the process memory itself during incident response activities. Other tools of note for more general file carving include Scalpel and Foremost.

So...more than anything else, it looks like it's getting to be a good time to update processes and tools. I mentioned an upcoming speaking engagement earlier, and I'm sure that there will be other opportunities to speak on Windows memory analysis in the future.

One of the things I mentioned in my new book was an alternative analysis method for performing computer forensic analysis. I specifically mentioned the use of Mount Image Pro for mounting a dd image as a read-only file structure, which opens up some areas of analysis that many may benefit from using. For example, during an intrusion case, one thing you may want to do is scan the image with AV software. This may save you a great deal of time trying to locate hacker tools by hand. Also, this is something you may want to do when you may be faced with the "Trojan Defense".

Another thought/useful option is this - we all have things that we look for everytime we open an acquired image of a Windows system, and there are other things that we look for on a case-by-case basis. Most often we do this through our forensic analysis software package, such as ProDiscover or EnCase. However, even though these packages ship with scripts to do some initial data collection and parsing for us, sometimes, they aren't as complete as they could be, or we'd like them to be, and it takes forever to get scripts updated because the few folks that actually write their own scripts are busy with other things. Sometimes you may be in a rush or under pressure, and may forget something that you would normally look for. So what if we had a script or a tool that would run through an image, pulling things out for us each time...all automated so that we wouldn't have to remember all of the different places could look, but at the same time, its all documented? Say, the tool would check to see if the Recycle Bin had been disabled, and then move on to parsing the INFO2 file for one user, or all users. Or, the tool would collect the audit policy from the system, check the Registry entries for the Event Logs, and then collect statistics from the Event Log files themselves, or automatically parse the Event Log files to .csv format (or both). Would that be useful?

Another use of something like this is for forensic analysis training. Mounting the image as a drive letter lets you dig into aspects of forensic analysis that while accessible via commercial forensic analysis applications, may be somewhat easier to grasp and work with, particularly for new students, or junior members of an IR/CF team or CSIRT.

Okay, so now, how do we do this? How do we start with just a dd image, and get to a read-only drive letter (ie., F:\, G:\) so that we can point an AV scanner or some other tool at it?

To get the dd image to begin with, you can use ProDiscover, Helix, straight dd, or even FTK Imager Lite. If you're using ProDiscover, you can use the Tools -> Image Conversion Tools -> VMWare Support for DD Images... option to create the necessary .vmdk file.