Stuff

Timelines
Corey Harrell recently posted to his blog about using Calc (the spreadsheet program associated with OpenOffice) to perform timeline analysis. Corey's post was very revealing and thorough, and clearly demonstrates to the reader that here's a guy who does timeline analysis. I mean, Corey looks at regular expressions for searching, etc., and really does a good job of covering a lot of the different analysis aspects that you'd do in Excel, and provides a good indication that he's actually been doing this kind of analysis. Great job, Corey.

However, there are two things that came up in the post that might be good points for discussion. First, Corey says that his exploration originated from an anonymous question asking if Calc could be used in place of Excel. I applaud Corey's efforst, but this question demonstrates how some analysts will continue in asking these kinds of questions, rather than doing their own research and posting the results. This is one of those things that could have been easily stated as "Calc can also be used...", rather than as an anonymous question.

The other issue is the concern that Corey expressed with respect to the spreadsheet program's ability to handle massive numbers (100K or more) of rows. This is definitely a concern (particularly with versions of Excel that were pre-Office 2007), but it also demonstrates how timelines, which are meant to some degree to be a data reduction technique, can actually become very cumbersome and even slow the analyst down, simply by the shear volume of data. Yes, extracting data and generating a timeline is less data than a full image (i.e., a directory listing of a 160GB hard drive is much less than 160GB...), but it appears that so much data is capable of being added to a timeline that doing so could easily overwhelm an analyst.

Timelines and Data Reduction
One solution to this that I highly recommend is an educated, knowledgeable approach to timeline development and analysis, which is something Chris points to in his Sniper Forensics presentation. Rather than throwing everything (even the kitchen sink, if it has a time stamp) into your timeline and sorting it out from there, why not instead start with the goals of your examination, what you're trying to show, and go on from there? Your goals will show you what you need to look at, and what you need to show.

After all, one of the benefits and goals of timelines is...and should be...data reduction. While a timeline compiled from an abundance of data sources is indeed a reduction of data volume, is it really a reduction of data to be analyzed? In many cases, it may not be.

Consider this...let's say that while driving your car, you hear an odd noise, maybe a squeal of some kind, coming from front left tire every time you break. What do you do? Do you disassemble the entire car in hopes of finding something bad, or something that might be responsible for the noise? Or do you do some testing to ensure that the noise is really coming from where you think it is, and under what specific conditions?

No, I'm not saying that we throw everything out and start over. Rather, what I'm suggesting is that rather than throwing everything into a timeline, assess the relative value of the data prior to adding it. One excellent example of this is a SQL injection analysis I did...I started with the file system metadata, and added just the web server logs that contained the pertinent SQL injection statements. There was no need to add Event Log data, nor all of the LastWrite times from all of the Registry keys from the hive files on the system. There was simply no value in doing this; in fact, doing so would have complicated the analysis, simply through shear volume. Is this an extreme example? No, I don't think that it is.

By reducing the data that we need to analyze, even if doing so in through the analysis (determine what we can remove from timeline as "noise", etc.), we then get to a point where relational analysis...that is, analyzing different systems in relation to each other, we can get a better view of what may have occurred (and when) in multi-system incidents/breaches. Remember, in the five field timeline format that I've recommended using, there is a field for the system name, as well as one for the user name. Using these fields, you can observe the use of domain credentials across multiple systems, for example.

Goals
I know that many folks are going to say, "What if you don't know what you're looking for?", and the answer to that is, "If you don't know what you're looking for, why are you doing analysis?" Seriously. If you don't know what the goals of your analysis are, why are you doing it?

Sometimes folks will say, "my goals are to find all bad stuff". Well...what constitutes "bad"? What if you find nmap and Metasploit installed on a system? Is it bad? What if the user is a network engineer tasked with vulnerability scanning and assessment? Then, is this find "bad"?

From the questions I receive, a lot of times I think that there is difficulty in defining goals. Does anyone really want to "find all malware"? Really? So you want to know about every BHO and bit of spyware? Given some home user systems, imagine how long it would take to locate, document, and categorize all malware on a system. Usually what I have found is that "find all malware" really means "find the malware that may have been associated with a particular incident or event". Then, getting the person you're working with to describe the event can help you narrow down the goals of your analysis. After all, they're talking to you for a reason, right? If they could do the analysis themselves, there would be no reason to talk to you. Developing a concise set of goals allows you to define and set expectations, as well as deliver something tangible and useful.

Timeline as a Tool
Timeline analysis is an extremely useful and valuable tool...but like any other tool, it's just a tool. The actual analysis is up to the analyst. There may be times when it simply doesn't make sense to create a timeline...if that's the case, then don't bother. However, if it does make sense to develop a timeline, then do so intelligently.

Volatility Updates
Gleeda recently tweeted about documentation for Volatility being available. If you do any memory forensics, this is an excellent resource that walks you through getting all set up and running with the full capabilities of Volatility.

More Updates

New Blog
Ken Pryor has started a new blog, and has his first post up as of Sun, 21 Nov. Check it out, and add it to your RSS feed. I'm sure Ken's going to have some gems.

I met Ken face-to-face at the WACCI conference a bit ago. He's a great guy, very knowledgeable, and very enthusiastic. Speaking of which, Ken was at the WACCI conference along with Brad Garnett, who's also posted to his blog recently. If you like some caffeine-induced forensic ramblings, stop on by and take a look.

Confessor
Russ reached to me recently to let me know about Confessor, a tool that he'd covered in a recent toolsmith column. Russ had previously mentioned MIR-ROR, and says that Confessor uses similar tools but deploys them in an "enterprise-capable manner". Also from Russ's description of Confessor and another tool (mentioned below):

"These tools were born of needing better utilities for incident response and security analysis in complex, massive cloud-like environments."

Russ also mentioned MOLE in his toolsmith article; "MOLE" stands for "malicious online link engine", which allows the analyst to validate URLs to see if malware was present. I can see how a tool like this would be very useful for analysts during a malware investigations and incident response.

Questions
I received a question the other day that I thought was interesting, because I'd seen it before. Back when I had submitted my proposal for the Windows Registry Forensics book, all of the proposal reviewers had stated that this book would need to compare and contrast RegRipper to the commercially available Registry "analysis" tools.

As it turned out, I wasn't able to do this for the book...for the simple reason that I didn't have access to those commercial tools. I don't use EnCase at work, nor do I use FTK. I did try to get a temporary license for one of the commercial tools, and was told "no". In the spirit of full disclosure, I did have an opportunity to meet Brian Karney of AccessData, and he did offer to discuss providing a temporary license for the AccessData product, but by then I was so close to the deadline for the book that there simply wasn't time to go back and work this into the book. I did reference Technology Pathways ProDiscover in the book, and that's because I had access to that commercial tool.

Also, I used quotes around the word "analysis" earlier, because most commercial tools are simply viewers...it's up to the analyst to perform analysis. To some extent, RegRipper is also a viewer, of sorts, although it doesn't so much leave the "what's important" up to the analyst, but instead allows the analyst to extract and analyze what is likely the more important and valuable data.

The question I received was right along the same lines. I guess on the surface, questions such as "how is RegRipper better than or different from the commercial tools" is one that comes from folks who, for the most part, haven't really used RegRipper much if at all, and have pretty much haven't really used the commercial tools to a great extent. I would also think that the question also comes from not really having conducted a great deal of Registry analysis. I wouldn't say that RegRipper is any better than any other tool...because it's just a tool, and is therefore only as useful or as good as the analyst using it. Like any tool that's used improperly, RegRipper would be seen as useless. Or, a knowledgeable analyst can use the tool effectively and even find new ways to use it that had not been thought of before, particularly by the designer.

One of the benefits and useful features of RegRipper is that it's open source, and the tool can be modified to suit your needs. Chris Perkins has modified RegRipper, and so did Adam James. Okay, so most folks are likely to say to this, "...but I don't program", and may even qualify that with "...in Perl." That's okay, because you can always ask someone to assist in meeting your needs. One of the reasons many folks provide tools for free is to get feedback from others who are either doing the same or similar work, or those who may be new to field and have a fresh view or perspective. So when I'm at a conference, and talk to someone who says, "...but I can't program...", I will generally ask them if they have email...because if they do, they can ask someone for assistance.

Another benefit of RegRipper as an open source tool is that if you need something done with a plugin...a new plugin written, or a current plugin with something a bit different done with the output...it's a simple matter to change things. Early on, shortly after releasing RegRipper, I received a request or two for XML output...in response, I asked for recommendations on a style sheet...and never heard back. I've received requests for .csv output...but it's a simple matter for someone to open the plugins of their choice in Notepad, commenting out (add "#" to the beginning of the line) the appropriate "::rptMsg()" statement, and adding their own. Or copy a plugin to a different name...say, copy uassist.pl to uassist_csv.pl and make the appropriate changes.

Okay, so what's the point of all this? To answer the original question, RegRipper is open source, so if you want to know how something is done or if you want to change something, just open up the appropriate file in Notepad. If you're not a programmer, ask someone. It's that easy. RegRipper isn't any better than any other tool, simply because it's not the tool, but the analyst that plays the most important role in any examination.

ZeroAccess Write-up
I was reading through Giuseppe Bonfa's write-up of the ZeroAccess/Max++ rootkit recently, and I have to say...I was interested not only in how detailed and thorough the write-up was, but also the steps taken by the malware author.

In part 1 of the reverse engineering write-up, Giuseppe points out an important artifact associated with this malware...a randomly named Windows service. According the write-up, the service is installed as a kernel driver, set to load on demand, and the ImagePath is set to "\*". The Service key name itself begins with a '.' (dot).

In part 2, Giuseppe reverse engineer's the kernel-mode device driver. His analysis revealed that when the kernel-mode driver loads, it first deletes it's Services Registry key, and then the entries under the "Enum\Root\LEGACY_" path. Apparently, the author(s) of this malware are taking steps to protect their gem from discovery, and are doing so from learning from incident responders and forensic analysts.

Giuseppe's write-up is as thorough as it is interesting. Take an opportunity to read through it...it's not only a good example for reverse engineers, but it's also good for other analysts to see so that they can understand the perspective of a reverse engineer, as well as what a reverse engineer can come up with and find out about malware. In this case, we've not only seen a rootkit that creates a hidden volume for its files, but also actively takes steps to obfuscate its presence on a live system.

OffensiveComputing also has a bit about the reverse engineering of this crimeware rootkit.

Updates

CyberSpeak, 8 Nov
Be sure to check out the CyberSpeak 8 Nov podcast, with an interview of Kristinn, creator of Log2Timeline. There's some Lubie, some iPhone stuff, and lots of Ovie! Good stuff, Ovie, thanks for putting these podcasts together and entertaining us all.

Windows 7 & USB Devices
A member of the Win4n6 group recently posted that there seems to be yet another place that Windows 7 tracks USB removable storage devices. The key path is:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt

This key appears to have to do with ReadyBoost, and applies to Vista, as well as Windows 7, systems. The key names for each of the devices listed contains information similar to what's in the DeviceClasses key, including the serial number (bold in the below example) for the device, as illustrated below:

\_??_USBSTOR#Disk&Ven_Best_Buy&Prod_Geek_Squad_U3&Rev_6.15#0C90195032E36889&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}GEEKSQUAD_1414378827

The values beneath each key include things such as the physical size of the device, as well the date that it was last tested (presumably by ReadyBoost for use as a RAM cache). I have a Windows 7 system for testing, as well as set of hive files from a Vista system, and I see entries for devices that include thumb drives and even an iPod, but not for a digital camera that had been connected to the system.

This might be a very good resource, as I've seen where some folks have asked for the physical size information of a USB device. It would be interesting to see if external HDD enclosures appear in this key, as well, and under what conditions the key LastWrite time is updated.

Resources
CodeProject

F-Response
There's a new post over on the NewInForensics blog that talks about using F-Response, in this case when analyzing Windows Event Logs (.evtx) files. I have to say that I'm glad to see others using this tool, and running tests like this, as it tells me two things. One is that folks are deciding to pick up tools and run their own tests.

The other is that folks in the community and industry are beginning to really realize and acknowledge how useful and truly powerful a tool F-Response really is, and they're using it as such.

When it comes to Windows Event Logs (.evtx) from Vista and above systems, I like to use LogParser from MS to parse the logs into some text-based format, and then use Perl to put the entries in a TLN format for inclusion into a timeline, or for generating mini-timelines. Sometimes I get questions that are best answered by creating mini-timelines (sort of the opposite of super timelines) from just RDP login events, W32Time events, etc.

OpenSource Tools
Brian mentioned recently that there's a new site available called OpenSourceForensics. From Brian:

One of the take aways from the Sleuth Kit and Open Source Digital Forensics Conference last year was that the community needed a site where examiners could go to find tools and learn about which ones were better than others.

This is a great resource, as one of the issues I hear from folks is that tools are out there, but they're OUT there...there's no single resource or location where an examiner can go to search for or find a tool, or get input from other analysts on the usefulness of the tool. Hopefully, with input from examiners and analysts, this can become an exemplary resource...but remember, folks, it takes effort from everyone!

Add to that a big thanks and shout-out to Brian for this, as well as for the Open Source Conference last June...Brian also mentioned that there will be another one next June!

Note
I presented at the PFIC2010 conference recently, and while I was there, someone came up and told me that they had all of my books. I was going to say something witty, and ask which one they liked best or opened the most, only to have them start off by saying, "...File System Forensic Analysis..."...uh...that's Brian, not me. Brian has hair, and is much smarter than I.

SecTor.ca
Speaking of conferences, SecTor videos are available. I watched Greg Hoglund's keynote presentation, and correlated to what I heard there about the APT and focused attacks to what I saw in Dave Nardoni's presentation at PFIC2010.

During the keynote, Greg pimped Windows Forensic Analysis 2/e during his presentation...very cool, Greg, thanks!

Greg went on to say that the perimeter is disappearing through the use of mobile devices, and that host systems are becoming more important than ever. Early in his keynote, he talked about threat intelligence achieved through host-based analysis, and how many folks have a simple, flash-and-go response policy...wipe the drive of a potentially infected system, re-install, and move on. I think that one of the scariest things...well, should be one of the scariest things...is that Greg pointed out that there's an economy behind gaining access to host systems. That's right...people are paying money to gain access to your systems!

Finally, during his presentation, Greg mentioned a couple of times how MD5 hashes are just short of useless for analysis of well-thought-out intrusions. I know someone who'd be upset about that, if they bothered to watch videos like this.

Randomness

Writing Books...and whatnot...
As I've mentioned, Windows Registry Forensics is nearing completion (I'm reviewing the proofs now...) and according to Syngress, will be available in January. When something like this is coming out, as with WFA 2/e, the biggest question I tend to get is, "Did you cover the differences/changes in Windows versions?"

Most times, I'm taken aback by this question. I was at the CSI 2010 conference recently, and went by the Syngress table. I talked to someone who was looking at a copy of WFA 2/e, and once he realized that I was the author, he asked me that question. In order to get a better idea how to answer that question, I turned it around and asked him, "...like what?" To that, I got a blank stare in response.

I think...and please, correct me if I'm wrong here...but the real, underlying question is, what are the new sources and locations of potentially valuable data?

In many ways, this is something of a loaded question...because, yes, there are some things that are different between versions of Windows, and in particular between the venerable Windows XP and the shiny new Windows 7. But I could sit here for the better part of the day talking about the differences and never, not once, hit on anything of value to you or to your examinations. Some file paths and Registry locations have changed...while some haven't. Some file formats have changed, while new ones have been added. Some of the new file types in Windows 7...for example, sticky notes...are a bit questionable when it comes to their potential value as evidence.

My suggestion to the community is that if you want to see this kind of thing, start talking. What good does it do to stand there asking "...did you cover all of the changes?" AFTER the book has been written and published, and you're holding it in your hands (with your thumb on the table of contents)? Seriously. If you've got a concern, ask someone. I think you'll be surprised...if nothing else, that you're not the only person with that question. Sometimes, that's all it takes...

Registry Analysis
Speaking of working on the book (the proofs, really), one of the things that really intrigues me about Registry analysis is...well...Registry analysis.

One of the most valuable uses for Registry analysis that I've found is that you can go into the Registry and see historical access to a range of resources...USB removable storage devices (thumb drives, digital cameras, etc.), network shares, remote systems (via RDP or VNC), files that no longer exist on the system, etc. In many cases, you can tie a good deal of this activity to a user, as well as to a specific time frame. You can see what a user searched for on the system.

I've performed examinations of systems where there was a question regarding digital images...we'll just leave it at that (most of us know where I'm going with this...). Someone had claimed that the images had been put on the system by malware, and yet the Registry clearly showed not only access to the files in question, but also showed an association with a specific viewing application, and time stamps indicating when the files had been accessed. These time stamps from the Registry corresponded to file system metadata, as well as metadata from Prefetch files associated with the viewing application(s) (think multiple data sources for timelines). The Registry also indicated access to files no longer on the system, as well as files that were on other media.

I'm really looking forward to the book coming out for two reasons...one is to see it and hold it. The other is to see what folks think, in hopes that the content will spur discussion (what else is needed) as well as a greater move toward recognizing the Registry as a valuable forensic resource.

FIRST
I recently attended a portion of a FIRST technical colloquium put on by IBM. Thanks to Richard Bejtlich for sponsoring me so I could attend.

I saw David Bianco (I'd swear that David is Cory Altheide's fraternal twin...) from Richard's team at GE talk about what they were doing, and the biggest take-away for me was the fact that they collect what's practical, as opposed to everything that's possible. They've got a phased approach to their network monitoring coverage, which has been prioritized; much like the Great Wall, they don't so much look at what's coming in as what's trying to go out of their infrastructure in the first phase of their rollout. This clearly demonstrates considerable thought having been put into their approach, taking into account what needs to be covered, staffing levels, etc., and coordinating all of these resources.

In part, this is something of a breath of fresh air when applied to the IR/DF communities. Too often, I think, we tend to take an "I need EVERYTHING possible" approach, and end up losing site of our goals. I really liked what David said about getting everything practical, as I can really see how it applies to the IR/DF field. Have you ever seen someone who will arrive on-site as a responder and state their strategy is to image everything? By the time you're done imaging, the customer is no longer interested in your findings, as they're likely fined or out of business.

Another thing that came out of the discussion surrounding the presentation was that they have a tiered approach for their analysts, with a progressive career path, so that analysts coming in at a particular level have goals that they can strive for in order to progress to the next level. This is a different view than what I had seen when I got into the security industry in 1997, and I think that its an excellent approach.

Again, thanks, Richard. I was saddened to not see Eoghan Casey at the colloquium.

Thoughts on Analysis, Information Sharing, and Presentations

Since June of this year, I've attended a couple of conferences, not only presenting but also attending several presentations. As with any conference, presentations tend to vary with the background and experience of the author. By experience, I don't so much mean with the experience the author has in the topic they're presenting on, but more so with developing presentations specific to the audience, public speaking, etc.

One of the questions I ask myself when both creating and giving a presentation, as well as attending one, is "how is this immediately valuable and useful to me?" Often times, we attend a presentation that may have some great information, but the question then becomes, okay, but how to I use this? How do I most quickly/immediately turn this information around and use it on a case or examination?

I'm sure that a lot of other folks feel the same way, particularly after having talked about this very subject after a presentation or discussion. I've also seen this enough to add this sort of approach to my books, starting with WFA 2/e and progressing even more so into Windows Registry Forensics. With a lot of what's going on in our community, it's vitally important that analysts be able to get up from a presentation or talk, and be able to put what they've learned in a technical presentation or lab into practice. If that isn't the case...what's the point?

This is critically important when you're talking about analysis techniques, which is particularly where we need to innovate. Data is always going to be data, and it's always going to be there. There's been discussion about triaging systems, due in part to the massive increases in storage and the amount of time it takes to acquire and analyze all of that (especially acquire). So whether you're talking about browser forensics or

Innovation in Analysis
How many folks out there use RegRipper? How about using RegRipper for malware detection or analysis? Seriously.

Bear with me on this...it probably wouldn't occur to most folks to use something like RegRipper for malware detection, looking into an acquired image, or a system accessed via F-Response. However, I (and others) have used this approach time and again to our benefit.

Consider Conficker. Microsoft cites five variants. In each case, when the next variant first came on the scene, the executable file was not detected by most commercial AV tools. However, there were some consistencies across the malware family, including not just artifacts (ie, disabling system functionality) but also in the persistence mechanism.

I had the distinct honor of reviewing on of the chapters for the new book, The Malware Analyst's Cookbook, and in that chapter, the use of RegRipper was discussed. MHL and his co-authors had written several plugins for use in their work (included in the book) and to be honest, they were innovative.

Okay, so you're probably looking at this so far and thinking, yeah, but that's for malware you know about. Okay, sure, I can go with that. But here's the deal...while you may not have seen all malware, or at least a great deal of it, but what are the chances that within a large group or community of forensic and malware analysts, a LOT of malware has been seen and analyzed? Of those, their artifacts and persistence mechanisms will likely have been identified (Zeus, or ZBot falls into this category) and be worthy of a plugin.

Consider malware based on PoisonIvy. Yes, it's polymorphic, which for most of us, is going to mean that AV scanners are going to have minimal effect in detecting this stuff. However, keep in mind the four characteristics of malware...the persistence mechanism is an example of Jesse Kornblum's "rootkit paradox"; in short, most malware will want to run, but will also want to remain persistent. As it turns out, PoisonIvy isn't the only malware that uses the Registry Installed Components as the persistence mechanism.

Institutional Knowledge
How many of us use the institutional knowledge developed on previous cases/engagements on any new analysis that comes in? Most of us are going to raise our hands and say, "I do that all the time."

Now, how many of us make use of the institutional knowledge developed by other analysts, such as other team members?

Tools like RegRipper (and pretty much any tool that has some level of extensibility, including EnCase and ProDiscover) provide for sharing of institutional knowledge, but only insofar as that institutional knowledge is documented.

So What?
I'm sad to say that not all of us will ever see everything, particularly when it comes to IR and digital forensics analysis. For myself, I know that I haven't seen everything...I've seen some things several times, I've been on engagements that never where, but I haven't seen everything. Expand this to include any 5, 10, 50, or 500 analysts you want, and while it may seem that across all of us, we've seen a lot, the question then becomes...how much of that have we shared with others, or each other.

The issues the community faces are not going away. Increases in things like storage space, sophistication and proliferation of malware and compromises/intrusions, AV scanners becoming less and less of a reliable resource, to name a few. I think that most of us are familiar with these issues. So what do we do about all these?

CyberSpeak
Ovie's on a roll...don't miss the new CyberSpeak podcast! Ovie has an interview regarding triaging systems...talk about timely! ;-)

Analysis Techniques

Now and again, it's a good idea to revisit old thoughts and ideas, to dredge them up again and expose them to the light of day. One of the things that I have spent a lot of time thinking about is the analysis techniques that I'm using during examinations, and in particular taking a step forward and seeing how those techniques stack up against some of the threats and issues that are being seen.

First, a caveat...a lot of what I think (and sometimes talk) about focuses on disk analysis. This is due to the realities of the work I (and others) do. Was a responder, many times, all I have access to is a disk image. Or, as is often the case now, I focus on disk analysis because I'm part of a team that includes folks who are way smarter and far more capable than I am in network, memory and malware analysis. So the disk stuff is a piece of the puzzle, and should be treated as such, even if it's the only piece you have.

Analysis
So, there are a couple of general techniques I tend to use in analysis, and I often start with timeline analysis. This is a great analysis technique to use due to the fact that when you build a timeline from multiple data sources on and from within a system, you give yourself two things that you don't normally have through more traditional analysis techniques...context, and a greater relative level of confidence in your data. By context, we aren't simply seeing an event such as a file being created or changed...we're seeing other surrounding events that can (and often do) indicate what lead to that event occurring. The multiple data sources included in a timeline provide a great deal of information; Event Logs may show us a user login, Registry contents may provide additional indications of that login, we may see indicators of web browsing activity, perhaps opening an email attachment, etc...all of which may provide us with the context of the event in which we are most interested.

As to the overall relative level of confidence in our data, we have to understand that all data sources have a relative level of confidence associated with each of them. For example, from Chris's post, we know that the relative confidence level of the time stamps within the $STANDARD_INFORMATION attributes within the MFT (and file system) is (or should be) low. That's because these values are fairly easily changed, often through "time stomping", so that the MACB times (particularly the "B" time, or creation date of the file) do not fall within the initial timeframe of the incident. However, the time stamps within the $FILE_NAME attributes can provide us with a greater level of confidence in the data source (MFT, in this case). By adding other data sources (Event Log, Registry, Prefetch file metadata, etc.), particularly data source whose time stamps are not so easily modified (such as Registry key LastWrite times), we can elevate our relative confidence level in the data.

Another aspect of this is that by adding multiple sources, we will begin to see patterns in the data and also begin to see where there are gaps in that data.

This is particularly important as intrusions and malware are very often the least frequency of occurrence on a system. Credit for this phrase goes to Pete Silberman of Mandiant, and it's an extremely important concept to understand, particularly when it comes to timeline analysis. In short, many times analysts will look for large tool kits or spikes in the event volume as an indication of compromise. However, most often, this simply is not the case...spikes in activity in a timeline will correspond to an operating system or application update, Restore Point being created, etc. So, in short, intrusions and even malware have taken a turn toward minimalization on systems, so looking for spikes in activity likely won't get you anywhere. This is not to say that if your FTP server is turned into a warez server, you won't see a spike in activity or event volume...rather, the overall effects of an incident are most likely minimized. A user clicks a link or an application is exploited, something is uploaded to the system, and data gets exfiltrated at some point...disk forensics artifacts are minimized, particularly if the data is exfiltrated without ever writing it to disk.

Timeline Creation
When creating a timeline, I tend to take what most analysts consider a very manual process, in that I do not use tools that simply sweep through an image and collect all possible timeline data. However, there is a method to my madness, which can be seen in part in Chris's Sniper Forensics presentation. I tend to take a targeted approach, adding the information that is necessary to complete the picture. For example, when analyzing a system that had been compromised via SQL injection, I included the file system metadata and only the web server logs that contained the SQL injection attack information. There was no need to include user information (Registry, index.dat, etc.); in fact, doing so would have added considerable noise to the timeline, and the extra data would have required significantly more effort to analyze and parse through in order to find what I was looking for.

Many times when creating a timeline, I don't want to see everything all at once. When examining a Windows system, there are so many possible data sources that filling in the timeline with the appropriate sources in an iterative manner is...for me...more productive and efficient that loading everything up into the timeline all at once, and parsing things out from there. If a system had a dozen user profiles, but only one or two is of interest, I'm not about to populate the timeline with the LastWrite times of all the keys in the other user's NTUSER.DAT hives. Also, when you get to more recent versions of Windows, specific keys in the USRCLASS.DAT hive become more important, and I don't want to add the LastWrite time of all of those keys when I'm more interested in some specific values from specific keys.

Part of the iterative approach in developing the timeline is looking at the data you have available and seeing gaps. Some gaps may be due to the fact that the data no longer exists...file last access/modified times may be updated to more recent times, Event Logs may "roll over", etc. Looking at gaps has a lot to do with your analysis goals and the questions you're trying to answer, and knowing what you would need to fill that gap. Many times, we may not have access to a direct artifact (such as an event record with ID 528, indicating a login...), but we may be able to fill that gap (at least partially) with indirect artifacts (i.e., UserAssist key entries, etc.).

Feedback Loop
Timeline analysis provides a view of a system that, in most cases, an analyst wouldn't get any other way. This leads to discovering things that wouldn't otherwise be found, due in part to the view enabled via context. This context can also lead to finding those much quicker. Once you've done this, its critical for future exams that you take what you have learned and roll it back into your analysis process. After all, what good would it be for anyone for you to simply let that valuable institutional knowledge disappear? Retaining that institutional knowledge allows you to fine-tune and hone your analysis process.

Consider folks that work on teams...say, there's a team of 12 analysts. One analyst finds something new after 16 hrs of analysis. If every analyst were to take 16 hrs to find the same thing, then by not sharing what you found, your team consumes an additional 176 (16 x 11) hrs. That's not terribly efficient, particularly when it could be obviated by a 30 minute phone call. However, if you share your findings with the rest of the team, they will know to look for this item. If you share it with them via a framework such as a forensic scanner (see the Projects section of this post), similar to RegRipper (for example), then looking for that same set of artifacts is now no longer something they have to memorize and remember, as it takes just seconds to check for them via the scanner. All that's really needed is that your image intake process is modified slightly; when the image comes in, make your working copy, verify the file system of the copy, and then run the forensic scanner. Using the results, you can determine whether or not things that you've seen already were found, removing the need to remember all of the different artifacts and freeing your analysts up some in-depth analysis.

So What?
So why does all this matter? Why is it important? The short answer is that things aren't going to get easier, and if we (analysts) don't take steps to improve what we do, we're going to quickly fall further behind. We need to find and use innovative analysis techniques that allow us to look at systems and the available data in different ways, adding context and increasing our relative level of confidence in the data, particularly as some data becomes less and less reliable. We also need to consider and explore previously un- or under-utilized data sources, such as the Registry.

Consider malware detection...some folks may think that you can't use RegRipper or tools like it for something like finding malware, but I would suggest that that simply isn't the case. Consider Conficker...while the different variants escaped detection via AV scanners, there were consistent Registry artifacts across the entire family. And it's not just me...folks like MHL (and his co-authors) have written RegRipper plugins (if you deal with malware at all, you MUST get a copy of their book...) to assist them in their analysis.

The same thing can be said of intrusions...understanding Windows from a system perspective, and understanding how different artifacts are created or modified can show us what we need to focus on, and what data sources we need to engage for both direct and indirect artifacts. But these techniques are not limited to just malware and intrusions...they can be used similarly used to analyze other incidents, as well.

Updates

CyberSpeak is Back!
Ovie returns, sans Bret, to talk about browser forensics, and more...check it out!

StuxNet
ESET's paper, Stuxnet Under the Microscope, has so far been an excellent read. It's 72 pages, but there are a lot of graphics. ;-) Take a look...there's some good info there.

Addendum: Check out Symantec's Stuxnet dossier, as well...

XP Restore Points
A bit ago, I'd reached to some friends at Microsoft regarding the structure of the drivetable.txt file in XP Restore Points. I received a response recently, and I'm posting it here with a big thanks to Jim for providing it and for the permission to post it:

C:\/\\?\Volume{181b2120-e4ac-11de-a517-806d6172696f}\ 3b 0 15604 / <>

If you see the flags field with a nonzero value, this is what they mean…

0x01 SR_DRIVE_ACTIVE
0x02 SR_DRIVE_SYSTEM
0x04 SR_DRIVE_COMPRESSED
0x08 SR_DRIVE_MONITORED
0x10 SR_DRIVE_NTFS
0x20 SR_DRIVE_PARTICIPATE
0x40 SR_DRIVE_FROZEN
0x80 SR_DRIVE_READONLY
0x100 SR_DRIVE_ERROR

The reason I'd asked about this was that I'd seen the question posted by LE and hadn't seen a response. Again, thanks to Jim for sussing this one out...

Speaking of Exploits...
Both Brian Krebs and the MMPC are reporting an increase in exploits to Java (not JavaScript). This is easy for both of them to report, because the solution is simply to update your Java installation. However, what's not being mentioned anywhere is what that looks like on a system. Should forensic analysts be looking for .jar files in the browser cache? Following one of the vulnerability links from Brian's post takes us to a CVE entry that starts with:

Unspecified vulnerability in the Java Runtime Environment component in Oracle Java SE and Java for Business 6 Update 18 and 5.0 Update 23 allows remote attackers to affect...

Unspecified? So how do I know if I've been affected by it? It's relatively easy for me to check to see if I'm vulnerable...I just check my version of Java. But how would I know if I've already been affected by this? More importantly, how does an analyst examining a system figure out if this is the initial infection vector?

This isn't just an idle question I'm asking. This potentially affects victims subject to PCI investigations, and a wide range of other compliance issues.

Back from WACCI

So I got up this morning to find myself back from the WACCI conference, which is still going on, with today being the final day.

First, I want to thank Cindy and Drew for doing such a great job setting up and organizing this conference, which is geared toward computer crime investigators. The conference venue was spacious and very close to the hotel, and well organized. As with many conferences, there were often two (or more) interesting talks scheduled at the same time.

I also want to thank those who attended for...attending. One of the things I really like about conferences is the networking opportunity. I got to see some friends, like Ovie Carroll, Ken Pryor, and Mark McKinnon. I also got to make some new friends and meet some great people...Sam Brothers, Brad Garnett, Mark Lachinet, and Fergus Toolan, to name a very few.

WACCI brought together private industry analysts, LE, and academics, all in one place. This is a smallish, regional conference, but these kinds of conferences are important, as they foster relationships that lead to sharing...which was the central point of my keynote, and as it turns out, an important element of Ovie's, as well.

On Tuesday, we started off with a welcome message to the conference from the Dane County sheriff, had lunch, and then kicked off into Ovie's keynote. Having been an instructor at TBS back in the '90s, I am very familiar with presentations given right after lunch, during "the death hour". Ovie is a very dynamic speaker, and his presentation was very engaging, not only with the movement and transitions on the slides, but more importantly, with the content. He made some excellent points throughout the presentation, particularly with respect to sharing information and intel amongst LE.

For my keynote...which was the "zombie hour", as I followed both lunch and Ovie (I KID!!!)...I opted to go commando. That's right...no slides. What I tried to engage the audience in was a discussion regarding the need not just for sharing, but simply communications between LE and the private sector. Folks in the private sector, such as myself, Chris Pogue, etc., tend to see a lot of different things and run across (and very often solve) some of the same challenges met by LE. As such, there is really no need for LE to spend the time re-solving technical problems that have already been addressed by others. Reaching out can tend to decrease the amount of time needed to complete a case while increasing the volume/quality of information/data retrieved. The "Trojan Defense" comes to mind. Remember, those of us in the private sector don't just deal with intrusions and compromises, we address issues and solve problems...it just happens that the folks who call us have intrusion issues. Many of us are more than willing to assist local LE with issues where we can, which is something Chris and Maj Carole Newell talked about at the SANS Forensic Summit this past summer.

I didn't expect to solve any problems with this discussion. Instead, I wanted to engage others in a discussion about how we could engage in more sharing and communication between the sectors. For me personally, success is measured in having one member of LE who hadn't reached out before overcome those often self-imposed obstacles and share, either by asking a question or contributing something (white paper, finding, etc.).

Perhaps the most significant thing to come out of the discussion is the need for a central repository of some kind where folks (LE in particular) can go for credible information, and even provide information in a manner that protects anonymity (although there was discussion that suggested that anonymity is inversely proportional to credibility) and privacy of the poster. The MITRE CVE was suggested as a model. One of the issues I've heard time and again is that the information is out there, and the problem is that it's out there...how do you find it, and how do you find the credible information? In most cases, I agree with that, but I also think that sometimes the issue is a lack of knowledge, or perhaps something else. During the conference, several questions came up (mostly during the more social parts of the conference) where someone would say, "I've been looking all over for information on this...", and within seconds, someone else would get on their computer or smartphone, call up Google, and find highly relevant links. But that's the first step...the sharing, the asking.

As a side note to this, I've had an opportunity to start discussing something like this, a forensic artifact repository, with Troy Larson of Microsoft. However, if you haven't seen it yet, be sure to check out ForensicArtifacts.com...perhaps something like this is a start, and what's needed are forums...some open, some vetted...for discussions.

Ken Pryor has already had his comments about the first day of WACCI posted on the SANS Forensic Blog. Be sure to check these and other comments out for varying views on the conference and presentations.

I'll admit that I only attended one presentation, as I spent a lot of time engaging and networking with folks at the conference, including the vendors (Cellebrite, in particular). In particular, one of the most vocal attendees during my keynote (besides Cindy!!) was Sam Brothers. Sam is not only well-published in mobile forensics, but he's also an amazing magician, regaling us with some truly incredible card tricks! Listening and talking to Sam, I know who I'm going to go to if when I encounter any forensic issues with mobile devices!

In closing, I just want to thank Cindy and Drew again for putting together such a great conference, and Cindy in particular for inviting me (and the rest of us) to her home for a great social event. I also want to thank Mark McKinnon for sharing such wonderful gifts with us...Bells Two-Hearted Ale (to which Sam whispered, "this is awesome!!"), steak brats, and Michigan cherry gourmet coffee. A great big "THANK YOU" to everyone who attended and made this conference a great success!

Updates

I know, I haven't posted in a while...but then, I haven't really had a lot to post about, as I've been busy completing one project (book) and getting kicked off on another one...

Speaking
I've got a couple of upcoming speaking engagements in the next couple of months...

WACCI - I think I'm giving keynote 2 on Tues; I'm strongly considering using a discussion-style approach (as in "no PPT"), and broaching the subject of engaging and sharing between LE and the private sector in some manner. This is a bit of a sticky wicket, as one cannot simply pontificate on the need for LE to reach to the private sector to engage and share; without being LE, I'm afraid that I'd have little credibility in the matter.

PFIC2010 - I'll be heading to Utah in Nov for a couple of days, to present on "Windows System Forensics". Yeah, I know...lots of room there for me to mess this one up! ;-)

Windows Registry Forensics
I recently finished work on the Windows Registry Forensics book, including sending in the DVD master.

Here's a short description of the chapters:
Ch 1 - This chapter addresses some of what I consider to be the basic concepts of "analysis"; this book is about Registry analysis and as such, I thought it was important to lay out what I see to constitute Registry analysis. This chapter also goes into the purpose and structure of the Registry, in order to build a foundation for the analyst, for the rest of the book.

Ch 2 - This chapter addresses the tools that can be used to perform analysis of the Registry, in both live and post-mortem situations. This is kind of important, I think, because there are issues such as malware infections that really overwhelm both IT admins and responders; identifying Registry artifacts of an infection can allow you to comb the infrastructure using native or custom tools for other infected systems.

Note: This chapter does not address any commercial forensic analysis applications, for the simple reason that I did not have access to any of them, beyond Technology Pathways' ProDiscover.

Ch 3 - This chapter addresses Registry analysis from a system-wide perspective; that is, it addresses the files that compromise the system hives, and what information that is of value to an analyst that can be extracted from the hives. For example, I discuss what information is available from the SAM hive, and also include some tools that you can use to determine if a user has a password, and how you can crack it.

Ch 4 - This chapter addresses analyzing the user's hives.

With chapters 3 and 4, I took a bit of a different approach than I have in the past. Rather than listing key and value after key and value, I provided examples of how the information (key name, key LastWrite time, values, data, etc.) could be and have been used during incident response or during an examination.

The DVD includes a copy of the RegRipper tools (including the Plugin Browser), as well as all of the latest plugins that I've written, as of mid-Sept, 2010.

Open Source
Having finished the Registry book, I'm working diligently on my chapters of Digital Forensics with Open Source Tools, which I'm co-authoring with Cory Altheide (it was Cory's idea, and he's handling the lion's share of the writing).

Projects
I've run across a couple of interesting issues during analysis recently that I wanted to document, and the best way I found to do was to create what I'm referring to as a forensic system scanner, based on tools such as RegRipper and Nessus. The idea is that rather than memorizing the various things I've looked for or found, I can now mount an acquired image as a drive letter, and then run a number of plugins across the image. Much like RegRipper, the plugins can parse the Registry, but what I've done now is included checks for the file system, as well.

I'm designing/writing this scanner to be run against a mounted (via ImDisk, etc.) image, or against a system accessed via F-Response. Given this, it will also work with other mounting methods, such as Windows 7's ability to mount .vhd files. If you have a method for mounting .vmdk files, you could also use that. At this point, I've got a couple/half dozen or so working plugins and things seem to be moving smoothly in that regard. One plugin looks for .tmp files with 'MZ' signatures in the user profiles "Local Settings\Temp" directories...it gets the information about the profile paths from the ProfileList key. That plugin also checks for .exe files with 'MZ' signatures, as well. In both cases, if it finds any such files, it also computes an MD5 hash for each file.

Another plugin checks for a Zeus/Zbot infection. This plugin checks the UserInit value in the Software hive for the addition of "sdra64.exe", as well as checks the system32 directory within the image for the existence of the file. This plugin can be expanded to include any of the other file names that have been used, as well.

Chris Pogue has mentioned seeing the Perfect Key Logger in a number of exams; it is pretty simple and straightforward to write a plugin that checks for this, as well.

As with RegRipper, I can run either individual plugins, or lists of plugins, which I've taken to calling "profiles".

My overall thinking is that there can be a lot of things to look for out there, and if I can codify a check, I don't have to keep trying to remember all of them. God knows I'll get through an exam, deliver the final report, and think, "wow, I forgot to check for this...".

This scanner is NOT meant to completely comprehensive, nor is it meant to replace deep analysis. My goal here is to produce something that can be used as part of an in-processing procedure; get an image, verify it, copy it, then run the scanner against the working copy of the image. The report can then be provided along with either the image, or with selected files extracted from the image, to an analyst. This is intended to be more of a sweeper, but also a force multiplier...think of it; someone writes a check or plugin, and provides it to their team. Now, everyone on the team has the ability to run the same check, even though they don't all see the same thing on every engagement. With a central repository of well-documented plugins, we now have retention of corporate knowledge from each analyst.

Addendum: I was reading this MMPC post regarding Camec.A (they should have entitled the post "Getting a Brazilian"), and it occurred to me that this would be a great example of using the scanner I mentioned above. Specifically, you could easily write a plugin to check for this issue; one way to write it would be to simply check for the DLL files mentioned in the post, and if you find them, get and compare their hashes. Another way to write the plugin would be to add a Registry query for BHOs (RegRipper already has such a plugin), and then check for the files.

Again, once the plugin is written and added to the tool's plugins directory, every system that this is run against would be checked; the analyst running the scan would not need to know (or have memorized) the specifics indicators of the malware.

Another WFA 2/e Review

I received the following comments from Allen Wheeler (a Systems Engineer with Troll Systems) today via email, and with his permission, I wanted to share his comments with you:

I just wanted to tell you how impressed I am with how thoroughly you cover the methods covered in your book. Usually when I pick up a book like this I’m prepared for more questions than when I started but that’s not the case with Windows Forensic Analysis. It’s elegantly worded and easy to follow which is hard to find when it comes to technical books. I read for about 8 hours straight yesterday on a trip back from the east coast and I still didn’t want to put it down. As a long time Windows user, you’ve helped fill in a lot of blanks and I feel like I’ll have a lot more flexibility and power by employing many of your tools and techniques as a Systems Engineer who spends a lot of time in this OS. Thank you!

Allen also posted a review of WFA 2/e on Amazon. Thanks, Allen, for your words, and for feeling led to reach out and share your thoughts, not just with me, but with others!

It's those darned DLLs again...

There's been a lot (and I mean a LOT) of traffic on the interwebs lately regarding a vulnerability associated with how DLLs are loaded on Windows systems. In short, the idea is that due to how applications look for DLLs that aren't explicitly defined by their path, and how the current working directory can be defined (includes how an application is launched), the application can end up loading a malicious DLL that is in a non-traditional directory.

First, some background/references:
DLL Search Order Vuln (circa 2000)
MSDN DLL Search Order article
ACROS Security's recent announcement
Recent Mandiant blog post (author: Nick Harbour)
SANS ISC blog post (author: Bojan Zdrnja)
ComputerWorld article
Register article (UK)
Rapid7 blog post (author: HD Moore)
Metasploit blog post (author: HD Moore)
SecDev blog post (author: Thierry Zoller)
MS Research and Defense blog
MS Security Advisory 2269637
MS KB Article 2264107 (includes a Registry change)

This was originally something that was pointed out 10 years ago...the new twist is that it has been found to work on remote resources. MS has issued instructions and guidance on how to properly use the appropriate APIs to ensure the safe loading of libraries/DLLs. However, this, combined with the findings from ACROS and others (see the paper referenced in HD's Rapid7 blog post), pretty much tells us that we have a problem, Houston.

The DLL search order vulnerability is a class of vulnerability that can be implemented/exploited through several avenues. Basically, some mechanism needs to tell an application that it needs to load a DLL (import table, Registry entry, etc.) through an implicit (i.e., not explicitly defined) path. The application will then start looking for the DLL in the current working directory...depending on how this exploit is implemented, this may be the directory where the application resides, or it may be a remote folder accessible via SMB or WebDAV. Therefore, the application starts looking for the DLL, and as there is no validation, the first DLL with the specified name is loaded. One thing to keep in mind is that the DLL cannot break required functionality needed by the application, or else the application itself may cease to work properly.

Okay, so what does all of this mean to forensic analysts? So some user clicks on a link that they aren't supposed to and accesses a specific file, and at the same time a malicious DLL gets loaded, and the system becomes infected. Most often, forensic analysts end up addressing the aftermath of that initial infection, finding indications of secondary or perhaps tertiary downloads. But what question do customers and regulatory bodies all ask?

How was the system originally infected?

What they're asking us to do is, to do a root cause analysis and determine the initial infection vector (IIV).

Some folks may feel that the method by which the DLL is designated to load (import table, file extension association, etc.) is irrelevant and inconsequential, and when it comes to a successful exploit, they'd be right. However, when attempting to determine the root cause, it's very important. Take Nick's post on the Mandiant blog, for example...we (me, and the team I work with) had seen this same issue, where Explorer.exe loaded ntshrui.dll, but not the one in the C:\Windows\system32 directory. Rather, the timeline I put together for the system showed the user logging in and several DLLs being loaded from the system32 directory, then C:\Windows\ntshrui.dll was loaded. The question then became, why was Explorer.exe loading this DLL? It turned out that when Explorer.exe loads, it checks the Registry for approved shell extensions, and then starts loading those DLLs. A good number of these approved shell extensions are listed in the Registry with explicit paths, pointing directly to the DLL (in most cases, in the system32 directory). However, for some reason, some of the DLLs are listed with implicit paths...just the name of the DLL is provided and Explorer.exe is left to its own devices to go find that DLL. Ntshrui.dll is one such DLL, and it turns out that in a domain environment, that particular DLL provides functionality to the shell that most folks aren't likely to miss; therefore, there are no overt changes to the Explorer shell that a user would report on.

Yes, I have written a plugin that parses the Registry for approved shell extensions. It's not something that runs quickly, because the process requires that the GUIDs that are listed as the approved shell extensions then be mapped to the CLSID entries...but it works great. This isn't as nifty as the tools that Nick and HD mention in their blog posts, but it's another avenue to look to...list all of the approved shell extensions listed with implicit paths, and then see if any of those DLLs are resident in the C:\Windows directory.

Again, there's a lot of great information out there and a lot to digest with respect to this issue, but the overarching issue that I'm most interested in now is, what does this mean to a forensic analyst, and how can we incorporate a thorough examination for this issue into our processes? Things that forensic analysts would want to look for during an exam would be the MRU lists for various applications...were any files recently accessed or opened from remote resources (thumb drives, remote folders, etc.)? If there's a memory dump available (or the output of handles.exe or listdlls.exe) check to see if there are any DLLs loaded by an application that have unusual paths.

Some of the issues you're going to run into is that you may not have access to the remote resource, and while you may see indications of a file being accessed, you won't have any direct indication that a DLL was in the same folder. Or, if the vulnerability was exploited using a local resource, AV applications most likely are not going to flag on the malicious DLL. In some cases, a timeline may provide you with a sequence of events...user launched an application, remote file was accessed, system became infected...but won't show you explicitly that the malicious DLL was loaded. This is why it is so important for forensic analysts and incident responders to be aware of the mechanisms that can cause an application to load a DLL.

One final note...if you're reading MS KB article 2264107, you'll see that at one point, "CWDIllegalInDllSearch" is referred to as a Registry key, then later as a value. Apparently, it's a value. Kind of important, guys. I'm just sayin'...

I've written a plugin that checks for the mentioned value, and updated another plugin that already checks the Image File Execution Options keys for Debugger values to include checking for this new value, as well.

Links

Who You Gonna Call?
Tom Liston had a great post to the ISC blog a bit ago entitled Incident Reporting - Liston's "How To" Guide. This humorous bent on the situation simply oozed truthiness. Many moons ago, I was on the receiving end of the "abuse@" emails for a telecomm provider, and marveled at the emails threatening litigation as a result of...and get this...a single ICMP packet received by some home user's firewall. Seriously.

One thing I would add to that, particularly for larger organizations...seek a relationship with professional responders before (because one will...if one hasn't, you simply haven't been paying attention) an incident occurs, and work with them to understand how to best help yourself. What really turns most organizations off to responding to incidents in general is the overall impact to their organization...having people on-site, engaging their staff, taking them away from keeping the email server up...and there's the price tag, to boot. But the problem is that in almost every instance, every question asked by the responders is answered with "I don't know"...or with something incorrect that should have been "I don't know". Questions like, what first alerted you to the incident? Where is does your sensitive data live in your infrastructure? How many egress points/ISPs do you have? Do you have any firewalls, and if so, can we see the logs? It's questions like these that the responders need to have answered so that they can scope the engagement (how many people and how much equipment to send), and determine how long it will take to complete the engagement. To be honest, we really don't want to have to engage your staff any more than we have to...we understand that as the engagement goes on, they become less and less interested, and less and less responsive.

Art Imitates Life
My wife and I watched Extraordinary Measures recently...we both like that feel-good, "based on a true story" kind of movie. After watching the movie, it occurred to me that there are a lot of parallels between what was portrayed in the movie and our industry...specifically, that there are a lot of tools and techniques that are discussed, but never see common usage. Through sites such as eEvidence, I've read some very academic papers that have described a search technique or some other apparently very useful technique (or tool), but we don't see these things come into common usage within the industry.

IIVs
H-Online has a nice CSI-style write up on investigating a "PDF timebomb". I know a lot of folks don't want to necessarily look at (I hesitate to say "read") some really dry technical stuff, particularly when it doesn't really talk about how a tool is used. A lot of available tools have a lot of nice features, but too many times I think a lot of us don't realize that espousing the virtues and capabilities of a tool do little to really don't get...after all, we may have made a connection that others simply don't see right away. So things like this are very beneficial. Matt Shannon cracked the code on this and has published Mission Guides.

So what does this have to do with initial infection vectors, or IIVs? Well, malware and bad guys get on a system somehow, and H-Online's write-up does a good job of representing a "typical" case. I think that for the most part, many of us can find the malware on a system, but finding how it got there in the first place is still something of a mystery. After all, there are a number of ways that this can happen...browser drive-by, infected attachment through email, etc. We also have to consider the propagation mechanism employed by the malware...Ilomo uses psexec.exe and the WinInet API to move about the infrastructure. So, given the possibilities, how do we go about determining how the malware got on the system?

Book News - Translations
I received a nice package in the mail recently...apparently, WFA 2/e has been translated into French...the publisher was nice enough to send me some complimentary copies! Very cool! I also found out that I will be seeing copies of WFA 2/e in Korean sometime after the first of the year, and in a couple of weeks, I should be seeing WFA 1/e in Chinese!

Malware Communications
Nick posted recently on different means by which malware will communicate off of Windows systems, from a malware RE perspective. This is an interesting post...like I said, it's from an RE perspective. Nick's obviously very knowledgeable, and I think that what he talks about is very important for folks to understand...not just malware folks, but IR and even disk forensics types. I've talked before (in this blog and in my books) about the artifacts left behind through the use of WinInet and URLMON, and there are even ways to prevent these artifacts from appearing on disk. The use of COM to control IE for malicious purposes goes back (as far as I'm aware) to BlackHat 2002 when Roelof and Haroon talked about Setiri.

Evidence Cleaners
Speaking of disk analysis, Matt has an excellent post on the SANS Forensic blog that talks about using "evidence cleaners" as a means for identifying interesting artifacts. I think that this is a great way to go about identifying interesting artifacts of various tools...after all, if someone wants to "clean" it, it's probably interesting, right? I've said for years that the best places to go to find malware artifacts are (a) AV write-ups and (b) MS's own AutoRuns tool (which now works when run against offline hives).

As a side note, I had a case where an older version of WindowWasher had been run against a system a short time before acquisition, and was able to recover quite a bit of the deleted Registry information using regslack.

Artifacts: Direct, indirect

In reviewing some of the available materials on Stuxnet, I've started to see somethings that got me thinking. Actually, what really got me thinking was what I wasn't seeing...

To begin with, as I mentioned here, the .sys files associated with Stuxnet are apparently signed device drivers. So, I see this, and my small military mind starts churning...device drivers usually have entries in the Services keys. Thanks to Stefan, that was confirmed here and here.

Now, the interesting thing about the ThreatExpert post is the mention of the Enum\Root\LEGACY_* keys, which brings us to the point of this post. The creation of these keys is not a direct result of the malware infect, but rather an artifact created by the operating system, as a result of the execution of the malware through this particular means.

We've seen this before, with the MUICache key, way back in 2005. AV vendors were stating that malware created entries in this key when executed, when in fact, this artifact was an indirect result of how the malware was launched in the testing environment. Some interesting things about the LEGACY_* keys are that:

1. The LastWrite time of the keys appear to closely correlate to the first time the malicious service was executed. I (and others, I can't take all of the credit here) have seen correlations between when the file was created on the system, Event Log entries showing that the service started (event ID 7035), and the LastWrite time of the LEGACY_* key for the service. This information can be very helpful in establishing a timeline, as well as indicating whether some sort of timestomping was used with respect to the malware file(s).

2. The LEGACY_* key for the service doesn't appear to be deleted if the service itself is removed.

So, in short, what we have is:

Direct - Artifacts created by the compromise/infection/installation process, such as files/Registry keys being created, deleted, or modified.

Indirect - Ancillary (secondary, tertiary) artifacts created by the operating system as a result of the installation/infection process running in the environment.

So, is this distinction important, and if so, how? How does it affect what I do?

Well, consider this...someone gets into a system or a system becomes infected with malware. There are things that can be done to hide the presence of the malware, intrusion or the overall infection process itself. This is particularly an issue if you consider Least Frequency of Occurrence (LFO) analysis (shoutz to Pete Silberman!), as we aren't looking for the needle in haystack, we're looking for the hay that shouldn't be in the haystack. So, hide all of the direct artifacts, but how do you go about hiding all of the indirect artifacts, as well?

So, by example...someone throws a stone into a pool, and even if I don't see the stone being thrown, I know that something happened, because I see the ripples in the water. I can then look for a stone. So let's say that someone wants to be tricky, and instead of throwing a stone, throws a glass bead, something that is incredibly hard to see at the bottom of the pool. Well, I still know that something happened, because I saw the ripples. Even if they throw a stone attached to a string, and remove the stone, I still know something happened, thanks to the ripples...and can act/respond accordingly.

Also, indirect artifacts are another example of how Locard's Exchange Principle applies to what we do. Like Jesse said, malware wants to run and wants to remain persistent; in order to do so, it has to come in contact with the operating system, producing both direct and indirect artifacts. We may not find the direct artifacts right away (i.e., recent scans of acquired images using up-to-date AV do not find Ilomo...), but finding the indirect artifacts may lead us to the direct ones.

Another example of an indirect artifact is web browsing history and Temporary Internet Files associated with the "Default User" or LocalService accounts; these indicate the use of the WinInet API for off-system communications, but through an account with System-level privileges.

Thoughts?

Ugh

Sorry, I just don't what other title to use...I wasn't able to come up with something witty or pithy, because all I kept thinking was "ugh".

The "ugh" comes from a question (two, actually, that are quite similar) that appear over and over again in the lists and online forums (forii??)...

I have an image of a system that may have been compromised...how do I prove that data was exfiltrated/copied from the system?

Admit it...we've all seen it. Some may have actually asked this question.

Okay, this is the part where, instead of directly answering the question, I tend to approach the answer from the perspective of getting the person who asked the question to reason through the process to the answer themselves. A lot of people really hate this, I know...many simply want to know which button to click in their forensic application that will give them a list of all of the files that had been copied from the system (prior to the image being acquired).

So, my question to you is...with just an image of supposedly victim system, how would you expect to demonstrate that data was copied or exfiltrated from that system?

Well, there are a couple of things I've done in the past. One is to look for indications of collected data, usually in a file. I've seen this in batch files, VBS scripts, and SQL injection commands...commands are run and the output is collected to a file. From there, you may see additional commands in the web server logs that indicate that the file was accessed...be sure to check the web server response code and the bytes sent by the server, if they're recorded.

In other instances, I've found that the user had attached files to web-based email. Some artifacts left after accessing a GMail account indicated that a file was attached to an email and sent to another address. In several instances, this was a resume...an employee was actively looking for a job and interviewing for that position while on company time. Based on file names and sizes (which may or may not be available), used in conjunction with file last accessed times, we've been able to provide indications that files were sent off of the system.

What else? Well, there's P2P applications...you may get lucky, and the user will have installed one that clearly delineates which files are to be shared. Again, this may only be an indication...you may have to access the P2P network itself and see if the file (name, size, hash) is out there.

What about copying? Most analysts are aware of USB devices by now; however, there is still apparently considerable confusion over what indications of the use of such devices reside within an image. One typical scenario is that a user plugs such a device in and copies files to the device...how would you go about proving this? Remember, you only have the image acquired from the system. The short answer is simply that you can't. Yes, you can show when a device was plugged in (with caveats) and you may have file last access times to provide additional indications, but how do you definitively associate the two, and differentiate the file accesses from, say, a search, an AV scan, or other system activity?

I hope that this makes sense. My point is that contrary to what appears to be popular belief, Windows systems do not maintain a list of files copied off of the system, particularly not in the Registry. If your concern is data exfiltration (insider activity, employee takes data, intruder gets on the system and exfils data...), consider the possible scenarios and demonstrate why they would or wouldn't be plausible (i.e., exfil via P2P would not be plausible if no P2P apps are installed). Reason through the analysis process and provide clear explanations and documentation as to what you did, what you found, and justify your findings.

Exploit Artifacts redux, plus

As a follow-up to my earlier post where I discussed Stuxnet, I wanted to take a moment to update some of what's come out on this issue in the past 12 days.

Claus wrote a great post that seems pretty comprehensive with respect to the information that's out there and available. He points to the original posts from VirusBlokAda, as well as two posts from F-Secure, the first of which points to the issue targeting SCADA systems. According to the second post:

...the Siemens SIMATIC WinCC database appears to use a hardcoded admin username and password combination that end users are told not to change.

Does that bother anyone?

Okay, all that aside, as always I'm most interested in how we (forensic analysts, incident responders) can use this information to our benefit, particularly during response/analysis activities. This PDF from VirusBlokAda, hosted by F-Secure has some very good information on artifacts associated with this malware. For example, there are two digitally signed driver files, mrxnet.sys and mrxcls.sys (found in the system32\driver directory), as well as several hidden (via attributes) LNK files and a couple of .tmp files. There are also two other files in the system32\inf directory; oem6c.pnf and oem7a.pnf, both of which reportedly contain encrypted data. This MS Threat Encyclopedia entry indicates that these files (and others) may be code that gets injected into lsass.exe. This entry points to online hosts reportedly contacted by the worm/downloader itself, so keep an eye on your DNS logs.

As the two .sys files are drivers, look for references to them both in the Services keys. This also means that entries appear in the Enum\Root keys (thanks to Stefan for the link to ThreatExpert).

This post from Bojan of the SANS ISC has some additional information, particularly that the LNK files themselves are specially-crafted so that the embedded MAC times within the LNK file are all set to 0 (ie, Jan 1, 1970). Outside of that, Bojan says that there is nothing special about the LNK files themselves...but still, that's something.

MS also has a work-around for disabling the display of icons for shortcuts.

So, in summary, what are we looking for? Run RegRipper and see if there are entries in the Services and Enum\Root (I have a legacy.pl plugin, or you can write your own) keys for the drivers. Within the file system (in a timeline), look for the driver files, as well as the .tmp and .pnf files. Should you find those, check the Registry and the appropriate log file (setupapi.log on XP) for a recently connected USB device.

Speaking of artifacts, Rebhip.A looks like a lot of fun...

For those interested, here's some PoC code from Exploit-DB.com.

Addendum: Anyone write a plugin for Rebhip.A yet? Also, I almost missed Pete's post on Stuxnet memory analysis...