Where was Waldo?

I was talking to some really, really smart folks last week about some things you could do with data that resulted from computer forensic analysis, and the topic of geolocation came up. I had some ideas, and when I returned from my trip, I started taking a look into how I could use historical information derived from an acquired image to perform geolocation. I sat down yesterday...it was rainy, so it's a nice day to code...and worked up a proof-of-concept that came out quite nicely.

So basically, here's how it works....during the course of an exam, you may determine that the system was used to connect to multiple wireless access points (WAPs). As discussed earlier, there may be more than just the SSID of the WAP recorded in the Registry...for example, the MAC address of the WAP is also recorded. Pretty neat.

So what? So you have a MAC address...what would you do with this information? Look up the vendor? Well...that's a start, as it can help you confirm that you do, in fact, have the right type of device. But in a few easy steps, you may be able to find out where that WAP is physically located. I put heavy emphasis on may because this isn't a 100% done deal...but it is way kewl nonetheless.

So the steps go a little something like this...

1. Run RegRipper (or rip or even ripXP) against the Software hive to get the SSID and MAC address of the WAP, as well as the last time the WAP was connected to. For XP systems, the updated ssid plugin is what you want to use, and for Vista and above systems, I wrote a plugin called networklist.

Note: There's a date associated with the SSID within the binary data of the Registry value on XP systems...however, I have no idea what this date means. On Vista systems and above, the MAC address has a distinct value (ie, does not need to be stripped out of a binary data stream), and a date/time stamp that indicates when the WAP was last connected to.

As an example, here's the data I retrieved from an XP system:

Launching ssid v.20090807
SSID
Microsoft\WZCSVC\Parameters\Interfaces

NIC: 11a/b/g Wireless LAN Mini PCI Express Adapter
Key LastWrite: Thu Feb 7 10:38:43 2008 UTC

Wed Oct 3 16:44:25 2007 tmobile MAC: 00-19-07-5B-36-92

For completeness sake, the output of the networklist plugin looks like this:

Launching networklist v.20090811
Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles
linksys
Key LastWrite : Mon Feb 18 16:02:48 2008 UTC
DateLastConnected: Mon Feb 18 11:02:48 2008
DateCreated : Sat Feb 16 12:02:15 2008
DefaultGatewayMac: 00-0F-66-58-41-ED

2. Submit your MAC address to the SkyHook WiFi Geolocation database...for metropolitan areas, you may get a lat/long pair back...it's not guaranteed, of course.

C:\Perl>skyhook.pl 00-19-07-5B-36-92
Latitude = 38.9454029
Longitude = -77.4444937

Note: The code for skyhook.pl was based on this code...many thanks to Joshua! I'm doing this on Windows, and I couldn't find a version of XML::LibXML that installed on Windows, so I used XML::Simple. Also, I made a number of other modifications with respect to programming style, but Joshua did most of the heavy lifting.

3. Using the lat/long pair, create a URL for Google Maps (you can include some additional information, such as the SSID and date last connected), which will give you a map with a pushpin and any additional information you add. For multiple WAPs and to plot multiple pushpins on the same map, you may need to create a KML or KMZ file and host it someplace that can be reached by Google Maps, and then submit the appropriate URL (on the KML Update page, hover over the link that ends in cropcircles.kmz...).

For the WAP in our example, the URL might look like this. Here's an article that describes how WiFi geolocation can be used to recover stolen laptops.

Again, this isn't 100%. Not every area is mapped, and its highly unlikely that SOHO WAPs have been mapped. Still, if you can get something out of this, it might be useful.

Resources
Google Gears Geolocation API gets Wifi
SkyHook Wireless How It Works page
Firefox GeoLocation add-on

Addendum: Updated my Perl script tonight, thanks to input from Colin Shepard on Net::MAC::Vendor (for Windows, download the .tar.gz file, can extract the .pm file into site\lib\Net\MAC in your Perl install...). Now, the script takes either a WAP MAC address (if no SSID is provided, uses "Unknown") or the path to a file containing MAC addresses and SSIDs on single lines, separated by semi-colons. The output is any vendor and address information returned by the OUI lookup, and a URL that can be pasted into your browser window to get a Google Map (if lat/longs are available). For example:

C:\Perl>maclookup.pl -w 00:19:07:5B:36:92 -s tmobile
OUI lookup for 00:19:07:5B:36:92...
Cisco Systems
80 West Tasman Dr.
SJ-M/1
San Jose CA 95134
UNITED STATES

Google Map URL (paste into browser):
http://maps.google.com/maps?q=38.9454029,+-77.4444937+%28tmobile%29&iwloc=A&hl=en

Pretty sweet...

Linkity-Link

Now and again, the question comes up about writing technical forensic examination reports. Often in some forums, you'll see someone say that they feel that folks should publish their report formats...most often without doing so themselves. Funny how that works, eh?

Here's a link to a recent DFI article that describes what a report should contain.

Not long ago, John H. Sawyer wrote a nice article for DarkReading that mentioned my name...very cool, and a very nice reference. Thanks, John!

From the sausage factory, there's a great blog post about Windows Photo Gallery artifacts. IMHO, for the most part, we don't see enough of these kinds of posts...great work! Here's another, similar post from the ThinkTankForensics blog.

This past week, I had an opportunity to be around and talk to some really smart people, and had some really interesting thoughts about WiFi geolocation data extracted from acquired images. Okay, it's not quite as simple as that, per se, but I do think that for some folks (in particular, law enforcement), this sort of data exploitation will be extremely useful.

Ran across a reference to the Digital Forensic Framework last week, and thought I'd take a look...yes, Virginia, there is a Windows version! I'll have to read a bit more about it and give it a run.

Speaking of frameworks, ProDiscover version 6 is available! Thanks to Chris Brown's generosity, I've been using PD since version 3, and have written several ProScripts, which is the Perl scripting interface into ProDiscover. Some of the updates in version 6 are very, very welcome, including the ability to conduct regular expression raw mode searches. Very cool! I also ran across some comments in various lists that version 6 also supports access to Vista Volume Shadow Copy files...this is something I definitely need to check out. One of the things I've always loved about ProDiscover is the cleaner interface than some other tools, and I really like the Perl scripting capability!

Parsing .job Files

John McCash recently posted an interesting article to the SANS Forensic blog on decoding the binary Scheduled Task .job file format (John's article referred to tasks created using at.exe).

Based on John's article, I wrote a Perl script that parses the binary structure of the .job file header, and also gets some of the variable data that follows the header. For right now, I've got a number of the header fields translated and extracted, and I've been testing against a couple of .job files I've created on my own system; the output appears as follows:

C:\Perl\forensics>jobparse.pl d:\cases\apple.job

Command : :C:\Program Files\Apple Software Update\SoftwareUpdate.exe -task
Status : Task is disabled
Last Run Date: Thu Jul 16 16:21:00 2009 Exit Code : 0x0

So, this is a good start. I've had engagements where analysis of the Scheduled Tasks log file proved to be critical, so I can see how being able to get details from the .job file might also be important. Also, as John pointed out, information about the binary structure of .job files may assist you if you find indications of deleted .job files in unallocated space. If you get a hit and are able to backtrack a bit, you may find enough information in unallocated space to be able to decipher the header fields.

As a side note, I did find some minor issues with how the MS documentation identifies some of the fields in the structures; for example, the documentation shows a total of 9 2-byte fields for the UUID, but UUIDs are defined as being 128-bits long (ie, 8 bytes); this threw my initial parsing code off by 2 bytes. Interestingly enough, this applies to Windows XP systems, and the last run time for the job is maintained in the header as a 128-bit wide field; here I was thinking that the new date format was only part of Vista and Windows 7! Eesh!

Addendum: Interesting thought...the timestamps (and other data) embedded in .job files are updated when the task is run; therefore, this information can be used to provide indications of activity that modifies file MAC times, such as AV scanning, searches, or AF tactics...

Mo' Stuff

Man, there is just so much stuff sometimes, that it takes several posts to get it all in...

Perhaps one of the biggest things to come through my inbox lately has been that F-Response now has a scripting interface! That's right! According to Matt:

The F-Response Enterprise installation package now includes a partial implementation of the F-Response Enterprise Management Console in a language neutral fully scriptable COM object. This object will allow a technical user of F-Response Enterprise to script actions typically initiated manually in the FEMC.

Sweet! What this technical jargon amounts to is that F-Response EE can now be scripted through Perl! Imagine automating collection of system names from the network, pushing out F-Response EE, collecting information, disconnecting and moving on to the next system!

Here's an analysis tip that I picked up based on a question posted to one of the forums...when posting a question about time stamp oddities (in particular) on Windows systems, it helps to specify which version of Windows you're working with. For example, if you have a last modified date that is three days after the last accessed date on a file, and the system is Vista, then you may have encountered an artifact that has to do with the fact that by default, Vista does not update last access times on files. If the system is XP or Win2K3, you may want to check the NtfsDisableLastAccessUpdate value. Even variations within the same version of Windows (XP Professional vs. Home) can be important...and yes, you can use RegRipper to get this information for you.

Lee posted an excellent write-up regarding issues of MSOffice document metadata, along with an interesting example that many of us have likely run across. This is an issue that's been around for some time, and even though MS's updated the application itself, this is still something that can be very important during an examination, as Chris found out recently.

Are you tired of using RegRipper? Mark Woan has created RegExtract, which according to Mark, is based completely on RegRipper, and implements most of the plugins that are currently publicly available (I currently have 118, a few of which are proof-of-concept and for testing purposes only...) with RegRipper. I downloaded and installed RegExtract and took a look at it. It requires .NET 3.5, and it only runs on Windows (unless you can get .NET 3.5 installed on wine), but if you need a better looking UI and perhaps slightly faster processing, you should take a look at this. A couple of things I found with RegExtract is that while it can run all plugins designed for the NTUSER.DAT hive (or any other hive type) against that hive file, it doesn't appear to be able to automagically determine the hive type, or allow you to run only specific plugins in a predetermined order against the hive file. The results of the plugins are sent to a text field in the UI, and the user doesn't appear to have the ability...at least not obviously...to save the results to a file, for inclusion in a report (directly into the report, or an appendix). You can, however, select what you want from the text field, copy it to the Clipboard, and then paste it into a report or text file.

Finally, something else to consider...the plugins are compiled DLLs, and are not open. RegRipper's plugins are essentially text files that can be opened in Notepad or an editor of your choice (much like Nessus's plugins), so if you ever have any questions about what the plugin does or why it doesn't work, you can just open the plugin up and have a look-see.

Speaking of RegRipper, Rob posted the results of his updated research on USB devices to the SANS Forensic blog yesterday. This is an excellent bit of work that Rob's done and really taken the original work that Cory and I did oh, lo those many years ago to new levels. Drop by and check out the handouts Rob's put together. Based on an IM exchange with Rob, I've updated mountdev.pl a bit to pull out the sector offset information for the partitions, so that there's less confusion when you see two volumes or drive letters with the same disk signature or MBR disk identity (they're the same thing...the 4 bytes found at offset 0x01B8). The plugin now returns the same information seen when you open the image in FTK Imager and look at the start sector for the partition. With this new information, I need to clean up the plugin a bit to make the output a bit easier to understand.

Finally, Matthieu's been busy, it seems, working away on win32dd (now referred to as "windd") and looking for beta testers (ignore the "2008" in the changelog info...it's 2009). Take a look!

Thoughts on Tool Verification

A recent thread over on ForensicFocus got me to thinking about the issue of tool verification. In that thread, there is discussion of verifying the results produced by RegRipper. Chris picked up on this and posted to his blog, as well.

First off, I'm a proponent of verification, but I also think that we, as a community and a profession, shouldn't be blindly running on autopilot when it comes to tool verification. Specifically, what is "tool verification"?

One way to look at this is that you'd like to verify that a tool does what it's supposed to do correctly. For example, if one tool (ie, AccessData's FTK Imager) generates an MD5 hash of an acquired image, you might want to verify that the algorithm used to generate that hash was done implemented correctly, so you'd use another tool (one that you trust as being correct...perhaps Jesse Kornblum's md5deep) to confirm that the MD5 hash is, indeed, correctly implemented. The implication here is that if both tools produce the same output, then the implementation employed by FTK Imager is correct and verified.

A similar way to look at this is with respect to a tool such as RegRipper, but how would you verify the results? For one, what other tools do what RegRipper does...besides RegExtract, which is, according to the author, based on RegRipper?

Well, similar to Nessus, RegRipper implements its actions based on plugins that are text-based. So if you want to determine what a plugin does (ie, what keys, values or data it extracts, and how it extracts or parses that data), all you need to do is open the plugin in Notepad or an editor. I know that a lot of folks will look at the Perl code and slip in to a coma, but for the most part, the data extraction and parsing logic is right there...in some cases, it's easy to see: read the binary data into a variable/Perl scalar, go to this offset within the data, read this many bytes, and translate it based on this table of values. Easy.

If you're not sure that what a plugin does is correct, I try to make sure that I include either descriptions in the comments of the plugin (lines that start with "#") or references to credible sources about the structure or use of the key, value, or data being parsed. In most cases, much like WFA 2/e, these references consist of MS KB articles. If there's some question about the data and how it is or should be interpreted...well, that's what I provide the references for, and as many of you know, I've tried to answer more than a few questions along those lines.

So, how do you verify what a tool like RegRipper does? One way is to use another tool that does what RegRipper does...but outside of RegExtract, there are no other tools that do what RegRipper does. You can open the hive file in a Registry viewer...some of the plugins present information in a manner similar to the way a viewer would, and you can always write your own plugins to do this. But what about parsing/interpreting binary data? Or "decrypting" ROT-13 value names? At that point, the only way to verify what RegRipper does is to sit down with the hive file open in a hex editor and do it all by hand.

Again, I'm not saying that tool verification isn't important...because it is. But so is understanding what a tool does. Blindly saying that I need a tool verify my findings against another tool is really pointless unless I understand what both tools do, and how they do it. I mean, the same holds true in other areas, such as live response. If I run two tools that both use to the same API calls to show me the active process list or the network connections, have I verified anything? No, I haven't. However, if I run two tools that use disparate APIs (and don't converge until somewhere very low in the API stack) then I have verified the tools and the findings...but only to the point where they ultimately converge somewhere down the API stack.

So, before discussing tool verification, we need to have an understand of the purpose and use of the tool, as well as an understanding of how the tool functions.

RegRipper Wishlist

I posted something similar to the RegRipper forums, but I'll do the same here...I'm looking to consolidate a RegRipper wishlist, so I can see what folks are looking for in RegRipper, see what is most/least looked for, and then prioritize the creation/update of features.

So...please, comment here, or email me. Thanks!

Tools for mounting images

A while ago, I posted on mounting DD images, and I wanted to provide an updated list of some of the tools that you can use to do just that on a Windows systems.

When would you need to use such tools? I like to use tools such as these as in most cases, you can do your analysis whilst goin' commando (sans dongle, as it were), and in many cases, do a great deal more deep analysis than you could using one of the commercial forensic analysis suites. In most cases, it's as simple as mounting the image and using your tools, many of which are CLI and can be run via a batch file. Mounting the image gives you access to most (be cognizant of permissions issues) of the files in the file system without that system being live and without requiring a password to log into the system (as with LiveView), simply because you're not actually booting the system, you're just reading the file structure.

I won't got into any particular detail about these tools, as I want to simply provide them here as a means of identifying those that are available.

VDKWin (free) - Excellent UI for VDK.
ImDisk (free) - installs as a Control Panel applet
SMARTMount (pay) - Andy Rosen's superb mounting utility; requires a dongle, mounts raw, SMART, EWF, SAW, VMWare virtual disk format images, and detects a wide variety of file systems.
P2Explorer (free, requires registration) - Lots of cool features, mounts a variety of formats.
Captain Nemo (pay) - Mounts raw and RAID Reconstructor images from Linux, MS, and Novell systems.

Other similar tools that may be of use:
MKS Software's mount utility
MS's Virtual CD-ROM drive from XP (1, 2, 3)
Mounting ISO images on Vista/Win7
WinCDEmu - mount ISO images

For those of you doing live response, the guys over at CommandLineKungFu posted a great blog on determining information about mounted drives and shares. Some of the tools I've written and provided on the DVD that accompanies WFA 2/e implements similar functionality as the wmic commands that Ed posted, but in most cases going just a bit further.

Stuff

Been out of pocket, enjoying my temporary unemployment for a while, and now I'm back in the game...

Richard Bejtlich posted his review of WFA 2/e on Amazon...thanks, RB! It's validating to see luminaries in the security industry picking up, reading, and commenting on books like mine, particularly because Richard is so well known for NSM, something my book doesn't really cover.

Thanks to a recent comment to one of my blog posts, I was led to the Eating Security blog...always nice to get different perspectives on topics. I like some of the recent posts about IR teams and documentation, as well as the "does it make sense" test. I've done considerable work over the years with respect to CSIRP development and IR team testing, and I like to see how others approach the problem. While each customer brings a unique perspective to the problem through their own infrastructure and team organization, it's always interesting to see the thoughts that others have...most often due to the fact that developing a new IR team with a customer doesn't allow for a great deal of feedback beyond, "wow...okay...this is new."

Speaking of CSIRP development, here's an interesting blog post that I picked up a while back. Interesting how information on "crisis management" so easily maps to a CSIRP.

The guys over at cmdLabs had a nice post on SQLite for forensics nerds that has some good information...something to read, maybe play around with a bit, and bookmark.

Claus had an excellent forensic roundup post recently...he really can cover a LOT of stuff. I'm still sifting through this one. Claus and I read each other's blogs pretty regularly, so you see not only crosslinks but comments, as well...but Claus never ceases to amaze me with the breadth of useful information he's able to come up with. He's got a couple of links for pcap visualization that I need to take a look at.

All in all, not a bad catch this time around.

Addendum: Just a bit later, I ran across a couple of interesting blogs, and rather than wait to post another blog entry, I thought I'd add them here...

ForensicInnovations had an interesting blog, and the post that initially got my attention was Push for Live Forensics. I started into the post expecting yet another argument for developing a live response process, and got some of that...but the post ends with an announcement for a data profiler product that appears to provide a list of various file types found on the system. I'm not entirely sure how I'd use such a product, as rather than "show me all of the file types" I might take the approach of just "show me all graphics images", or something a bit more directed (based on the goals of my response).

I also found Simple Techniques that Fool Forensics Tools in the archive, as well as a couple of other posts. There's mention of NTFS Alternate Data Streams in this post, something I've been writing about for years, and oddly enough, is still something that is an effective hiding place for data, as many sysadmins and forensic analysts still do not understand how ADSs are used by the OS, let alone by the bad guys.

Also, I found a link to this CyberCrime blog that has some interesting stuff to read.

RegRipper used to validate Neeris infection...with lots of other good stuff in the post, as well...a good deal of which I use in creating timelines for analysis...

More Links

I found another review of WFA 2/e this morning, this one on the ISC^2 web site, from Jesse Lands...thanks! I greatly appreciate when folks take the time to let me know what they thought (what they liked or disliked) about the book. To whomever...Thanks! This is in addition to the 14 reviews on the Amazon page for WFA 2/e...

Seems the folks at SpiderLabs will be putting on a Malware Freakshow presentation at a conference in Toronto coming up soon. Also, it sounds as if the presentation is going to be pretty interesting...take a look at this excerpt from the DarkReading article:

In a memory-dumping attack, the attacker reads the unencrypted transaction or other information that sits in memory before it goes to the actual application. The hotel attack included several pieces of malware, including code that dumps the contents of the memory onto the attacker's machine, and another that performs data parsing. "One piece installs itself as a service so the malware can come back when it needs to boot up," Ilyas says.

I'd run into the same malware myself during an exam, and one of our team members had seen an earlier version a year so prior to that. This shows how pervasive this stuff can get! In the instances I'm aware of, the intruder gained access to the internal network and then gained domain admin access...most often due to weak passwords...and then targeted very specific systems, and installed the software mentioned in the article.

Also, if you're going to the conference, be sure to check out Chris Pogue's Sniper Forensics presentation.

On the topic of visualization, check out the VizSec2009 conference. This looks really interesting, as visualizing malware program flow, for example, can be extremely helpful. One of the things I've been struggling with is to understand how to graphically represent timeline data so that an analyst can use that to determine what happened and when; however, there's just potentially so much data that I've been having a very difficult time trying to come up with some way to represent what happened. Right now, its a manual process to sift through the data looking for the smoking gun(s), and representing the findings can be done with a table or an Excel spreadsheet.

It looks like I'll be attending HackerHalted in Miami later this month, and Syngress is not only a sponsor but will have books available. I'll try to be available to sign books...if I'm not at the booth, just grab me (beer's always welcome!!).

And finally, for the VMI alumni in the readership, I picked up follower number 89 today!

What is "Registry Analysis"??

What is this thing called (that's the second time I've used that Benny Hill reference in this blog)...Registry analysis?

For most folks, this phrase probably conjures memories opening a hive file in their favorite Registry viewer (RegEdit, EnCase, ProDiscover, or RFV, etc.) and looking at a couple of the more popular entries, such as the "ubiquitous Run key". Others may run though an entire list or spreadsheet worth of Registry keys and values. Manually. By hand. How boring. And if you're a corporate consultant, there's no better way to waste a customer's money as you burn through the hours on this chore, calling it Registry analysis.

But is this really analysis? Is analysis simply viewing data, or is it extracting data and interpreting that data in not only its own context , but also in context with other data?

One of the things I've stated in my books as well as in this blog is that when interpreting data (particularly data extracted from the Registry) its vital that the analyst understand what created or modified (with deletion being the extreme form of modification) a particular artifact, so that the nature and context of that artifact is understood (and presented/explained). For example, what would lead to a graphics image file being referenced in the MRU list to an image viewing application? The artifact is there, but what lead to its creation? Depending upon how that particular MRU list is maintained by the application, you may have a very specific timestamp associated with the artifact, as well...one that may correlate with the last access time of the file. Ah, but there's another point about Registry analysis, analysis in general, and understanding the context of artifacts...beginning with Vista, MS disabled the updating of last access times on files by default, so now analysts can't correlate a file's last access time to other artifacts.

So my point is that Registry analysis isn't just about viewing certain keys and data...no, that's Registry viewing. Rather, Registry analysis is about interpreting Registry artifacts (keys, LastWrite times, values, and data) in the context of the actions that led to their creation and modification, as well as in the context of other artifacts. Tools such as RegRipper strive to assist analysts and examiners with this sort of analysis, by providing a framework for extraction, correlation, a modicum of interpretation, as well as the presentation of the data with some supporting information.

Growth and research in this area appears to be sought after by the community, but is also limited by a lack of support and contributions from the community.

Timeline Analysis
Registry data can be an integral part of a timeline created for analysis; however, there is much more timestamped data available in the Registry than just key LastWrite times...sort of like that quote from Hamlet. For example, on Windows XP, some data holds the SSIDs that the user connected the system to via wireless networking, as well as the WAP MAC addresses and when the connection was made. On Vista, you also get the first and last time that SSID was connected to (as well as the WAP MAC address). Let's not forget other keys and values, such as MRU listings and one of my personal favorites, the UserAssist subkeys. These aren't the only differences between Windows versions...and I'm sure that there are others out there who are working on documenting these differences besides myself.

Links and Stuff (Registry research)

The subtitle of this blog post is "There are more things in heaven and earth than are dreamt of in your EnScript", to paraphrase Horatio.

Thanks to the SANS ISC blog, I ran across an AV product (free) called Immunet. This seems very interesting as it takes a "cloud" approach to protection...I know that "cloud" is becoming something of a buzzword in the computing industry, but maybe this will bring it home for the older folks; it take a SETI@Home approach to protection. How's that? The concept (not talking about the actual implementation) sounds pretty cool...

I ran across a tool called TrojanHunter recently that looks pretty interesting from a live system response perspective. The main page for TrojanHunter is absolutely correct...there are Trojans and other malware that don't necessarily hide on the system as much as they are DLLs injected into the memory of other processes. Therefore, when you're doing your live response, you're going to see network connections for some processes that may not normally have network connections...because it's the Trojan that's doing it.

Lately, I've been working on some Registry research, and I came across this page at the MS site, which includes the following:

Executable binary code should never be stored in the registry.

Pretty cool, eh? That's why I wrote the findexes.pl plugin for the RegRipper...Don had written on his blog not long ago about malware that wrote executable files into binary Registry values, so there had to be a way to detect this sort of thing.

As part of this Registry research I was doing, I was digging into the Shell\BagMRU data, as I had read this excellent paper on the use of the keys, but noticed that the paper didn't include anything about the binary data itself. I contacted the authors of the paper and Mr. Zhu was kind enough to respond with some information that proved to be very helpful. I took it from there and wrote up a RegRipper plugin to parse the information...several actually, that provide the information in various formats. Right now, however, it's very bare bones and the data needs to be formatted a bit (no, I take that back...a LOT) better.

Also during that research, I found something interesting...actually, a couple of somethings. First, the MUICache key on Vista has moved to the other user hive file, %LocalAppData%\Microsoft\Windows\UsrClass.dat. On a Vista system, I found the key in the UsrClass.dat file, in this path: Local Settings\Software\Microsoft\Windows\Shell\MuiCache.

The other interesting thing I found was that some of the Shell\BagMRU key appeared to be in the normal location in the NTUSER.DAT file, but there was additional information in the UsrClass.dat file, as well, in the path, Local Settings\Software\Microsoft\Windows\Shell\BagMRU. In fact, some of the information in the UsrClass.dat file seemed to be more inclusive...but that's just in my initial testing.

While we're on the topic of the Registry, its completely clear to me that the Windows Registry maintains a great deal of data, and as has been the case with memory analysis, things also seem to change as the versions of Windows change. With Vista and Windows 7, not only has a great deal of the information we would normally expect to look for on an XP system moved, but new data associated with wireless networking (specifically, binary values for wireless profiles named DateCreated and DateLastConnected) and an entirely new format has been added for the dates.

Mark has a blog post about translating the date format here; completely separately, I wrote the below code for my own use (thanks to my friends who helped me with the format):

sub parseDate128 {
my $date = $_[0];
my @months = ("Jan","Feb","Mar","Apr","May","Jun","Jul", "Aug","Sep","Oct","Nov","Dec");
my @days = ("Sun","Mon","Tue","Wed","Thu","Fri","Sat");
my ($yr,$mon,$dow,$dom,$hr,$min,$sec,$ms) = unpack("v*",$date);
$hr = "0".$hr if ($hr < 10);
$min = "0".$min if ($min < 10);
$sec = "0".$sec if ($sec < 10);
my $str = $days[$dow]." ".$months[$mon - 1]." ".$dom." ".$hr.":".$min.":".$sec." ".$yr; return $str;
}

Okay, so not only does this show us that, clearly, things change between versions of Windows in more than just the memory analysis arena. So, not only does the Registry contain some time stamps in 32-bit Unix time format, as well as the more expected 64-bit Windows FileTime format, but now there's this 128-bit whatever format for time stamps!

More to come...

Goin' commando

Cory had post a bit ago about using alternatives to commercial analysis suites when conducting an exam, and that got me to thinking...when I wrote WFA 2/e, one of the things I was acutely aware of was that some of the information would age pretty quickly; that is, from the time that I submitted the manuscript (early March) until the book was published (June), there would be a LOT of things that changed or improved, with new tools and new versions coming out. So something like a published book would be a good start, but it wouldn't be a great way to keep track of freely available tools that may be of use. Considering the fact that in most cases, folks don't even look for (or in some cases, write) tools until they actually need them, something online and easily edited (ForensicWiki) would be a better resource for tracking this sort of thing. The ForensicWiki would also be a great resource for not only providing information about tools (free or otherwise) for conducting analysis, but also for information on the format on the files being analyzed.

As a side note, I've found that over the past year or more, with the exception of PCI-specific searches, I've pretty much gone commando (i.e., sans dongle) on my exams, relying instead on specific, free tools...not because I have anything against the commercial stuff, but because the free tools fit the bill for what I needed. Does that make me a bad person?

Anyway, I think that is would be a great place to start throwing up information, discussion and links to free and open-source tools that folks are using for analyzing various files or formats. This can include general stuff (such as, does anyone have a good, free grep utility for Windows that doesn't use cygwin?)

For example, over on the ForensicFocus forums recently, there was a question regarding viewing information in MSI files. The original poster (OP) found that one of the recommended tools, InstEd, was extremely helpful for what he needed to do.

So, I'll be posting links to and comments about tools here, but I'd love to have folks send in comments or emails about tools they use that are free and/or open-source, and allow them to "go commando" on their exams. Please, no pictures! ;-)

Virtualization

What is a way to use a system to perform various activities, but leave minimal traces? One might think that any of the available cleaner tools (anyone remember SilentRunners.vbs?) would be the answer, but such tools can be too good, making it clear that something was used to wipe artifacts off of the system, harkening back to one of the adages in my books, that the absence of an artifact is itself an artifact.

Think virtualization. Think plugging in a USB device (thumb drive, iPod, etc.) that contains its own running operating system, along with its own tools and storage area. This isn't something that I've seen a lot of, but in a time when the media is telling us that declines in the economy are leading to increased data theft by departing employees, its something to consider.

Diane Barrett has talked about how virtuatlization affects forensics. When portable virtual environments such as MojoPac or Moka5 are used, the analyst is presented with a whole new set of challenges, as the usual remnants and artifacts (i.e., browser history, Registry settings, etc.) won't be available on the confiscated system. Instead, all artifacts will be on the USB storage device that contains the virtual environment, and only indications of the use of these environments (USBStor and MUICache Registry key entries, etc.) will be found.

So, the days of a simple, straightforward examination are fading into the past. Concerns of data leakage or IP theft just took on another dimension... going from file copying and malware and Trojans to leakage via social networking sites and virtualized environments. What's needed is specialized research and training to keep up with developments.

Resources
PortableUbuntu
Qemu Manager - Manager for Qemu VMs
Running the OLPC Image in Qemu
ReactOS (use Qemu or VMWare)
Run Haiku under Qemu (Haiku is based on BeOS...I added this one for pure kewlness...)
Portable Virtual Privacy Machine
Windows + Qemu + Plan 9 (again...pure kewlness)
OS/2 Warp 4 on Qemu (ok, that's just going for the extra nerd points...)

Papers, Tools, and Such

If you do any work at all with network traffic captures (ie, .pcap files), you should take a look at Claus's Network Capture Tools and Utilities post. I mentioned several of the tools listed in Claus's post in Chapter 9 of Windows Forensic Analysis 2/e, and some of those tools have been updated. If you want to try the tools out but don't have any "interesting" traffic available, check out sites like this or this.

I didn't attend DFRWS this year, but I did see this very interesting paper about the CyberForensics TimeLab (CFTL) by Jens Olsson and Martin Boldt. CFTL is a "computer forensic timeline visualization tool", with the engine developed in Perl (yes!) and a C#/.NET GUI frontend. According to the paper, timestamped data is automatically extracted from an acquired image via processing with filters, and then stored in an XML format, which is then made available to the analyst via the frontend. CFTL appears to take a similar approach to ex-tip, in that filters extract timestamped data from various file formats. Taking the similarities a step further, CFTL also appears to parse Registry hive files only for keys and LastWrite times. From just reading the paper, the similarities end there, as CFTL uses an automated approach to extracting information from an acquired image, making in-processing and development of the XML file a fairly straightforward process.

I applaud the efforts of the authors, as this is just the kind of work we need to see within the computer forensic analysis community. Without this kind of work, we wouldn't move forward. However, I have a couple of thoughts with respect to this sort of approach to timeline creation and analysis. First, the context available from a timeline is derived from contents of the events themselves, not in a bar chart or histogram showing the numbers or frequencies of events within a given time period. For example, automatic software updates can lead to a great deal of file system and Registry activity, and any malicious activity during that timeframe will be hidden. Also, the LastWrite time for the ubiquitous Run key isn't nearly as relevant to an examination as the values contained in the key.

Second, I have heard analysts say time and time again that when developing a timeline, most analysts want everything, all of the available data, and that data reduction will be performed later. With respect to the Registry, I tend to disagree, as in most cases, the timestamps embedded within Registry data provide greater context than the key's LastWrite time. I tend to agree that if you don't really know and understand what you have available to you within an image acquired from a Windows system, go ahead and grab everything that's available. I also believe that if you do know what you have available to you and what data you can use, you can take an interative approach to building your timeline for analysis. I've done this myself, and I've found it to be much faster and more accurate than dumping all of the Registry key LastWrite times into a timeline and trying to make heads-or-tails of what happened.

From Spanagel Hall out at NPS in Monterey, CA (my alma mater) comes a very interesting master's thesis from Greg Roussas titled "Vizualization of Client-Side Web Browsing and Email Activity". This approach reminds me of the Analyst's Notebook, and I can see how this sort of approach would be

A bit of computer trivia...Gary Kildall once had an office in Spanagel Hall. I used to walk by it almost every day.

I caught this ComputerWorld article about NZ police releasing a virtualized environment tool for evidence. One thing about the article that concerned me was this statement:

Digital forensic examiners faced with a complex inquiry can spend weeks delving into a computer to find the traces of evidence required for a successful prosecution, Police say.

Ouch! Really? Weeks? Why? On the commercial consulting side, a "complex inquiry" would be broken down into discrete goals and steps, each of which would be provided an answer, or something along the lines of "...could not be determined conclusively...", along with the reason why. But really...weeks? Anyway, in the end, the new tool sounds as if it's LiveView with a web interface...but hey, if it helps LE put bad guys in jail, so be it. Personally, I think that there's a lot being missed using something like this, but I do see how it can be a very useful tool.

Finally, IronGeek posted the video for a class he gave on anti-forensics. The video itself is quite long (just over 3 hrs), so you might want to grab the slides and check out the links in the page. There's some pretty interesting (re: challenging) stuff presented in the links alone (I haven't watched the video yet...).

Tools and Links

From DFRWS2009 (papers here) and Andreas's tweets I found out about NFI Defraser, a utility that reportedly detects full or partial multimedia files in data streams, such as unallocated space within an acquired image. Defraser downloads as an MSI file, so it appears to be Windows-based. John posted some great info on Defraser to the SANS Forensic blog.

Also from Andreas's tweets I found out about Snorkel from NFILabs. Snorkel is a Java-based library that provides access to acquired images. While an evaluation version is available for testing, the implications of something like this are incredible! Imagine being able to completely script (ie, automate) an entire pre-processing examination of an acquired image, where much of what is now done manually would be a matter of inputting a job and waiting.

Internet Evidence Finder from JADSoftware has been updated to version 2. IEF v2.0 runs searches for a variety of Internet artifacts, such as Facebook, Yahoo and Google chats, Limewire search histories, etc. If this is something you're looking for, particularly with regards to inappropriate usage or data leakage issues (hey, USB devices aren't the only way to get data off of a system), then this is a tool you'll want in your kit.

Also be sure to check out Jad's Encrypted Disk Detector tool. EDD is a CLI tool that checks local physical drives for PGP, TrueCrypt and BitLocker encrypted volumes. If you're doing live response and need to know this sort of information before shutting a system down and acquiring an image, then you really need to include a tool like this in your kit.

If you're interested in Vista's Volume Shadow Copies, check out this post from the Forensics from the Sausage Factory blog. Most folks seem to love 'war stories' and 'case studies', so this is something you might want to take a look at.

Speaking of analysis, Chad's post on the SANS Forensic blog about demystifying the use of defrag on a Vista system is very well-written and interesting. This follows Chad's other post that takes a look at the same subject, but from an XP perspective. Posts such as these are extremely important, IMHO, as they look at attempting to determine intentional use of the disk defragmenter utility, given the fact that the system itself runs a limited defrag on a regular basis. I think that too many times, analysts fall into the trap of thinking that if a Prefetch file exists on an XP system, that indicates that the user run utility...end of story. However, per Microsoft (from the section on Prefetch):

Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag.

On a side note, one of the tools I recently posted to the Win4n6 Yahoo group as part of the timeline creation toolkit (ie, pref.pl) does a great job of parsing information/metadata from both XP and Vista Prefetch files.

The folks over at the SANS Internet Storm Center posted a compilation of tools for extracting files from pcaps. Very cool. I talked about NetworkMiner in WFA 2/e, and it's one of my favorites.

HelpNet Security Interview Posted

I recently responded to an email Q&A session for HelpNet Security...it's posted here.

Thoughts?

Timeline Creation Tools Posted

I've posted the currently available timeline creation tools to the Files section of the Win4n6 Yahoo group, along with a PDF document that illustrates how to use the tools.

The tools themselves are somewhat raw at the moment. They're all Perl scripts (none have been compiled into standalone EXEs) and therefore require that ActiveState Perl be installed to use them (I used version 5.8 to develop the scripts). Some of the scripts require additional modules, but they're pretty easy to install using the Perl Package Manager (PPM) that ships as part of ActiveState Perl.

At the moment, the process for using the tools is manual...there's no single "Find all evidence" button to push...this isn't Nintendo forensics. However, there is a method to my madness...this provides the analyst with the flexibility to create mini-timelines, comprised of a subset of available sources, such as only the Event Logs. I've found this capability alone to be extremely valuable.

Finally, these tools are a start, and even through they're still raw at the moment, they open the door to an extremely valuable analysis technique. If this is something you're interested in, download the zipped archive, take a look at the PDF document (walks through using the tools to build an actual timeline from an image), and let me know what you think. Posting this isn't the end, it's just the beginning...

Links and Stuff

Once again, I present for your reading pleasure an odd mish-mash of links to information that defy categorization...

I no longer do PCI forensic audits, but I thought this one was interesting...the BreachSource site includes an interesting tool called BreachProbe, which takes a packet capture and can parse out credit card data. I can't say that I had access to very many packet captures during a breach investigation...most often we'd get a call after the "victim" organization had been notified by an external third party that they were a CPP, usually as a result of a fraud investigation. From there, there was even more time that went by before folks like me were called on-site. However, this does look like a useful tool for those who still do this kind of work.

I've been doing some research on various values and data within the Windows Registry, and part of that included settings for WZCSVC, largely for Windows XP. During my research, I ran across this Symantec web page, which includes a tool called wlan.exe. This looks like it's a great tool for collecting information and troubleshooting issues in a wireless environment. Based, in part, on this information and more about the WZC_WLAN_CONFIG structure, I updated the ssid.pl RegRipper plugin to parse the MAC address of the WAP out of the data. There's some additional work that needs to be done regarding control flags, but so far this has been some pretty interesting information. I originally started looking down this road based on something said in a post to the EnCase user forum, and started digging for some credible, solid information on which to base some Registry research. While the structure I found is specific to WinCE, it seems to apply very well to XP, as well. In my own testing, I pulled the MAC addresses for two SSIDs out of a hive file; the MAC address for the "tmobile" SSID pointed to (via OUI lookup) Cisco as the manufacturer, and the one for the "ender" SSID (my own WAP) pointed to Cisco-Linksys.

A recent post on one of the lists asked about locating indications of the use of the at.exe in the Task Scheduler log file. The at.exe command is used to schedule tasks, and on XP and above, you can also use schtasks.exe to create scheduled tasks. However, the schedlgu.txt file does not record the creation of scheduled tasks via either of these tools, but instead records Task Scheduler Service start/stop messages and scheduled task/job execution information. So this is something to keep in mind when conducting analysis and you find a Prefetch file for at.exe.

In a recent discussion regarding Windows trusted shells, someone sent in a link to a tool called "console", which appears to be a replacement to cmd.exe. It looks pretty interesting, and may be a great edition to your toolkit if you find the functionality useful.

A new post on the Hacking Exposed Computer Forensics blog continues the "what did they take when they left" series of posts, and also mentions RegRipper and RipXP. The post brings a lot of the thought processes that an analyst must use into play when trying to answer the question. Its easy to say, "there's more to it than that", and I'm sure that the author(s) would agree, but that's why there's a series of posts...putting it all in one post would simply make that post too long and too hard to digest. Also, I'd suggest that since part of the title of the series includes "when", suggesting a relation of events to time, that timeline creation and analysis might help to answer these questions. RegRipper doesn't have a plugin that parses all of the information mentioned in the blog post...yet.

On a side note, it looks as if HECF has a second edition on its way out. Nice! I still have the first edition posted prominently on my bookshelf, and it's nice to see a number of computer forensic books out there. As much of a niche as the topic of computer forensics is, its nice to see a choice of books that covers different aspects of the field.

The Virus Bulletin recently released their RAP index, illustrating the results of testing to determine an AV product's reactive and proactive detection capabilities. Kind of scary when you think about it, but then most folks are aware of this and know not to rely on AV as a be-all-end-all, silver bullet solution. I mean, what do you expect, with malware write-ups like this? I mean, seriously...

Finally, RipXP has been picked up in Spanish on the NeoSystemsForensics blog! Nice!

Thoughts on using a "trusted shell"

Recently I've seen the topic of using a "trusted shell", especially when performing live response on Windows systems, brought up in a couple of forums.

The idea of a "trusted shell" comes from the use of statically-compiled binaries on *nix systems, where the actual executable file carries with it it's own libraries and does not rely on libraries on the "victim" system. The idea is that if the actual shell binary or any of the dependent libraries have been compromised, the responder can still get accurate information due to the fact that she's using a "trusted shell". And, of course, there's always the concern about "rootkits", but whenever I see a post or email that includes a reference to rootkits, my FUD radar goes off; in most cases, I don't think that folks understand rootkits, per se. For example, why say that you're only going to use a "trusted" cmd.exe because the cmd.exe on the system may have been subverted by a rootkit, when your "trusted" cmd.exe is going to use the same DLLs as the native one? I mean, most rootkits hook or subvert API functions, not executables.

Mapping this to the world of Windows incident response, one has to ask, how do you statically compile an executable for Windows? Can you even do this? At some point, you're going to have to rely on an MS-provided DLL, and its all a matter of how deeply the system has been compromised. After all, if the intruder is able to compromise extremely low-level APIs to the point of tricking the kernel, it's game over!

Even using SxS manifests will very likely present their own unique set of problems, particularly since most currently available tools and applications don't use manifests and would need to be rewritten.

Finally when running cmd.exe, there are a number of ways to subvert the use of just that executable without ever touching or modifying the EXE or any of its dependent DLLs. One is through the use of the Command Processor\AutoRun Registry entry (HKLM or HKCU), one is through the exefile Registry entries, and another is through the Image File Execution Options Registry key.

So that leaves me with the question of, why are folks stressing so much about "trusted" shells, when we can't even figure out what that is?

Another way to look at this is that if we've done our IR planning, maybe we want the operating system to lie to us. Think about it...if we're using some form of differential analysis, wouldn't we want to run "netstat -ano" on a system, and then compare that output to a packet capture, firewall logs, or even an nmap scan? Or how about using tools that use disparate API calls, such as perhaps pslist.exe and handle.exe, to get similar information (ie, process listing)? Wouldn't we get some benefit from quick, automatic parsing of the data that would highlight disparities in the output? Let's say you're seeing a steady stream of data flowing from a system, and you have firewall and IDS logs, as well as a packet capture, and the output of netstat shows in indication of the use of the port? Wouldn't this sort of analysis provide us with something useful, and obviate the need for speculation and assumption?

What are your thoughts?

More work on Timeline Analysis

I saw that there's a new post over on the SANS Forensic blog about generating timelines for analysis by adding "alternative" sources of timestamped data. This post points back to Kristinn Guðjónsson's blog post about the log2timeline tool for creating timelines.

This is very similar to some of the stuff I've been working on, and it's great to see that there's more interest in creating timelines for analysis and answering questions.

Another cool thing about Kristinn's work is that its Perl-based! Sweet!

Speaking of Perl-based approaches to timeline creation, I received an email yesterday that contained a link to the Revealer Toolkit, or "RVT". This toolkit looks pretty promising, so be sure to take a look at the project page for downloads and news. RVT has its own newsletter/Google group, as well.

RVT is an interesting project. First off, there's the Perl aspect. Second, reading through the documentation, it appears that the authors came up with some similar thoughts along the same lines that I was thinking of when I started down this road; in particular, how to incorporate not just different sources of time stamped data from a single system (ie, file system, EVT files, Registry hives, etc.), but how to incorporate data from multiple systems, as well as other external sources.

Another interesting aspect of RVT is the ability to plot timelines in a graphical format. I'm having some trouble coming up with a means for plotting timeline data in a meaningful way, so that the analyst is not overwhelmed with raw data, but is instead able to glean some modicum of actual intelligence from the shear glut of information. For right now, the timeline tools I've developed are a very manual process, but there's a method to my madness...more about that later.