Showing posts with label ADS. Show all posts
Showing posts with label ADS. Show all posts

Friday, September 23, 2011

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.

Wednesday, June 11, 2008

NTFS Alternate Data Streams

NTFS Alternate Data Streams (ADSs) have been around since the dawn of...well...NTFS. Windows OSs ship with plenty of tools to create (and execute) ADSs, but the cool thing is that until Vista came along, there were not tools provided with the Windows operating systems that allowed you to see arbitrary ADSs that had been added to your system.

Caveat: There are some tools that do allow you to see specific ADSs, but those are only in very specific instances. Even Windows systems themselves make use of some specific ADSs, as well.

And, yes, you heard me right...from NT up through Windows XP and 2003, someone could create arbitrary ADSs on your system, using tools on the system...but there are no tools that ship as part of the OS that allow you (as an admin) to find and/or view these ADSs. On Vista, you can use dir /R to view arbitrary ADSs.

An interesting kicker is that ADS can not only be attached to files, but directory listings, as well, using the same command line syntax, with a slight alteration...

D:\>type c:\windows\system32\calc.exe > d:\ads\:calc.exe

Running tools such as LADS (from Frank Heyne, see below) we see that the ADS is indeed attached to the directory listing. We can launch this executable using the same syntax as was used to create it:

D:\>start d:\ads:calc.exe

Pretty sweet, huh? This is how tlist.exe sees it:

2640 ads:calc.exe Calculator Command Line: "d:\ads:calc.exe"

You see pretty much the same thing in Task Manager, as well.

This topic is covered in both of my books...Windows Forensics and Incident Recovery and Windows Forensic Analysis. From these resources, you can see that ADSs can be used to "hide" files and data, but also be used as a repository for executables, as well as scripts.

Resources

My original paper, The Dark Side of NTFS
Frank Heyne's LADS
SoftCorp scSTREAMS
Rootkit that uses ADSs
WindowsIR on ADSs