Links

If you're at all interested in steganography, including not only the technology but also available tools, you should check out this paper from a couple of folks at GMU (from 1998). This led me back to the JJTC site, where you can find more publications and tools. Gary Kessler also has an Overview of Steganography for the Computer Forensics Examiner, which is another good read and definitely helps in understanding the strengths and limitations of the technology. From talking to LE, for the most part steganography is considered when there are indications of such a tool being used; indications can come from artifacts such as Prefetch files, MUICache Registry key entries, contents of emails, or just the existence of a known stego tool on the system.

Working on some of my timeline analysis stuff recently, I went looking for some tools to handle certain file types (or for information on formats so I can write my own), and ran across JAFAT again. I say "again" because I took a look at the INFO2 file parser a bit ago, and I see not only the cookie file parser, but also the Safari tools on the Archive of Forensic Tools page. There's a package available for the tools to run on Windows, if you need it.

Speaking of working on stuff, now and again I get questions about how to determine the edition of Windows from an image (NOT version...edition); ie, Windows XP Home vs. Professional. I've addressed this here in this blog, but after spending some time recently looking for another solution, I thought I'd ask you all...the OSVERSIONINFOEX structure contains a field called SuiteMask; does anyone have any information on how this might be populated so that it can be replicated during post-mortem analysis? I already know how to populate most of the other fields and determine what version of Windows (and Service Pack) is installed, but the one field I haven't been able to find any information about is the SuiteMask. While this appears to be used quite often on live systems to perform checks during installation procedures, I'm having a great deal of difficulty determining where this information might be found within an acquired image.

Addendum: This page from Geoff Chappell pretty much covers what I found with respect to populating the SuiteMask field. Specifically for XP, in order to determine MediaCenter and TabletPC editions, check for the System\WPA\name Registry key (name = MediaCenter or TabletPC) with an Installed value equal to 1.

The Illustrious Don Weber is back to blogging again, this time about AV and Linux...good stuff, as always!

If you've got a copy of Windows Forensic Analysis 2/e, go to chapter 9 and add this link to open-source forensic tools to the last page. Thanks, Claus, for the heads-up on this one...

Jamie Butler's added a new post to Mandiant's M-unition blog, this one about finding a keylogger through the use of the XPath filters in Memoryze. This is definitely worth checking out, as it allows a user to extend the tool's capabilities through scripting, just as you can do with Volatility and RegRipper.

Links and Stuff

The Forensic 4Cast Awards (live video-cast) were posted at the end of the last week; a huge thanks to everyone who submitted nominations and voted, and thank you to those who voted for me in the Best Digital Forensics Blog and Best Digital Forensics Book categories! Watching the video, it looks as if Lee and Simon had a great deal of fun creating it, and I hope that they follow it up next year! Maybe some folks can contribute prizes...nothing fancy, just something simple.

Over on the RegRipper forums, Ken Pryor had this to say about the recently released RipXP (quoted with permission):
I finally got time to try it out today and must say it's a brilliant piece of work. I have immediate use for RipXP for a case I'm working on. Harlan, I thank you for all you do for us. I would gladly pay for RegRipper and RipXP and I am very thankful you provide them. I haven't worked a case yet that RegRipper didn't play a part in and I expect RipXP will be much the same.

Thanks for the words, Ken!

James Macfarlane has released an update to the Parse::Win32Registry Perl module that is the basis for such tools as RegRipper and RipXP. The most notable change to this version of the module are the ability to extract and view security descriptor information.

James has also updated some of the scripts included with the module. Rather than trying to describe them in my own words, I'll use James':

regshell.pl is a new interactive console program for browsing registry files. It is a little simpler to use than regdump.pl as it provides tab completion if you have a functioning Term::Readline. It should work on Windows. (Note: ActiveState includes Term::ReadLine::Perl and Term::ReadLine::Zoid on Windows)

regview.pl has been improved to include searching and bookmarking.

regmultidiff.pl is a new console program for comparing multiple registry files. It improves on the old regdiff.pl by allowing the comparison of an unlimited number of registry files.

regcompare.pl is a new GTK+ program for comparing multiple registry files.

If you're using ActiveState's Perl on Windows, you can install this module via PPM:

C:\Perl>ppm install parse-win32registry

If you already have it installed (ie, v. 0.41 or earlier) you can upgrade the installation:

C:\Perl>ppm install parse-win32registry

I have to say, from my perspective, James has made a HUGE contribution to the forensic community! Many, many thanks, James!

Speaking of tool releases, Paraben has released their P2 eXplorer image mounting tool for free! You can download the demo, but you have to "purchase" the free product (and yes, submit a credit card number), but once you receive the registration key, you can activate the full features of the product. I've played with it a little bit, and I think that having access to tools like this that provide a single, needed functionality at a reasonable price point (free, in this case) can really do a lot for the community. While the interface isn't entirely intuitive (who uses A:\ and B:\ any more??), the only other things I really don't like are the rotating banner ads for other Paraben products on the right-hand pane on the interface, and the inability to completely disable the generation of MD5 hashes for images that are mounted/unmounted...I'd rather see something more obvious in the tool about read-only functionality. However, P2X does generate a log of activity, so that's nice to have and include in your case notes. All in all, a good, commercial grade replacement for ImDisk and VDKWin. P2X also allows you to mount other image format types besides raw, dd-style formats, such as EnCase, SMART, SafeBack, etc.

If you use Volatility (if you don't...why not!?!), then you really need to take a look at some of the new plugins posted by Michael Hale Ligh. Some look like they'd be extremely helpful in detecting malicious goings-on...very cool, and thanks to MHL!

More Perl-y goodness

I've uploaded a new script (handle.pl) to the files section of the Win4n6 Yahoo group...this is a script I wrote this morning to process the output of "handle -a" (collected during live response), based on a couple of things mentioned by Kris Harms and Pete Silberman (both of Mandiant) during the SANS Forensic Summit.

The script extracts, parses, and lists all entries for "pid:", which is something Kris mentioned during his presentation is a means of collecting the same information (ie, process listing) using a disparate means (ie, different API calls). After completing this iteration of the script, I figured that the next version will include additional processing of other items.

The script also processes the output for mutants and displays them all based on the "frequency of least occurrence". Pete mentioned that malware is (should be) the least frequent thing to occur on a system, and malware authors are using mutexes to ensure that infected systems are not continually infected over and over again. Many times, these mutexes are random names, whereas they usually appear as easily readable strings in most cases.

So, during live response, should the responder opt to run "handle -a > handle.log" as part of a batch file, the resulting output of the command (ie, handle.log) can be quickly and easily parsed using scripts like this. Also, this acts as a force-multiplier, in that the knowledge developed by a few is made easily available to many. Seriously...how often do you hear someone say, "...find interesting or suspicious processes..." with no mention of what constitutes "interesting" or "suspicious"?

Thoughts?

Addendum, 20090720: I've updated the handle.pl Perl script to include include some disparity checking in processes (searches for PIDs vs process/thread handles), etc. I see this script as being extremely useful and very valuable for performing some automated parsing and analysis of collected data, as codifying the "rules" for initial processing of the data allows for the use of automation as a force multiplier and error reduction technique. I can also see how it would be useful to add Least Frequency of Occurrence (LFO) checking for other (Event, Device, File, Key) handles, as well as process listing disparity checking against the output of other process listing tools (ie, pslist, tlist, etc.)

Update on USB Devices

I posted to the Win4n6 Yahoo Group on USB removable storage devices and tracking connections, and got some really good confirmation from Rob Lee, so I thought I'd share it here, as well.

So, when I was writing WFA 2/e, I did some testing and found that when connecting a USB removable storage device to a system, beneath the unique instance ID key (under the DeviceClasses key), a Control subkey was created, and when the device was disconnected, the Control subkey was deleted. The creation/deletion of this subkey constitutes a modification to the unique instance ID key, updating the key's LastWrite time and allowing us to track the usage of the device.

However, there appear to have been changes to this functionality since then, and Rob's more expansive testing has confirmed my own. Essentially, if you sit down to a running system (XP SP2 or 3, Vista, Windows 7), and plug in a USB removable storage device (even one that's been previously connected to that system), you'll see the Control subkey created...but when you disconnect the device, the Control subkey will remain until the system is rebooted. Rob has confirmed that this LastWrite time survives logins, as well.

So, now the LastWrite time on the unique instance key refers to the time that the device was last connected to the system, which is an important distinction to make when performing analysis of the usage of these devices. This requires further testing for more complete confirmation, but this is how things appear at this time. Shout outs to Rob Lee for the testing on this!

SANS Summit Question

During the recent SANS Forensic Summit, there were a number of questions handed to Rob during the panels that went unanswered due to time constraints. After the IR panel, I took a look at some of the yellow index cards with questions and grabbed one in particular to answer. The question I found was (no author info was available):

What is the worst thing an IR team internally will do?

As I kept thinking about this, I kept coming back to two answers...either do nothing at all, or do too much of the wrong thing. Now, I'm assuming with my response that an incident has been detected, the IR team has been called into action, and some kind of response process has been initiated. At that point, you very likely have something that occurred to indicate that there is an incident, so you may very well have sensitive data being actively exfiltrated from the environment, so doing nothing at all could be extremely detrimental/harmful to the organization.

On the other hand, grabbing systems, running AV scans, deleting files, even wiping systems and reinstalling them can also be harmful to the organization. In a typical breach situation, the questions that need to be answered are:

1. Was the system compromised?
2. Did the system contain some kind of sensitive data?
3. Did "yes" to #1 lead to the exposure/exfiltration of #2?

If you destroy the indicators or "evidence" of what occurred, and cannot therefore determine the answers to these questions, where does that leave you? If you're just re-installing everything with no idea of the attack/infiltration vector, how do you protect yourself in the future? Heck, how do you even know that you fixed the issue, particularly if you have no idea how long the bad guy or their malware have been on the systems? You may be re-installing the malware itself!

So then I thought to myself, why do IR teams (both internal and external) do this sort of thing? In my experience, a lot of times it has to do with assumptions that are made...very often, incorrect assumptions. Due to lack of knowledge, skills, tools, and/or training, IR teams are very often under the gun to provide answers to management, or just get things working again. If you don't know what to look for, it's simply easier to make assumptions without any hard data and proceed on from there. I mean, really...if you destroy the data, who's going to be able to question you? I'm not saying that this is being done maliciously...what I am saying is that I have seen both internal IR teams as well as consultants make some very unfounded SWAG statements about an incident with no data to back them up, and proceed on from there. Very often, I'll just stand there, shaking my head, as they charge off into the sunset.

So, what's myanswer? The question was about IR teams, and not specifically management...so I'd have to say that, IMHO, the worst thing an internal IR team can do is NOT take it upon themselves to develop their own knowledge and skill sets. "I don't know what to do because management won't send me to training" should be an indicator that you've got the wrong people on your team...both for internal teams as well as consulting companies that provide response services. Not everything is going to be included in a class, and having to sit in a classroom to learn something means that the team member (or members) are unavailable for that time. More importantly, if you do get the opportunity to attend a class, but are unable to process the information and use it in your environment, that basically means that you got a nice paid vacation...and to be honest, I'd much rather have one of those some place other than in a classroom!

In summary, the worst thing an IR team can do is not learn from their mistakes, and not take it upon themselves to expand their skill sets and improve their processes.

Thoughts?

Links and New Stuff

The MalwareForensics site, based on the book by the same name, is up and running...pretty nice so far. If you're involved in incident response, malware analysis, or just IT in general, you should check this site out. It has links to Linux and Windows tools, as well as to web-based tools.

Tools available with the DVD that accompanies Windows Forensic Analysis allow you to view metadata within MSOffice documents up to the point where MS ported the document format from OLE over to OpenXML. Well, this post on the SANS Forensic blog takes that step forward and shows you how to extract metadata from within Office 2007 documents. Even cooler, the code is written in Perl!

Another tool, albiet not written in Perl, is Security Database's Evidence Collector. The span of data collected looks to be pretty useful, and the UI is different from anything I've seen before. If you're an incident responder in a small shop, you might want to take a look at using a tool like this.

In case you missed it, I recently released the current iteration of my ripXP tool, a small tool that is part of the RegRipper set of tools. RipXP uses the same plugins as RegRipper, and will run each plugin not only against the designated Registry hive file, but also against all of the corresponding hive files within XP System Restore Points! This is extremely useful for a couple of reasons, the first of which is that Registry keys have LastWrite times, which are analogous to file last modification times, but we very often don't know what changed. RipXP will allow you to parse through the Restore Points to see a historical view of the data. Second, ripXP also includes a small bit of code that parses the rp.log file to report not only when the Restore Point was created, but also the reason why it was created, potentially adding a significant amount of context to the data itself.

There's some new fun floating about the Internet, exploiting a vulnerability to the MS Video ActiveX Control, msvidctl.dll. There's been info posted on this issue:
SANS ISN
Terminal23
MS Security Research and Defense

Others have posted intel about what happens after the exploit:
FireEye Malware Intel Lab

It appears that the way this is working is that the bad guys first compromise web sites, and then redirect users to sites where the exploit resides. The exploit then occurs through the browser (MS refers to this as "browse and get owned"...comforting) and additional malware (such as an online gaming password stealer) is downloaded.

So why am I talking about this? This is yet another example of how all of the available information about this stuff is vulnerability-based, and there's really very little information available as to what this looks like on a system once it's succeeded. The MS SRD site lists some mitigation steps such as setting the kill bit in the Registry that can be used to determine if a compromised system was susceptible to this sort of attack, but the fact is that there is little information available regarding what to look for to determine if the system was compromised via this particular exploit.

More later, folks. As always, comments and suggestions are welcome...

Windows Registry Forensic Analysis

Based on some comments I received from folks who reviewed WFA 2/e, I am strongly considering writing a book on Windows Registry Forensic Analysis...and I'll probably use that as the title! ;-)

I'm working on a proposal now, and one of the things I'm doing is including those things from previous books that have been successful...in particular, writing style, use of demonstrations, short case studies, and generally trying to show how this information can be used to further an investigation. My goal is to be a thorough as possible, providing information on format and structure, how to monitor the Registry, and provide as much information as I can with respect to keys and values that are (should be) of interest for examinations.

One of the issues I'm sure I'll run into is that same one I've run into with respect to WFA 2/e...there are folks out there who expect certain things to be in the book, but don't (a) realize that I can't do everything without assistance, or (b) don't voice that expectation until after the book is published.

So, here's your chance...if you were shopping for a book on Registry Analysis, what would you be looking for with respect to content?

I've already received emails from folks who say that they're looking for information on P2P applications, without saying which ones. There's already information available on a lot of topics such as P2P artifacts, and I understand that part of the problem is that this information isn't all in one place...but the way to make things like this a real success is to get input from folks in the community. As was discussed at the Summit last week, there really hasn't been a great number of requests for plugins or anything over at the RegRipper site...

SANS Forensic Summit

I spent all day last Tuesday in downtown DC attending the SANS Forensic Summit...it was totally awesome and well worth every second I was there.

First, a HUGE thank you to Rob Lee for setting the Summit up and inviting me and all of the other speakers, and an only slightly-smaller thank you to all of the folks who attended and made the Summit the success that it was!

Now on to the Summit itself...

Presentations
Richard
Richard Bejtlich gave the keynote address which was very entertaining. Richard is a dynamic and informative speaker, and has some very well thought-out and articulated views, and he's definitely someone worth listening to, even if you don't necessarily agree with everything he says. Unlike Ken Bradley, I don't work for Richard, so I can say anything I want! ;-) Seriously, though...Richard is truly one of the thought leaders in the industry, and definitely someone worth listening to.

Kris Harms
Kris had some great things to say as an incident responder for Mandiant. As a responder, for me, it's great to see other folks in the industry, listen to their presentations, and talk to them about what they're doing, and how they're addressing those problems that we all run into. Many times you'll pick up things that you didn't know, and other times you'll get validation regarding some of the things you're doing when you get a chance to see how others are addressing those same challenges. Kris and the Mandiant crew have a great deal of experience with APT, or advanced persistent threat, so if you get a chance to pick Kris's brain on the subject, do it.

Jamie and Peter
Jamie and Peter, both also from Mandiant, had some great things to talk about with respect to memory analysis, with a specific focus on malware detection. If you haven't really looked at it, you should definitely consider looking at Memoryze and AuditViewer.

Brendan
Brendan's presentation on analyzing Windows Registry hives extracted from a memory dump was a great piece of work! My (top)hat's off to Brendan on the work he's done to extend the work put into tools such as Volatility and RegRipper. Who knew you could grab a memory dump from XP, and the using open source tools, extract the password hashes which you can then crack using your tool-of-choice?

Panels
The panels are a summit/conference format that Rob uses to great effect. I first encountered this sort of technique at Aaron's OMFW last year, and Rob has included it at the Summit. Several folks from a particular field (I was on the IR panel) each give short presentations, and then the floor is opened for questions which Rob filters so that things keep moving. This is a great way to do two things; first, to really push through some varying views in a short period of time, and second, to open up discussions that continue between individuals later, during breaks or even over email after the summit is over.

PodCast
Ovie and Bret were nice enough to invite me, as well as Rob Lee, Ken Bradley, and Jesse Kornblum to take part in the live recording of the CyberSpeak podcast, which was a LOT of fun...as I'm sure you'll be able to tell when you listen to it.

Hey, don't listen just to me...Chris and Matt have posted their impressions of the Summit, as well.

Tips
One of the things I picked up from Kris Harm's talk was a great tip on a means for doing differential analysis of volatile data. Most of use are familiar with the use of pslist to get process information, and how to analyze the information that we receive. I tend to combine that information with the output of tlist, as well as other tools (netstat, etc.) to develop an overall picture of what was happening on the system. What I picked up from Kris is that grep()'ing through the output of handle.exe, you can look for "pid:", which provides you with yet another means of locating processes. The same technique can be used for malware detection, by looking for mutants/mutexes (mentioned by both Kris, and his cohort over at Mandiant, Peter Silberman) using something called the "least frequency of occurrence" (thanks, Peter!).

User Account Analysis

Something I picked up on recently (albeit not directly at the SANS Summit) was how to determine if a password had been set on a system, when all you have is an image to analyze. Brendan has provided tools to use with Volatility to extract Registry hives from Windows XP memory dumps, and subsequently to extract hashes, but what if you only have an image of a system? Well, one of the user flags extracted by the RegRipper samparse plugin is "Password not required"...now, this does NOT mean that the account doesn't have a password.

What I got from someone at MS is as follows:
That specifies that the password-length and complexity policy settings do not apply to this user. If you do not set a password then you should be able to enable the account and logon with just the user account. If you set a password for the account, then you will need to provide that password at logon. Setting this flag on an existing account with a password does not allow you to logon to the account without the password.

Another thing you can do is extract the System and SAM hives and run them through SAMInside. If you like CLI tools better, try using pwdump7...it's got the same functionality.

Where something like this won't work is when the system is accessed by domain users, as their user account information isn't stored in the local SAM hive file.

RipXP Released!

I've decided to release RipXP, which I've demo'd at both SANS Forensic Summits, as is. Go to the RegRipper site Downloads section, and you'll see it. Be sure to read the instructions in the zipped archive...

SANS Forensic Summit 2009

I'm really looking forward to getting to the SANS Forensic Summit tomorrow! This is a great place to meet, listen to some great presentations, and to chat with folks from various fields (LE, FTE, corporate consultant, etc.) in the industry. My hat's off to Rob Lee for pulling this fantastic event together!

Per the Summit agenda, I will be on the IR panel in the morning, and then giving my Registry Analysis presentation at 1pm, right after lunch. When I was teaching at TBS while I was on active duty in the USMC, we used to call this "the death hour", so I'm going to address this urge to nap after lunch with several live demos, as well as a surprise at the end of the presentation!

But that's not all! There's more! Check out who else is attending...Mandiant is well represented at the conference, and Chris Pogue will be there, as will Eoghan Casey. Chris and Eoghan are fellow Syngress authors, so be sure to swing by the Syngress table at the Summit, get a copy of their books, and then hunt them down to have them sign them for you!

There's a rumor that Troy Larson of Microsoft will be there as well...but I have to tell ya, while I've heard the guy's name and been told that he's been on conference calls, I've never actually seen the guy! As far as I know, Troy is the yeti of the forensics community! ;-) Hopefully, he'll turn up sometime before the live recording of Ovie and Bret's Cyberspeak podcast.

While I only plan to be at the Summit on the 7th, there are a LOT of great speakers and panelists who are going to be there, and this is definitely an event that anyone who can attend, should! Without question! Where else are you going to be able to have so many giants of the forensics community together in one place, from various areas (corporate, federal gov't, LE), and covering so many pertinent topics (memory analysis, courtroom preparation, etc.)?

And if you have a Captain Picard fetish and have a "thing" for bald men, this is THE place to be in DC! ;-)

The Case of the Missing MFT Entry

A bit ago, I received an email from someone mentioning the following facts with respect to an examination they were doing:

- Malware was suspected as having been running at one point on a Windows XP SP2 system
- A Prefetch file was found the related directly to the malware
- AV logs indicated that the malware had been deleted
- An XP Restore Point included an INI specific to the malware
- Between the time that the malware had been deleted and the system imaged, 8 Restore Points were created

Given these facts, the question was...why does there appear to be no MFT entry for the malware file?

I responded with my answer...I want to know what YOU think.