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.

I love it when stuff works...

Remember my earlier post about parsing the output of handle.exe? Well, I received the output of this tool from a customer with a system that, in all likelihood, was infected with W32.Virut.CF. Using the Perl script from my earlier post, I found a mutant named 'l0r8' within the winlogon.exe process.

An interesting item about this malware is that it doesn't appear to use autostart locations within the Registry or file system in order to maintain persistence; rather, it achieves persistence as a file infector...some of the files infected get run on a regular basis, so the infection remains persistent across reboots. A list of files infected by at least one variant of Virut can be seen here. Here's a nice write-up on another variant of Virut, and here's an informative blog post from Fortinet.

So, when examining a system that may be infected with Virut, don't expect to find a process running or a Registry entry that will point to an executable file. From a post-mortem analysis perspective, look for the artifacts in the write-ups available, in particular an odd entry in the hosts file, an entry in the Registry allowing outbound connections through the firewall (AuthorizedApplications\List in the DomainProfile or StandardProfile...the fwconfig.pl RegRipper plugin can help you here), and a value being added HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer key.

One important aspect of forensic analysis when it comes to malware infections is that customers are asking the question, how did it first get on the system? This malware doesn't float around on its own, and it doesn't install itself as an executable, launching from a Registry key, so we'll have to find another way to determine when and how the system was first infected. One way to do this is check the last modification time on some of the files that were infected, and correlate those to the Registry artifacts listed with some of the variants. If you're not sure which files to check for (some variants may infect different files), there's another means of determining some of the files you can look at; some of the write-ups on the malware state that it patches sfc_os.dll in memory, disabling Windows File Protection, presumably to infect 'protected' files. Therefore, we can use a tool such as WFPCheck in order to determine infected files, and from there, determine the last modification time of the files.

Don't forget to check the contents of the host file, and if the described artifacts are present, check the last modification time, as well.

Now, one thing to keep in mind is this...what happens when an infected system is rebooted? When the system starts back up, infected EXE files are launched and the activity indicative of the malware occurs again...but are the EXE files re-infected? If so, the last modification time of the files should be shortly after the last reboot...something we can correlate with other system artifacts. So the question becomes, are the Registry and file system artifacts the result of only the first infection instance, or are they reproduced each time the system is rebooted and the infected files are run again?

Now, if you have a Windows XP or Vista system, you may be able to use existing Restore Points or Volume Shadow Copies (respectively) to narrow down (to an approximate window) when the system was infected.

Once you have a timeframe to focus on, use timeline analysis of system and user activity to attempt to determine the original infection vector...via web browsing activity, email attachments, or possibly connection of USB removable storage devices or connections to network shares.

More Links

Picked up this site the other day, with a post about the MS Office Visualization Tool...looks pretty cool! Offvis allows you to graphically view data structures and records withing MSOffice documents...neat! If you need this kind of capability and need to be able to extract metadata from Office documents, then this is a good tool to have available. If you have your copy of WFA 2/e, be sure to check out wmd.pl and oledmp.pl on the DVD...and check out chapter 8 for an example of how I've used oledmp.pl!

Hey, the Illustrious Don Weber has posted about finding malware hiding in (that's right, I said "in") the Registry (Sophos post on the same sort of thing). This is actually pretty amazing when you think about it...so how do you go about finding this sort of thing, if you suspect it? Do you do what Don did and essentially stumble across an exported DLL function or handle to an odd Registry key during memory analysis, or can you find it another way? Remember my recent post where I mentioned least frequency of occurrence (props to Pete Silberman!)? Do something like that and parse through the entire hive file looking for values with binary (REG_BINARY) data types, and (a) map them based on size and (b) look for ones that start with "MZ". To get started on this, I wrote a RegRipper plugin (uploaded it to the Win4n6 Files section, and pasted it into a post on the RegRipper.net forums) that parses through any Registry hive file and looks for all values with binary data. For each of the values with binary data that if finds it keeps a count, and searches the binary data for "MZ", an indicator of a PE file. Here's what the output looks like when the plugin is run (via rip.exe) against the file that Don was looking at:

Launching findexes v.20090728
Key: Microsoft\SysMgr
LastWrite time: Fri Jun 26 08:18:27 2009
Value: ssdt Length: 2464 bytes
Value: hide Length: 3328 bytes
Value: door Length: 110592 bytes

Number of values w/ binary data types: 5103
Number of values w/ MZ in binary data: 3

Pretty neat, eh?

Speaking of neat tools (no, this is NOT a reference to Cory Althiede), I received this comment about ripXP over in the RegRipper.net forums this week:

This is a very slick tool, and, aside from the fact that it's free, should be a candidate for "tool of the year" if there's such a thing!

Thanks! I don't know if there is such an award, but I'm glad that someone has found the tool to be useful!

Addendum, 8/10: Symantec posted a write-up on the malware (Backdoor.Regdor) that findexes.pl was originally written to address. Something interesting about the Symantec write-up is the statement that the malware takes control of the system when the replaced version of mspmsnsv.dll is loaded by svchost.exe. Hey, wait a second...on my XP systems, mspmsnsv.dll is a file that's protected by WFP...so shouldn't the write-up be mentioning something about WFP being subverted? Yeah, yeah, I know that malware is doing this more and more, but this is still something that needs to be said.

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.

Links

My interview with Lee Whitfield is up as Forensic4Cast episode 17. Lee asked some interesting questions, so be sure to listen to the entire podcast...we talk about some things at the end of the interview that you like to hear.

Chris Pogue, co-author of Unix and Linux Forensic Analysis, has started his own blog...check it out! Chris and I have worked together, and it's good to see him getting into the mix now and bringing his experience and knowledge to the blogosphere, including posting a review of WFA 2/e! Chris will also be at the SANS Forensic Summit, speaking on the IR panel. I'm sure if you asked him, he'd be more than happy to sign your copy of ULFA, which, by the way, Syngress will have table at the Summit with their books available.

Hogfly posted on the Need for Speed, and I really think that this is something that cannot be said enough. While there is a need for speed in response, there's also a need to ensure that things are still done right and still done to a standard of accuracy and quality. Again, though...the need for speed in response is very real. In many cases, you'll have an issue of suspected data leakage or exposure, and acquiring a small number of systems and taking 2 months or more to provide an answer is simply unacceptable, as much or more so than providing the wrong answer too quickly. Processes and techniques need to be addressed, improved and implemented in such a manner as to answer the three most important questions:

1. Was the system compromised?
2. Did the system house or store "sensitive" data?
3. Did #1 lead to the exposure of #2?

Suffice to say that a lot of what it takes to answer these questions rests squarely on the shoulders of the system owners themselves. There's only so much that can be done when the breach goes unnoticed (often, for weeks), and then the first reaction of the on-site staff is to shut the system down and take it off of the network.

Hogfly also posted his review of WFA 2/e...check it out. I like to see what practitioners have to say about the book (or any other resource, for that matter), because who better to have an opinion on something like that than someone who works in the business, right? Seriously. If you wanted to get someone's opinion on, say, the acceleration and handling of a sports car, who would you look to? Eddie, the introvert who reads car magazines (and other things) online, or Danika Patrick?

#1 on Amazon!

Just today, I found out that WFA 2/e is #1 in the Amazon Sales Rank for Forensics books! Awesome! Thanks to everyone who's reviewed the book and to everyone who's purchased a copy of the book!

Buy F-Response, get a free copy of WFA 2/e!

Hey, no kidding! Check it out! Matt's offering a free (as in "beer") copy of WFA 2/e with each purchase or renewel of F-Response CE/EE. Got four consultants? Outfit each of them with a copy of F-Response EE, and they'll each get a copy of WFA 2/e. Sweet! Don't think so? Check out the reviews!

WFA 2/e eBooks

I've received a number of emails regarding ebook versions of WFA 2/e, and at this point, all I've been able to determine is that Elsevier will NOT be producing a PDF version of the book for sale. No, I don't know why, and to be honest, I'm as mystified as you are.

The information I have from the publisher at this time is that it takes about 1-2 months to produce the ebook version of a book, and multiple ebook versions are produced (Kindle, Safari, etc.). I've been told that while a PDF version will not be produced for sale, that there will be a version produced by Ingram (??) that will be available to be read on a computer, and I'm also told that this reader, like Adobe Reader, allows the ebook to be searched. Other than that, I have nothing...I don't even know where to download the reader just to take a look at it. Nor do I know when the ebook will be available in any version, nor how much it will cost.

That's all I have. Pretty amazing, eh? A large publishing firm like Elsevier, and an author such as myself is having trouble getting basic information.

So, all I can say is sorry (although I'm not sure why I'm the one saying that...), and if you really want to let someone know how you feel about this, email my editor...she's graciously consented to accepting your emails. Or stop by the Syngress table at the SANS Forensic Summit and let her know.

Thoughts on Timeline Analysis

I was chatting with Chris Pogue (a fellow Syngress book author attending the SANS Forensic Summit) a bit over the past couple of days on the subject of Timeline Analysis, and had some thoughts that I wanted to throw out there and see what others thought about them...

Personally, I've been doing some pretty cool things with timeline analysis, incorporating not only file system metadata, but Event Log entries, data from the Registry, as well as the user's web browser history, etc. What this does is allow me to view events from several sources all in one place, giving me some context, but not all of the possible context. And this can be a LOT of data! I go through the process of creating a bodyfile, then a 5-field TLN format events file, and then a full timeline in ASCII, saving it in a text file. I've updated some of my code recently to allow me to re-run the events-file-to-timeline conversion tool and focus solely on a specific date range, down to a single day.

This is where we usually start talking about visualization...what's a good way to present this information in a graphic format so that the analyst can determine the answer to the question they're trying to answer? Perhaps better yet...IS there a good way?

When it comes down to presenting the data to the customer, I've never been a supporter of giving the customer all of the raw data (there are folks out there who think a 3300+ page report is a good thing!), and giving the customer a timeline graphic of ALL of the data really doesn't do a whole lot, either for them to understand what's going on, or for your professional credibility. That's where the knowledge and ability of the analyst come in, and you create a timeline that summarizes the important and relevant events for the customer.

So, how do you do this? Do you sift through the data, extracting all of the irrelevant stuff (ie, removing thousands of file last accessed events and replacing them with a single AV scan event, etc.) and dump it into some kind of program that will generate the timeline automatically, or is it something more of a manual process? (See the Resources section at the end of this post for some examples of how to create a graphic representation of a timeline that can be added to reports.)

At this point, I'm of the opinion that this is still largely a manual process. While timeline creation and analysis has been automated to some degree through the use of tools, the fact is that there's currently no automated "sausage grinder" that you can drop an acquired image into and have it chug away and give you a full timeline. Just the file system metadata alone from one system can be cumbersome and overwhelming, particularly if you don't know what you're looking for. Lets say that you automatically add the Event Log entries to the timeline...but what if the Security Registry hive shows that the type of auditing you're looking for (successful login attempts) wasn't enabled, and a scan of the Event Logs shows that the events do not cover the dates in question anyway? If this is an automatic process, you've now got a lot of extra, albeit irrelevant, data.

What about context? Not all context of the events is visible in a timeline...in some cases, a recent modification date on a file isn't as important as what was added (or removed) from the file. Or you may have two events...a USB removable storage device plugged into the system and shortly thereafter, a Windows shortcut/LNK file created...and the valuable context of the correlation between the two events is in the path information and volume ID embedded in the LNK file.

In a way, this discussion brings us back around to the basic idea of the skill and knowledge of the examiner/analyst. Lets say an analyst responds to an incident, and goes on-site to find four desktop systems that had been powered down and taken off of the network. One analyst might look at this, remove the drives, and image them with the pair of Vooms he has in his jump kit. Another might hook each drive up to a write-blocker and acquire logical images of each partition. Yet another responder might boot each system, log in as Administrator, acquire volatile data, and then perform live acquisitions. Given this kind of disparity across a single response, how does an analyst then "correctly" decide which information needs to be included in a timeline for analysis, and then determine the context of the data?

IMHO, this all comes down to training and experience. Training specifically in this topic needs to be available, followed by guidance and mentoring. Cheatsheets need to be available to remind folks about what's available, why and how the data is important, and then within organizations and labs, there needs to be some kind of peer review.

Thoughts?

Resources
How to create a timeline in Excel (free templates)
Free SmartDraw Timeline Software

Very Interesting Developments

I don't often get presented with issues of copyright violation and intellectual property theft, but I did see this one today. It seems someone has set up a blog where they are offering copyrighted ebooks for free, two of which I authored. I also know the authors of several of other offered ebooks.

Folks, one of the big myths about authoring books is that somehow the author gets rich. I'm here to tell you, in this niche market, that just is NOT true at all. If you're that hard up that you need to steal someone else's intellectual property...well, what can I say?

Suffice it to say, this just isn't cool.

SANS Forensic Summit

Folks, let's not forget that the SANS Forensic Summit is coming up! Check out the list of speakers, presentations, and panels...this conference is going to be great!

Also, I spoke to the marketing folks at Syngress, and they are going to have a table at the Summit (graciously provided by Rob Lee) where they're going to have books available. Now, the way cool...no, wait...the WAY COOL thing about this is that several of the authors are also speakers at the Summit! So, if you don't have Chris Pogue's book, get it and get it signed by none other than Chris Pogue himself! Eoghan Casey's going to be there, too!

Finally, I have pristine copies (one each) of Windows Forensic Analysis (first and second editions), as well as Perl Scripting for Windows Security. I am going to bundle all three of them together and provide them as a give-away following my presentation at the conference.

BTW...the presentations from the 2008 SANS Forensic Summit are archived here! Take a look!

PS: I had a meeting yesterday and got there a few minutes early...I was meeting a friend for lunch and took a minute or two to walk through a nearby bookstore. Guess what I saw on the shelf? I'll give you a hint...I went to the Computer section, and was browsing in the area where they keep the books on security and forensics... ;-)

More Links

NetWitness announced on 8 June the availability of NetWitness Insight. This is a very interesting announcement, in part because, IMHO, NetWitness is the premier product available today when it comes to seeing and understanding what's happening on your network. In this case, collection of network traffic isn't the issue...it's the analysis and presentation, and that's where NetWitness products excel. The inclusion of InSight now gives the NetWitness suite of products what appears to be a DLP and vulnerability assessment capability, so that customers can find out where that sensitive data resides, as well as (according to the press release) locate vulnerable systems and prioritize remediation. As an incident responder, this is a fantastic capability...but what's missing is still the host-based response capability. Sounds like a job for F-Response!

I recently heard about a tool called MIR-ROR, put together originally by Troy Larson and then expanded by Russ McRee, both of Microsoft. Russ blogged about it here, and there's a toolsmith article available on it, as well. MIR-ROR is a batch file that is useful for running tools on a system as part of incident response; what I like about this is that Russ isn't sitting back hoping that someone does something like this, he's taking advantage of his knowledge and capabilities to put this together. And he's made it available to the public, along with instructions on how to run it. I like tools like this because they're self-documenting...properly constructed and commented, they serve as their own documentation. As always, the standard caveat applies...use/deploy tools like this as part of an incident response plan. If your plan says you need to acquire a pristine image of the drive first, you will want to consider holding off on using a tool like this...

Didier updated his disitool...I'm not even going to try to explain this one; instead, go to his blog and check it out.

Win32dd has been updated...according to Matthieu, there are some bug fixes, improvements, and some additional information about the memory state is displayed when the tool is used. Thanks, Matthieu, for the great work you've done with this tool!

While we're on the subject of memory collection and analysis, Brendan has updated VolReg to support BIG_DATA data types, due in part to Matthieu's blog post on Undocumented Vista and later Registry Secrets. Also, be sure to check out Brendan's Volatility Plugins page.

If you're a follower of Lon Solomon, at this point, you might be thinking, "SO WHAT?!?" Well, take a look at this write-up from Sophos...the part I like about this bit of malware is:

Rather than creating another file on disk, the dropper logic writes an entire PE file into the registry. The executable is stored under the key HKLM\SOFTWARE\Licenses with a randomly generated entry name.

Years ago while I was working for a security company in New Jersey, I wrote some code that would go out to a web site and grab what appeared to be a GIF image, but was in reality a PE file. The code would then disassemble the PE file into various Registry keys...the idea being that disassembling and writing it into the Registry would avoid detection by AV scanners. Then another piece of code would reassemble the PE file into the Recycle Bin and launch it. I thought that was pretty cool...but that was 8 years ago. Reminds me of that song Round and Round, by RATT..."what comes around goes around...". Hey, I wonder if we'll "see" a resurgence in the use of NTFS Alternate Data Streams, say, to hide PCI data?