Tools

A couple of tools I've written have popped up on other blogs recently, so I thought I'd link to those blogs here...

Andrew Hoog posted a HOWTO on his eDiscovery blog, which illustrates how to extract metadata from Word doc files, on Linux systems. I really like Andrew's post for a number of reasons, not the least of which is that it highlights both something I wrote and Perl in the same post! But seriously...the format is great, and it's very comprehensive and easy to follow, particularly with respect to how to install the necessary Perl modules to get the wmd.pl script working properly. This script is included on the DVD that accompanies both the first and (soon-to-be-published) second editions of Windows Forensic Analysis. One of the interesting additions to the second edition of WFA is a case study of a time I used wmd.pl's sister script, oledmp.pl, to further my analysis.

RegRipper made it into the SANS Forensic blog in a post by Keven Murphy. Keven's post illustrates how to run RegRipper (the GUI) under WINE, or you can use Daniele's modified version of rip.pl to run that under Perl on Linux.

Just a couple of things that I'd like to mention in order to clarify Keven's post a bit...

First, he's right...RegRipper does use "pre-canned" plugins...just like Nessus. And just like Nessus, the plugins are essentially text-based, so anyone can (and has) open them, read them, modify them, or write their own plugins. In fact, Jason's even created a plugin generator!

Second, to update the plugins, just drop them into the plugins directory...it's that easy!

Thanks for the shout-out, Keven! Glad you like RegRipper, and I'd love to hear your thoughts for modification or improvement. Also, once the book's complete and into publication, I'll focusing my efforts on RegRipper v3!

Over on the RegRipper forums, a RegRipper user posted about how he'd used FTK Imager to extract all of the Administrator user hive files from the XP Restore Points into a directory called "restpts", and then used the following batch script to run a single plugin across all of the extracted hive files:

for /R restpts %i in (*) do rip -p typedurls -r "%i" >>typedurls.txt

This is a great way to do this kind of thing with what you have, but ripXP was designed to do this, and pulls out a bit more information, as well, in order to provide additional context to the information. I know what you're going to say, and you're right...ripXP is not publicly available as of yet...but that's a discussion for another time.

Random Updates

I've been on the road a bit lately, and as such don't really have much info for a single post, but I have a couple of small tidbits that fit nicely when mashed into a single post...

I caught Hogfly's Beware the Key post...in it, he points to this KB article about correcting the "disable Autorun" capability in the Registry. By default, removable storage devices do not (and should not) have autorun capabilities enabled, but preventative measures pushed out via GPOs if necessary are a good thing. Why? Check out this article from India (here from Wired) about an iPod being used to steal data. The usbstor2 plugin for RegRipper was designed just for this type of incident; to help you consolidate data from multiple systems in one place for correlation and analysis. In an infrastructure with dispersed systems, F-Response Enterprise Edition would be extremely useful...I mean, "da bomb-shizzle".

If you do any incident response work at all, you should probably take a look at Didier Stevens' pdf-parser.py Python code. He made this code available from his blog post on analyzing a malicious PDF file. This can be used to narrow down the attack vector for an intrusion or malware on the system.

I've posted about free tools before (here, as well), and one that I wanted to add was a free, open-source AV scanner called MoonAV. If you're looking for other free tools, I'd suggest staying up on the NirSoft Blog, just like Claus. There are a number of very, very useful freeware utilities at NirSoft and more coming soon.

With respect to open-source AV, there are some other interesting, older links over at the OpenAntiVirus project page, as well.

Christine updated the e-Evidence site today! This is the closest thing to a monthly digital forensics e-zine available! Be sure to bookmark this site and check it out regularly.

New Tools

Thought I'd take a page from Claus's book and update everyone as to some new tools that are available...

First, over on the Volatility Tumbleblog, there's mention of two new Volatility plugins that Jesse Kornblum developed for use with Volatility. Also on the same blog is a link to a tool to search memory dumps for GMail artifacts. Both look like exceptional utilities.

Speaking of Claus, be sure to check out the updated browser analysis tools over at NirSoft. Claus is also the one who pointed out that AutoRuns has been updated. Thanks! AutoRuns a great tool to use in IR, and to keep up to date on autostart locations.

Brian Carrier updated the TSK tools to v3.0, which includes the Windows versions of the tools. I've updated my own regtime.pl script to produce output similar to that of fls, so that the output of the script can be appended to the output of fls, and parsed with mactime to produce a timeline of file (and now Registry) activity on a system. At this time, only the path and mtime fields are populated for Registry keys, as the LastWrite time is analogous to the last modification times for files. With the currently available tools, deleted keys can be added to the list. I'll need to update the plugins to have RegRipper and rip produce the same output, which would be more targeted (and perhaps more valuable) than dumping all of the keys.

Forensic Analysis Applications

As a forensic nerd, I'm familiar with...either directly or indirectly...a number of tools. Like most folks, I try not to be specific to a single tool, but rather understand what I need to do, and then select the appropriate tool for the job. I've used EnCase (going back as far as v.3), FTK, ProDiscover, and recently I've had an opportunity to work with X-Ways Forensics. I have access to SMART and MacForensicsLab, although I can't admit to having used either to a great extent. I've also seen PyFlag in action, and at one point (several years ago) I even installed TSK/Autopsy on a Dell Inspiron 5150 laptop running Windows.

Before I go any further, let me say that I'm separating data collection from data analysis. If anyone's read my books, you'll know what I'm talking about. When discussing functionality in a forensic analysis application, I'm not going to be discussing the applications ability to acquire data (ie, an image)...only to present it. A great example of this is Matt Shannon's F-Response...Matt has focused solely on allowing incident responders to collect data in a vendor-agnostic manner, allowing them to use any tool they want to acquire an image from a live system.

That being said, all of these tools are just that...tools...and each has it's own strengths and weaknesses. I won't go into detail on that here, because to be honest, at some point, these things really start to become a matter of perspective. By that, I mean that I do certain kinds of analysis...intrusions, breaches, suspicious activity, etc...and I don't do other kings of work (ie, CP). Some tools are great for certain types of analysis and the folks who use them know how to navigate the application to perform those functions really well. Each forensic analysis application provides the user with a layer of abstraction of the data, as well. While the examiner may see the hex data that corresponds to the contents of the image being analyzed, she may also see things like the volume identifier, drive letter, file structure, and icons representing files and directories...all of which are abstraction layers that present and represent the data to her.

However, I don't feel that I'm completely limited by these forensic analysis applications. In many cases, I may have a need that I can fulfill by either using another tool, or by creating my own tools. For example, I do a considerable amount of Registry analysis when analyzing a Windows system. As such, Registry Viewers similar in function to RegEdit don't offer me a great deal of functionality. This is why I wrote RegRipper...and it's also the reason I've written other tools (like the ones on the DVD that ship with my book).

Working with these applications, I've found that in many ways, they're all vastly different...different in the capabilities they provide, and especially different in how you would go about getting them to perform a certain function and then display the results. Most applications abstract packages of data as 'cases' and that's great...each has their own way of requesting and storing the case-specific (examiner, date, etc.) information. Then try just adding an image file to the case...I think you can see where I'm going with this.

The issue I see facing us, as a community of forensic examiners, is that we're making our own jobs harder through complexity. I say "our" because as (heavy) users of forensic analysis applications, we should take it upon ourselves to provide input and feedback to the developers of the forensic analysis applications. We're facing the same issues we always see...storage media is increasing in capacity, data (aka, "evidence") can now be found in more sources and formats (cell phones/PDAs, physical memory/RAM, email .PST/.NSF files, etc.), and the forensic analysis applications themselves are adding to the complexity itself. There's more and more available data to analyze and it appears to me (via my own experience as well as viewing public and vendor lists/forums) that the design of forensic analysis applications is adding to the overall complexity, making it harder to get to the data presentation and reduction that is so important.

My thought is this...a forensic analysis application needs a core set of functionality and capabilities. Beyond that, additional functionality can be added through plugins or modules, as well as scripting capability via an extensive and usable API. A forensic analysis application should be a data presentation application...actual "analysis" needs to be done by the examiner or analyst themselves.

Core Functionality
- Stability - 'nuff said!
- Simplicity - again, this is all relative
- Be able to open/add/import standard and the most popular image file formats
- Be able to recognize and present a wide range of file systems
- Searches (grep/regex, keyword, filename) across all files, including inside files such as archives (zip, bz2, rar, etc.)
- File type/signature analysis
- File Carving
- Timeline creation
- Ownership/permission searches
- Hash creation/comparison
- Image viewing (aka, "Gallery View")
- Segregation of data between 'cases'
- Extensibility (via scripting API, and separate plugins)

This is just my list of core capabilities for forensic analysis apps, and shouldn't be construed as being comprehensive. Like I said before, there are going to be examiners who heavily rely on the Gallery View available in most forensic analysis apps for what they do...and there are going to be examiners (like me) who will start an examination by opening the 'case' and extracting certain files for detailed analysis. It's all a matter of what you do, and your personal preference.

Being a forensics nerd, I do understand economics. I do understand why some forensic analysis apps are designed the way they are...there is money to be made through providing training and support by making your application proprietary. There are forensic applications available and in extensive use for which the training is more about how to navigate the GUI rather than actually do productive work.

Don't get me wrong here...all I'm saying is that IMHO, I'm seeing certain aspects of what we do, and how we do it, as a "community", and I'm thinking...wow, can't this be easier and more straightforward? Shouldn't it be possible to get an analysis application that is stable, presents the data in a straightforward manner, and allows me to perform certain data reduction functions easily and accurately? Instead, why are we faced with applications whose interfaces become more complex and less easy to navigate between major releases, and at the same time loose or break major core, underlying functionality at the same time? And why are we charged thousands of dollars more for this new version? What's the focus here?

My goal here is neither to make forensic analysis so easy that a caveman could do it, nor to make so difficult that only a very select (genetic mutations) few could do it. I simply think that we've gone so far afield with the development of these applications that we've lost sight of what's actually necessary. I'd love to see a forensic analysis application that for one price comes with a core set of functionality (see above) for one price, and is simple and stable, and can be extended via a simple scripting API. Beyond that, include an a la carte menu of plugins or modules that will NOT increase the complexity of the application but instead simply add to its capabilities. For example, say an application that presents the file system within the image in an Explorer-style interface, and then a plugin that will allow the examiner to add .PST files to the case, open them in a similar style interface, and also allow the contents (including attachments) to be viewed, searched, etc...all without crashing the main app.

...or am I just completely out of my mind here?

Process-to-port Mapping

During first responder activities, be they simple troubleshooting or incident response related, one of the important pieces of information that can really provide some insight into the behavior and status of a system is process-to-port mapping.

Why is this information important? Well, it really depends on what you're looking for, but if your initial indicator or notification of a potential security incident is "unusual traffic" originating from a system, then you'd want to know what process was generating that traffic...right? After all, there are a couple of truths you need to keep in mind when troubleshooting or performing IR activities. One is that network traffic never spontaneously emanates from a system without a cause...there's always some process involved. Another is that nothing happens on a system without some code executing as part of a thread/process.

Okay, moving on...

With NT, getting process-to-port mapping information wasn't easy. You had to use a tool like fport to get the information. The same was true for Windows 2000, and it was really cool that as of XP, netstat.exe had the '-o' switch added so that you could get the network connections with the associated PID all on one line (this is great for scripting! =) )

Many folks may not be aware that there was an update to Windows 2000 that added the '-o' capability to netstat.exe on that platform. If you've got Windows 2000 systems, this is a great update to add, so that (as an admin) you have the capability to get the information you need.

Another tool you can use to get this information during IR activities is tcpvcon. I prefer this tool because it can be included in a batch file (reducing overhead), and the output can be sent to .csv format, which is great for parsing with Perl scripts.

Analysis Tip: One of the things you might run across during an engagement is working with admins who are network-centric...or being one of those network-centric admins. For example, you may get some indication of an issue from traffic captures, or IDS/IPS/firewall notifications or logs. In such cases, you very often have a couple of pieces of information available to you, one of them being the source IP of the traffic, which you would likely use to locate the system from which the traffic originated (assuming that it wasn't spoofed). But guess what? You will very likely also have the source port for the traffic...and this will information (if you don't ignore it) may assist you in identifying the process from which the network traffic had been generated. Something as simple as "netstat -ano | find " may be all you need to do to find the process that generated the traffic.

How is this important? Well, one more than one occasion, incident responders such as myself have encountered those who've said, "...we saw some unusual traffic, found the system, and scanned it with [insert AV product name], and found a virus." In such cases, there may be no correlation whatsoever between the traffic and whatever the AV product found (could've been a DLL or a Registry key...) - this is "incident response by assumption/speculation", which is about as bad as "security through obscurity".

Jesse rides again!

Jesse Kornblum has done it again! Jesse's one of those guys who releases some really amazing tools for use in the IR and forensic analysis space, and he's done it again with "Miss Identify".

Miss Identify is a tool to look for Win32 applications through the use of file signature analysis. By default, it looks for Win32 apps (per the PE header) that do not have executable file extensions. As with Jesse's other tools, Miss Identify is rich with features, all of which are configurable from the command line.

So, you're probably thinking...okay, so what? You can already do this sort of thing with other tools, right? What makes this tool so Super Bad, McLovin?? Well, right now, there are a number of ways that a forensic analyst can identify malware in an acquired image, including checking the logs of any AV app that is already installed, or mounting the image and running an AV scanner or hash set comparison tool. However, two issues arise with these approaches...one is that there are legitimate tools that can and are used for malicious purposes. The other is that signatures (AV signatures, hashes, etc.) don't always work. However, there is one thing that all malware must be, and that is executable!

Miss Identify can also print strings that are found in the files, as well. This is great because you may find an executable file in the system32 directory that has a Microsoft-sounding name, but does not contain the MS copyright info embedded in the resource strings. This would be a "clue".

The use of Miss Identify doesn't replace other analysis and data reduction techniques, but instead augments them. This is without a doubt a useful tool, and one that should be considered for use by all sysadmins, first responders, as well as forensic analysts.

A round of applause for Jesse, everyone!

Also, I love the "Hollywood teaser" Jesse used to let everyone know what was coming! Speaking of teasers, isn't IronMan coming out soon....? Can you think of a better way to get Marvel Comics and Black Sabbath to come together??? ;-)

Addendum: I reached out to Jesse and mentioned to him that it might be useful to parse out the file version information from an executable, rather than all of the strings. Also, reading through the comments to Jesse's blog, there are some very useful tips pointed out...for example, finding an executable file in a user's browser cache might be considered by some examiners to be a "clue"... ;-)

Interesting Tool - SecInspect

Now that my book has been released, I'll be posting updates, errata, and comments here in this blog. Some of the updates will include things such as tool updates, as well as "From the Lab" entries (sort of mini-HowTos), comments, reader questions, etc.

One interesting tool I ran across recently on HogFly's ForensicIR blog is something new from Microsoft called "Sector Inspector". Secinspect.exe is a command line tool (ie, great for IR and live response!!) that lets the sysadmin view things such as a list of physical devices, drive geometries, disk signature and volume serial number, etc. Now much of this is available through WMI classes such as Win32_PhysicalMedia, but secinspect.exe may be much easier for many folks to use, particularly if you want to include it as part of your drive documentation process (ie, hook up a drive to your write-blocker and then collect data on it using secinspect.exe prior to or immediately after acquiring an image).

An excerpt of what secinspect.exe collected when run on my own system:

Target - \\.\PHYSICALDRIVE1
14593 Cylinders
255 Heads
63 Sectors Per Track
512 BytesPerSector
12 MediaType
[snip]
Disk Signature 0x96244465

Also, for each partition, you see information such as:

SerialNumber : 10675897970943624920

Note: You can also use this with USB thumb drives.

Cool stuff!