Friday Stuff

ADSs
I've been fascinated by NTFS alternate data streams for almost 14 years now, and I caught MHL's recent blog post on detecting stealth ADSs with TSK tools.  The idea behind a "stealth ADS" came from this Exploit Monday post, and both posts were very interesting reads.

ADSs are one of those NTFS artifacts that many folks (DF analysts, admins, etc.) don't really know a whole lot about, and I'm not sure why.  I guess it's a chicken-or-the-egg issue; how do you know that there aren't any ADSs on your systems if you're not looking for them?  If you don't look for them, why do you then need to know about them...right?  I remember about 11 years ago, Benny and Ratter of the group 29A wrote Win32/Stream, mostly as a proof of concept.

F-Response
If you haven't heard of Matthew Shannon's F-Response, I'd really have to question where've you been.  F-Response is one of those tools that have really pushed incident response work ahead by leaps and bounds.  Using F-Response, you can reach out systems on another floor, in another building, or even in another city, and make a read-only connection to the physical disk, and from there, run tools to search for specific items, collect specific files, or even conduct a physical or logical acquisition.  With Windows systems, you can even collect the contents of physical memory.

Matt's added the FlexScript scripting capability to F-Response, and through Powershell, recently demonstrated how to use F-Response to automate large collections.  As always, Matt includes a video so you can see what he did, in addition to providing the scripts along with the F-Response Mission Guides.

This adds a whole new dimension to an already-valuable tool; being able to automate large-scale collections is a powerful capability.  If an incident occurs, an organization can use this capability to automate quickly connecting to systems and either collecting data, or

Live Forensics
Speaking of Matt Shannon, thanks to his Twitter account, I was recently directed to this paper, which is intended to dispel some of the myths of live digital forensics.  The paper is just 5 pages long, so I printed it out so I could read it...and found it very interesting.  The paper essentially addresses (and shoots down) three common myths that are encountered within the digital forensics community regarding live forensics, and does so only with respect to the admissibility of "live" digital evidence in a US court of law.  I can see how this distinction is important for the paper, particularly in driving its point home.  Additional discussion in dispelling the myths would extend the length of the paper unnecessarily, and potentially make the argument a bit murky.  In short, each of the myths is addressed with "...the Court makes no requirement...".

This is similar to conversations I've had with Chris Pogue, during which we've discussed "court certified" tools; this is something we've both heard, and the long and short of the discussion is that there is no such thing, regardless of what folks (including marketing staff) my choose to believe or say.


Volatility
Here's a post on the malwarereversing blog that discusses (and provides) the vscan.py plugin for Volatility 2.0, which allows you to submit malicious stuff you've found in a Windows memory dump to an online AV scanning site (the post uses Jotti).

The blog post also mentions MHL's avsubmit.py plugin, which allows for the submission of stuff you've found to VirusTotal.

Tools
I ran across the CERT Linux Forensics Tools Repository recently; very cool.  Not only are some of my tools posted there (i.e., RegRipper, tln_tools) but many of the ones listed also run on Winderz!

Mark Woan recently updated JumpLister to include parsing of DestList streams, as well as looking up AppIDs. It appears from the JumpLister web page that the DestList parsing capability was added based on the information available in the ForensicsWiki, which really shows how useful and powerful a resource the ForensicsWiki can be.  Mark's application downloads as part of an installer package, and it only runs on Windows.  The installer adds 11 files to your system, and when you run it, you can load one autodest JumpList at a time.  The tool did a great job of parsing the DestList stream on the few files I loaded.  Mark mentioned in the Win4n6 Yahoo group that he changed the functionality of the tool, so that instead of loading the entire compound file, it first parses the DestList stream, and then looks for the numbered streams identified in the DestList stream.  Jimmy Weg reports that XWays now supports parsing autodest JumpLists, including the DestList streams.

I hope that with the information in the ForensicsWiki, and a number of available tools (free and otherwise) supporting parsing of these artifacts, that maybe this will push folks to start looking at these files as a valuable forensics resource.  Since I started posting about Jump List analysis, I've created my own code for parsing these files, including not only the compound files that the autodest Jump Lists are stored in, but also the LNK streams and the DestList stream.  This code allows me a great deal of flexibility, not only to troubleshoot issues with "misbehaving" Jump List files, but also to modify the output into any format I desire (CSV, TLN), either to analyze separately or include in a timeline.  I've seen the value of Jump Lists in forensic analysis, and I hope others begin to parse these files and include them in their analysis.

AutoRuns Update
AutoRuns has been updated to version 11, to include a "jump to folder" capability, as well as several new autostart locations.  I haven't gone through all of them yet, but this looks very promising.


Speaking of autostart mechanisms, Martin Pillion recently posted to the HBGary blog regarding malware's use of Local Group Policy to maintain persistence on a system.  I found the blog post fascinating (it's always interested to see stuff you've seen talked about before), albeit a bit hard to follow in some places; for example, just below figure 4, the second sentence states:

We do this by adding the following line in the section:

What section?  I see the "following line", but for the casual reader (or perhaps someone not quite as knowledgeable in this area), this can be confusing.  Overall, however, this doesn't really take much away from this persistence mechanism.  I mention it here (rather than in its own section), as according the blog post, the new version of AutoRuns does NOT detect this persistence mechanism.

Several other MS/SysInternals tools have been updated, as well, to including ProcDump and Process Explorer.

DFF
DFF RC 1.2 is available.