Tools

Microsoft recently released an update (KB 3004375) that allows certain versions the Windows OS to record command line options, if Process Tracking is enabled, in the Windows Event Log. Microsoft also recently upgraded Sysmon to version 2.0, with some interesting new capabilities.  I really like this tool, and I use it when I'm doing testing in my lab, to provide more detailed information about what's happening on the system. I like to run both of these side-by-side on my testing VMs, to see the difference in what's reported.  I find this to be very valuable, not only in testing, but also in making recommendations regarding auditing and the use of process creation monitoring tools, such as Carbon Black. Even if you're not able to run something like Cb in your environment, monitoring process creation via the Windows Event Log or the use of Sysmon, and shuttling the records off of the system in to a SEIM, can be extremely valuable.

If you do have Process Tracking enabled in your Windows Event Log, Willi Ballenthin has released a pretty fascinating tool called process-forest that will parse Windows Security Event Logs (Security.evtx) for process tracking events, and assemble what's found into a process tree, sorting by PID/PPID.  Agan, if you've enabled Process Tracking in your logging policy, this tool will be very valuable for displaying the information in your logs in a manner that's a bit more meaningful. If you're a consultant (like me) then having this tool as an option, should the client have the appropriate audit configuration, can provide a quick view of available data that may be very beneficial.
Willi has also released a Python script for parsing AmCache Registry hive files, which were new to Windows 8, and are available in Windows 10.  To get more of an understanding of the information available in this hive file that was first available on Windows 8, check out Yogesh's blog post here, with part 2 here.  RegRipper has had an amcache.pl plugin for over a year.

After reading Jon Glass's blog post on parsing the IE10+ WebCacheV01.dat web history file, I used his code as the basis for creating a script similar to destlist.py, in that I can now parse the history information from the file and include it in my analysis.  This can be very helpful if I need to incorporate it into a timeline, or if I just want to take a look at the information separately.  Thanks to Jon for providing the example code, and to Jamie Levy/@gleeda for helping me parse out the last accessed time stamp information.  Don't expect anything spectacularly new from this code, as it's based on Jon's code...I just needed something to meet my needs.

The NCC Group has released a tool called "Windows Activity Logger", which produces (per the description on the web site), a three hour rolling window of insight into system activity by recording process creation, along with thread creation, LoadImage events, etc.  The free version of the tool allows you to run it on up to 10 hosts.  I'm not sure how effective a "3 hr rolling window" is for some IR engagements (notification occurs months after the fact) but it's definitely a good tool for testing within a lab environment.  I can also see how this can be useful if you have some sort of alerting going on, so that you're able to respond within a meaningful time, in order to take advantage of the available data.

I was doing some reading recently regarding CrowdStrike's new modules in their CrowdResponse tool to assist with collecting application execution information from hosts.  Part of this included the ability to parse SuperFetch files.  As I dug into it a bit more, I ran across the ReWolf SuperFetch Dumper (read about the tool here).

Speaking of Windows 10, there was a recent post to an online forum in which the OP stated that he'd seen something different in the DestList stream of Windows 10 *.automaticDestinations-ms Jump Lists.  I downloaded the Windows 10 Technical Preview, installed it in VirtualBox, and ran it.  I then extracted the two Jump List files from the appropriate folder and started looking at a hex view of their DestList streams.  Within pretty short order, I began to see that many of the offsets that I'd identified previously were the same as they were for Windows 7 and 8, so I ran my destlist.py/.exe tool, and found that they were pretty much the same...the tool worked just fine, exactly as expected.  As yet, there's been nothing specific from the OP about what they'd seen that was different, but it's entirely possible.  Whenever a new version of Windows comes out, DFIR folks seem to immediately ask, "...what's new?"  Why not instead focus on what's the same?  There seem to be more artifacts that don't change much between versions that there are wildly new structures and formats.  After all, the OLE/structured storage format used by the Jump List files has been around for a very long time.

Resources
Dell SecureWorks Tools
WindowsIR: FOSS Tools
Loki - Simple IOC Scanner

Writing Tools

I mentioned during my presentation at OSDFCon that tools like RegRipper come from my own use cases.  I've discussed my motivation for writing DFIR books, but I've never really discussed why I write tools.

Why do I write my own tools?
First, writing my own tools allows me to become more familiar with the data itself.  Writing RegRipper put me in a position to become more familiar with Registry data.  Writing an MFT parser got me much more familiar with the MFT, and forced me to look really hard a some of the short descriptions in Brian's book (File System Forensic Analysis).

Sometimes, I want/need a tool to do something specific, and there simply isn't something available that meets my immediate need, my current use case.  Here's an example...I was once asked to take a look at an image acquired from a system; during the acquisition process, there were a number of sector errors reported, apparently.  I was able to open the image in FTK Imager, but could not extract a directory listing, and TSK fls.exe threw an error and quit before any output was generated.  I wanted to see if I could add file system metadata to a timeline...I was able to use both FTK Imager and TSK icat.exe to extract most of the $MFT file.  Using a Perl script I'd written for parsing the MFT, I was able to incorporate some file system metadata into the timeline...this was something I was not able to do with other tools.

Why do I share the tools I write?
I share the tools I write in the hopes that others will find them useful, and provide feedback or input as to how the tools might be more useful.  However, I know that this is not why people download and use tools.  So, rather than expecting feedback, I now put my tools up on GitHub for two reasons; one is so that I can download them for my own use, regardless of where I am.  Two, there are a very small number of analysts who will actually use to the tools and give me their feedback, so I share the tools for them.

One of the drawbacks of sharing free tools is that those who use them have no "skin in the game".  The tools are free, so it's just as easy to delete them or never use them as it is to download them.  However, there's nothing in the freely available tools that pushes or encourages those who use them to "develop" them further.  Now, I do get "it doesn't work" emails every now and then, and when I can get a clear, concise description of what's going on, or actual sample data to test against, I can see if I can figure out what the issue is and roll out/commit an update.  However, I have also heard folks say, "we couldn't get it to work"...and nothing else.  Someone recently told me that the output of "recbin -d dir -c" was "messed up", and it turns out that what they meant was that the time stamp was in Unix epoch format.

Similarly, those who incorporate free tools into their distributions or courses seem to rarely contribute to the development and extension of those tools.  I know that RegRipper is incorporated into several *nix-based forensic tools distributions, as well as used in a number of courses, and some courses incorporate scenarios and labs into their coursework; yet, it's extremely rare to get something from one of those groups that extends the use of the tool (i.e., even ideas for new or updated plugins).

I am very thankfully to those folks who have shared data; however, it's been limited.  The only way to expand and extend the capabilities of tools like RegRipper and others is to use them thoughtfully, thinking critically, and looking beyond the output to seeing what other data may be available.  If this isn't something you feel comfortable doing, providing the data may be a better way to approach it, and may result in updates much faster.

Why do I write multiple tools?
I know that some folks have difficulty remembering when and how to use various tools, and to be honest, I get it.  There are a lot of tools out there that do various useful things for analysts.  I know that writing multiple tools means that I have to remember which tool to run under which circumstance, and to help me remember, I tend to give them descriptive names.  For example, for parsing Event Log/*.evt files from XP/2003 systems, I called the tool "evtparse.pl", rather than "tool1.pl".

My rationale for writing multiple tools has everything to do with my use case, and the goals of my analysis.  In some cases, I may be assisting another analyst, and may use a single data source (a single Event Log file, or multiple files) in order to collect or validate their findings.  In such cases, I usually do not have access to the full image, and it's impractical for whomever I'm working with to share the full image.  Instead, I'll usually get Registry hives in one zipped archive, and Windows Event Logs in another.

In other cases, I may not need all of the data in an acquired image in order to address my analysis goals.  For example, if the question I'm trying to answer is, "did someone access this Win7 via Terminal Services Client?", all I need is a limited amount of data to parse.

Finally, if I'm giving a presentation or teaching a class, I would most likely not want to run a full application multiple times, for each different data source that I have available.

Tool Requests
Every now and then, I get requests to create a tool or to update some of the tools I've written.  A while back, a good friend of mine reached out and asked me to assist with parsing Facebook chat messages that had been parsed out of an image via EnCase...she wanted to get them all parsed and reassembled into a complete conversation.  That turned out to be pretty fun, and I had an initial script turned around in about an hour, with a final polished script finished by the end of the day (about four hours).

One tool I was asked to update is recbin, something I wrote to parse both XP/2003 INFO2 files as well as the $I* files found in the Vista+ Recycle Bin.  I received a request to update the tool to point it to a folder and parse all of the $I* files in that folder, but I never got around to adding that bit of code.  However, when that person followed up with me recently, it took all of about 5 minutes Googling to come up with a batch file that would help with that issue...

@echo off 
echo Searching %1 for new $I* files...
for %%F in (%1\$I*) do (recbin -f %%F)

This isn't any different from Corey Harrell's auto_rip script.  My point is that getting the capabilities and functionality out of the tools you have available is often very easy.  After I sent this batch file to person who asked about it, I was asked how the output could be listed in CSV format, so I added the "-c" switch to the recbin command, and sent the "new" batch file back.

Tool Updates
Many times, I don't get a request for new capabilities to a tool; instead, I find something interesting and based on what I read, I update one of the tools myself.  A great example of this is Brian Baskin's DJ Forensic Analysis blog post; the post was published on 11 Nov, and on the morning of 12 Nov, I wrote three RegRipper plugins, did some quick testing (with the limited data that I had available), and committed the new plugins to the GitHub repository...all before 8:30am.  The three plugins can be used by anyone doing analysis to validate Brian's findings, and then hopefully expand upon them.