Didier has released an updated version of an older viewer that he'd written, called InteractiveSieve. Based on the description of the viewer, this looks like an excellent tool for performing timeline analysis.
Here's what I would do...may times, I will want to look at a particular date range, so I would run the parse.pl script to extract just that date range from my events file. I would then open the resulting mini-timeline in Didier's viewer and go about deleting those things that I didn't want to see, and colorize things that might be important, or interesting but not specifically relevant without further investigation.
AppCompatCache
The folks over at Mandiant posted to the M-unition blog regarding the Application Compatibility Cache, which is maintained in the Registry (see their paper). They've released a free tool to view this data, and in less than 30 minutes, I wrote up a RegRipper plugin to parse this data. The first test data that I had available was 32-bit XP, so it's limited, but it's a start, and I think that it really shows the power of open source. I don't say this to take anything away from the efforts of the Mandiant folks...rather, I thank them for their willingness to share the results of their research with the community at large. I provided a copy of the plugin to the SANSForensics team, and gave them permission to post the code via the SANS Case Leads. Rob contacted me with the test results, which weren't good. It appears that the module I use has an issue, which I describe below in the "Troubleshooting" section.
Now, how is this information useful? Check out Mandiant's paper...this particular data source is very rich in data, and I'll be updating the plugins once I get the module "fixed".
Open Source
I had posted to the Win4n6 Yahoo group some thoughts I had on the power of open source tools, with respect to the information Mandiant released. The purpose of the post was not to say, "hey, look at me...I wrote another plugin!!", but rather to demonstrate the power and flexibility of open source tools, and how they can be quickly be extended to provide a capability that might take days or weeks for commercial applications. Andrew provided another example, one that involved extending Volatility during Stuxnet analysis. As someone who's done DFIR work for a long time, I really appreciate having the ability to decide what analysis I will do, rather than being penned in by a commercial tool or framework.
Troubleshooting
Okay, back to the information Mandiant provided regarding the Registry value...one of the members of the Win4n6 group (Ben) sent me a Windows 7 System hive...I have several, which I had opened in MiTeC's WRR and found the value in question to be all zeros...yet Mandiant's free tool pulled a great deal of data from the hive. I checked again, and sure enough, the value in both ControlSets was all zeros. So, based on a suggestion from Ben, I tried Yaru from TZWorks, and found all of the data. I also wrote up a quick Perl script to extract the data from the value and place it into a file; from there, I opened up the file in a hex editor and could easily view the data. It turns out that the issue is that Yaru is apparently the only tool of those I looked at that correctly handles 'db' node types within the Registry. I have attempted to contact the author of the Parse::Win32Registry module about this, in hopes that it's an easy fix.
Registry Unallocated Space
I wanted to see how that compared to regslack, so I ran regslack against the same hive and got a bit different information; I got the same deleted key that Yaru found, plus one other, and I also got a LOT of unallocated space! The web page for Yaru says that finding deleted keys is an experimental capability, which is great...it's also great that someone else is working on this topic. Yolanta's work and release of regslack were a significant milestone for Registry analysis (here is one of my first blog posts on the topic).
The description of Yaru also states that you can view "cell slack", or unused "key value data space"...that's something else that might be very interesting to look into, although I'm not completely clear on what value there may be in data included in cell slack.
A while back, while I was involved in PCI forensic assessments, I used our documented process once I was back in the lab, and my scan for CCNs with an acquired image turned up hits within the Software and NTUSER.DAT hives on a system. I thought that was odd...looking at the data surrounding the hits, it wasn't 100% clear to me that these were actual CCNs; that is, there were no indications that this was track data. So I exported the hives and ran searches across the "live" Registry...and got nothing. It turned out that the CCNs were part of unallocated space within the hive files...so understanding that there is unallocated space within a hive file can mean the difference between saying, "CCNs were found in the Registry", and actually providing accurate information in your report (as it can affect your customer).
Malware Persistence
The MMPC site has a description of Trojan:Win32/Reveton.A,which provides a good deal of information about this bit of ransomware. Apparently, this baddie locks the infected system and displays a warning to the user that they've been reported to authorities as possessing illicit material.
Okay, so what is the persistence mechanism? This one creates a Windows shortcut (LNK file) for itself in the Windows Startup folder. Since the malware arrives as a DLL, it uses rundll32.exe to launch itself via the shortcut.
So what this gives us is some very good info to add to our malware detection checklist, doesn't it? Not only should we check the Startup folders shortcuts (easy check; can accomplish this with a simple 'dir' command), but we might want to get some additional information via Prefetch analysis, particular of Prefetch files that start with "rundll32.exe".
"Community"
There's a new post up over on the Hexacorn blog, and comments are turned off, so I can't comment there...so let's do it here. ;-) Overall, let me say that I find most of the posts here interesting, and this one is no exception, but in this case, I'm only interested in four words from the post:
Like many before me...
I think that what a lot of us loose sight of is the fact that with few exceptions, there's probably someone out there who has faced the same challenges we've seen, and had to deal with the same...or at least very similar issues, as we have. So, when faced with these challenges, we have options...we can seek help, or (if we're racing the clock to get stuff done) we can try to muddle through things and figure things out for ourselves. I've heard people say this...that they want to wrestle with the issue and try to figure things out for themselves...even though there are others willing to help, or material and documentation available. This is very noble, but think about it...is there any wonder why we don't see anything from them about what they learned later? It's probably because they spent so much time wrestling that they don't have much time for anything else.
Recently, Girl, Unallocated gave an excellent DFIROnline presentation that involved a spoliation case and CCleaner. Now, I've had an opportunity recently to work with the latest version of this tool...not in a forensic analysis capacity...so I'm a little familiar with it. However, not long ago, I dealt with a case that involved an older version of WindowWasher. So this shows that in a lot of ways, there are very few "new" cases; that is to say, it's likely that technology aside (XP vs. Win7, for example), there are very few, "This is what I need to determine..." cases.
Need to recover Event Log records (or MFT records) from unallocated space on an XP workstation or Win2003 server? Perform USB device analysis? Determine if that malware on the system actually executed? I'm sure that someone else has run into this before...probably many "somebodys".
So, what to do? Well, we can start by recognizing that if we have a road block, there's a way around it that someone else may already have found. Ask for assistance. It's also helpful that (a) the response not be taken "off list", and (b) that when the dust has settled, there's some final feedback or closure.
Remember, no one of us is as smart as all of us together.
To close this out, I recently had an event that made the issue of "community" clear to me. Back in 2009, I'd written a script to parse Windows XP Scheduled Task/.job files (pull out the command run, the last time the job was run, and the status), and I have it is part of my personal stash of timeline tools. In recent weeks, I had two different people ask me for a copy of the script, which I was somewhat hesitant to do because of my past experience with doing this sort of thing. I decided to give the first person a chance and sent them the script. I was notified that they received it, but getting feedback on how well it worked was like pulling hen's teeth. So the second person came along, and I was just gonna say, "No, thanks" to their request...but they had a compelling need. And they ran into an issue with the script...during testing, I'd never encountered a .job file that had been created but never run. Now, I simply don't have any of those types of files available...but I asked Corey for some help, and thankfully, he was able to provide a couple of files. All in all, the script is working very well, and providing not just some useful output, but it will also provide that output in TLN format. Thanks to Corey providing some sample files, that meant I didn't need to go find an XP install disk, set up a VM, etc., etc., and was able to provide a solution much sooner.
1 comment:
description of Yaru also states that you can view "cell slack", or unused "key value data space"...although I'm not completely clear on what value there may be in data included in cell slack.
From what I understand, value slack may provide previously existing data attached to a value. I took a quick look ay one hive, and the example provides an example:
Direct3D\MostRecentApplication\Name\ wmplayer.exe e lery.exe
In the example, we have key\subkey\value\data plus a string of e lery.exe. The latter is the value slack. I came up with a quick example, but perhaps you can see how this could be helpful, given a better one.
We've discussed this on the list, but the slack is distinguishable from registry free space. The slack is more or less "mechanically" attached to the value cell, kind of like file slack is attached to a file.
Post a Comment