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.

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?

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...

I posted yesterday, and included some discussion of exploit artifacts, the traces left by an exploit, prior to the secondary download. When a system is exploited, something happens...in many cases, that something is an arbitrary command being run and/or something being downloaded. However, the initial exploit will itself have artifacts...they may exist only in memory, but they will have artifacts.

Let's look at an example...from the MMPC blog post on Stuxnet:
What is unique about Stuxnet is that it utilizes a new method of propagation. Specifically, it takes advantage of specially-crafted shortcut files (also known as .lnk files) placed on USB drives to automatically execute malware as soon as the .lnk file is read by the operating system. In other words, simply browsing to the removable media drive using an application that displays shortcut icons (like Windows Explorer) runs the malware without any additional user interaction. We anticipate other malware authors taking advantage of this technique.

So the question at this point is, what is unique about the .lnk files that causes this to happen? A while back, there was an Excel vulnerability, wherein if you opened a specially-crafted Excel document, the vulnerability would be exploited, and some arbitrary action would happen. I had folks telling me that there ARE NO artifacts to this, when, in fact, there has to be a specially-crafted Excel document on the system that gets opened by the user. Follow me? So if that's the case, if I search the system for all Excel documents, and then look for those that were created on the system near the time that the incident was first noticed...what would I be looking for in the document that makes it specially-crafted, and therefore different from your normal Excel document?

So, we know that with Stuxnet, we can look for the two files in an acquired image (mrxcls.sys, mrxnet.sys) for indications of this exploit. But what do we look for in the malicious LNK file?

Why is this important? Well, when an incident occurs, most organizations want to know how it happened, and what happened (i.e., what data was exposed or compromised...). This is part of performing a root cause analysis, which is something that needs to be done...if you don't know the root cause of an incident and can't address it, it's likely to happen again. If you assume that the initial exploit is email-borne, and you invest in applying AV technologies to your email gateway, what effect will that have if it was really browser-borne, or the result of someone bringing in an infected thumb drive?

The MMPC site does provide some information as to the IIV for this issue:
In addition to these attack attempts, about 13% of the detections we’ve witnessed appear to be email exchange or downloads of sample files from hacker sites. Some of these detections have been picked up in packages that supposedly contain game cheats (judging by the name of the file).

Understanding the artifacts of an exploit can be extremely beneficial in determining and addressing the root cause of incidents. In the case of Stuxnet, this new exploit seems to be coupled with rootkit files that are signed with once-legitimate certificates. This coupling may be unique, but at the same time, we shouldn't assume that every time we find .sys files signed by RealTek, that the system had fallen victim to Stuxnet. Much like vulnerability databases, we need to develop a means by which forensic analysts can more easily determine the root cause of an infection or compromise; this is something that isn't so easily done.

Addendum
Another thing that I forgot to mention...we see in the MMPC post that the files are referred to, but nothing about the persistence mechanism. Do we assume that these files just sit there, or do we assume that they're listed as device drivers under the Services key? What about the directory that they're installed in? Do they get loaded into a "Program Files\RealTek" directory, or to system32, or to Temp? All of this makes a huge difference when it comes to IR and forensic analysis, and can be very helpful in resolving issues. Unfortunately, AV folks don't think like responders...as such, I really think that there's a need for an upgrade to vulnerability and exploit analysis, so that the information that would be most useful to someone who suspects that they're infected can respond accordingly.

One of the things I really like about this industry is that there's always something new...a new challenge, a new twist to old questions, etc. This is fun, because I like to see about approaching these issues with a novel approach.

Here's an example; I recently found this article discussing an issue with web cams on laptops issued to high school students having been allegedly turned on remotely and used to monitor students in their homes. More and more laptops are available with built-in web cams, and web cams are relatively inexpensive. How long before there are stalking cases or civil suits in which the victim's web cam is enabled? The "Trojan Defense" (ie, the malware did it, not me) has been around for a while, so how long before we can expect to see other devices (web cams, in particular) being recognized as a source for illicit images, or somehow involved in other issues or crimes? Not long afterward, we're going to hear, "hey, I didn't do it...it was the virus."

So the novel approach comes in when you start to consider, what are the artifacts of the use of a web cam on a system? How do you tell if a web cam (or any other device) has been used, and more importantly, how do you address attribution? Was it the local user that started the web cam, was it malware, or was the web cam activated remotely by a legitimate user (or, activated remotely by someone with access to a legitimate user account)?

So what happens when this sort of issue lands on an analysts desk? This may be an example of one of those new, we haven't seen this kind of thing before issues. There very likely isn't a public repository of data, artifacts, and analysis plans somewhere, is there? Maybe there's a private one, but how does that help folks who don't have access to it, particularly if it's only accessible by a very small group of individuals? Where do folks go to start developing answers to questions like those in the previous paragraph, and once they determine those answers, what do they then do with the information? Is it available to the next analyst who runs into this sort of thing, or do we have to start all over again?

There's a good deal of research that goes on in a number of areas within the IR/DF community...file carving, for example. However, a lot of new issues that land on an analyst's desk are just that...new. New issue, new device, new operating system. Most of use are intimately familiar with the fact that the automated analysis approach we used in XP systems was, in some cases, broken when we got our first Vista system in for analysis. Oh, and hey...guess what? Windows 7 is out...in some ways, we need to start all over again.

So what happens when something new...some new issue, operating system, or application...comes out? Sometimes, someone puts forth the effort to conduct analysis and document the process and the findings, and then make that available, like what was done with Limewire examinations, for example.

Speaking of artifacts, I've posted before about browser stuff to look at beyond the traditional TypedURLs key and index.dat files. Well, as it happens, there appears to be data that indicates that it's not so much the browser that's being targeted...it's the stuff running in support of the browser. Brian Krebs posted recently about BLADE (no, not this Blade); the point of the post is that it isn't the browser that's the issue, it's the stuff running behind the scenes; the plugins, the add-ons, etc.

Consider this...someone gets an email or IM with a link to a PDF or other file format, and they click on it. Their default browser is opened, but it isn't the browser that's popped...it's the old/unpatched version of Adobe Reader (or some other unpatched add-on) that results in the system being compromised. Ultimately, a compromise like this could lead to significant losses. So while there will be artifacts in the browser history, this tells us that we need to look beyond that artifact if we're going to attribute an incident to the correct root cause; finding the first artifact and attributing the issue to a browser drive-by may not be correct, and in the long run, may hurt both your employer's reputation, and most certainly your customer. What happens if your customer reads your report and updates or changes the browser used throughout their infrastructure, only to get hit again?

Every now and then I get emails from folks who've found my blog or one of my books useful, whether it has to do with work, school, or a hobby. For the most part, these emails are positive...I haven't really received any negative comments, per se...but I also try to see if there's a way to have these comments made publicly available in some manner. Recently, one of the folks who emailed me consented to allowing me to post the body of their email to my blog...so, here it is...

I'll try to make this short. I have your first book and on more than one occasion, I've referenced it for information. A fellow examiner asked me about it one time and even read through it to some extent. He later commented that it was a pretty good book but the author wasn't even a certified examiner. I let it go because everyone has their opinion. About a week or so ago, he was preparing to testify in a case and the subject of external drives and USB flash drives came up. I showed him your chapters concerning the registry and USB storage. Long story way too long, his newly gained knowledge of the registry and USB helped out enormously during the trial to the point that the other side didn't even have their expert take the stand. He is now a converted HC follower and has plans to purchase your upcoming WFA 2/e as I will be doing the same. Anyhow, I thought you would find this pretty amusing....I did.

Pretty amusing, definitely. Cory Altheide and I conducted the first publicly available research into USB removable storage device artifacts on Windows systems many, many moons ago, and since then, I'd have to say that it's probably the most popular and most asked-about set of artifacts...and maybe even one of the most misunderstood.

I wanted to take my last post on this topic just a bit further...

I received an email from someone recently asking me about checklists for determining the attack vector of an incident. Yeah, I know...that's a pretty broad question, but I do see the issue here. Sure, some folks are "finding stuff", but the question is now becoming, how did it get there? That's the next logical question, I suppose, and it is being asked.

Over on F-Secure, I saw this post this morning about a PHP IRC Bot. This is just one example, but once the IRC bot is located on the infected system, how does one go about determining how it got there? One thought would be to look at the method you used to locate the bot...say, scanning with an AV scanner...and use that as a starting point. What did the AV scanner identify the malware as? Once you get a name, go to the vendor's web site and see what it says about infection vectors. Again...this is one way to go about the process, not the way.

Another example is this...I'm sure that finding a bot or backdoor isn't too difficult, particularly if you have volatile data or the malware is easily detected by the scanner you're using. But how did it get there? Was the attack vector a downloader from a malicious web site that pulled down a Trojan or bot that was then used to put the backdoor on the system?

At this point, you might be thinking..."who cares?" After all, you found the bad stuff, right? But is that really sufficient? If you you don't discover the root cause, how do you protect yourself in the future? How do you protect other systems?

Another aspect to consider are the application artifacts. Hogfly recently posted on intel gathering...what are the artifacts of the use of the three applications he listed in the post? Does anyone know? After all, one thing to be concerned about is USB devices...but how many are considering remote storage repositories? Anyone remember this three year old blog post regarding the GMail Drive? Some of the artifacts listed in the post are easily added to any sort of Registry scanning tool... ;-)

I'm thinking that it's about time to add a little something to our investigative process. Artifact repositories will very likely make it much easier to determine root causes, keeping in mind, though, that such a thing isn't really a comprehensive solution. Training or instruction in OS and application basics will provide a better understanding of how to determine root causes, particularly when there a multiple possibilities.

I see posts in a number of lists asking about (and for) forensic artifacts for P2P applications...lately, there have been several about LimeWire. For the most part, general questions regarding P2P apps drift toward...well...general questions, like "has anyone ever dealt with this" kind of questions. When specific apps are named, like LimeWire, specific questions are asked, such as "what are the contents of this file?" I can easily see how these issues would be relevant to cases involving files being shared, whether they are illicit images, or company proprietary information and IP.

It has occurred to me, time and again, that what is needed is a central repository of forensic artifact information. Something like a searchable database portal where you can login, type in a few keywords, and obtain a listing of relevant articles. These articles could be downloadable PDF documents...something that you can take with you, print out, etc. These articles would be written for forensic analysts, by forensic analysts...that way, they would contain relevant information, as well as have tips for techniques to use for data extraction and analysis, or even the tools themselves.

Now, the question becomes...if this repository were to contain more than just a few articles on forensic artifacts of P2P applications, but instead covered other areas, and even addressed other OSs, is this something you would pay for? Far too often in this community, when something is provided for free, it languishes unused...be it tools, information, or books. An annual subscription fee would be necessary to keep something like this up and running.

Now, articles would be updated, of course, and information would constantly be added to the library. Something like this could also have a forum where information could be exchanged, and clarify questions could be asked. Also, a subscriber could request additional information or make a request for the latest version of the app to be examined.

Is there anything else you'd like to see, or wouldn't like to see in something like this? Does this make any sense at all?

As a follow-on to the tool testing posts, I wanted to throw something else out there...specifically, I'll start with a comment I received, which said, in part:

Tool criteria include[sic] whether the data the tool has acquired actually existed.

This is a slightly different view of RAM acquisition (or "memory dumping") than I've seen before...perhaps the most common question/concern is more along the lines of, does exculpatory evidence get overwritten?

One of the issues here is that unlike a post-mortem acquisition of a hard drive (ie, the traditional "hook the drive up to a write-blocker, etc."), when acquiring or dumping RAM, one cannot use the same method and obtain the same results...reproduceability is an issue. Because you're acquiring the contents of physical memory from a running system, at any given point in time, something will be changing; processes process, threads execute, network connections time out, etc. So, similar to the live acquisition of a hard drive, you're going to have differences (remember, one of the aspects of cryptographic hash algorithms such as MD5 is that flipping a single bit will produce a different hash). I would suggest that the approach we should take to this is to accept it and document it.

That being said, what are some of the questions that we can anticipate addressing, and how would/should we answer them? I'll take a stab at a couple of basic questions (and responses), but I'd really like to see what others have to say:

1. Did you acquire this data using an accepted, validated process?

In order to respond to this question, we need to develop a process, in such a way as to validate it, and get it "accepted". Don't ask me by whom at this point...that's something we'll need to work on.

2. Did this process overwrite evidence, exculpatory or otherwise?

I really think that determining this is part of the validation process. In order to best answer this question, we have to look at the process that is used...are we using third-party software to do this, or are we using some other method? How does that method or process affect or impact the system we're working with?

3. Was this process subverted by malware running on the system?

This needs to be part of the validation process, as well, but also part of our analysis of the data we retrieved.

4. Did you add anything to this data once you had collected it, or modify it in any way?

This particular question is not so much a technical question (though we do have to determine if our tools impact the output file in anyway) as it is a question for the responder or examiner.

As you can see, there's still a great deal of work to be done. However, please don't think for an instant that I'm suggesting that acquiring the contents of physical memory is the be-all and end-all of forensic analysis. It's a tool...a tool that when properly used can produce some very valuable results.

An interesting question appeared on one of the listservs a bit ago..."what is an investigator's protocol for demonstrating intentional erasure of data, ostensibly done by the user to remove evidence from a system?" This is an interesting question and since it doesn't fit neatly into one of the FAQ sections at the end of a chapter in my next book, I thought I'd address that question here in the blog.

The first thing I would look at is the level of erasure that has occurred. One of the first places to check is the Recycle Bin. Many users delete files through the Explorer shell, and they end up in the Recycle Bin...from there, some users don't bother to empty the Recycle Bin. However, this does show an intentional attempt to remove data, based on the actions that are required to move the files to the Recycle Bin.

I have seen instances in which the user has deleted files (ie, sent to the Recycle Bin) and then emptied the Recycle Bin. In such cases, the last modification time on the INFO2 file in the Recycle Bin may give you an idea of when the Recycle Bin was emptied. Again, this may show intent.

In some cases, many of the sectors for the files were then overwritten due to the limited defrag that occurs about every 3 days on a Windows XP system, making the deleted files unrecoverable.

I would also suggest checking the contents of the UserAssist keys, and on XP systems, the Prefetch folder, to see if there are any artifacts to indicate that an erasure tool of some kind was used. This may range from commercial tools to freely available VBS scripts.

One important thing to keep in mind when performing forensic analysis is that given some artifacts, we can expect to see other other artifacts. For example, if we find that auditing of logons has been enabled, and we see user profiles with MAC times (on the NTUSER.DAT files, etc.) that indicate logons, then we can expect to see some information in the SAM file, as well as the Security Event Log. By correlating these sources, we can develop information about our case. However, the absence of those artifacts that we know we should see (but don't) is itself an artifact.

I've been doing some thinking about IR and CF artifacts over the past couple of weeks, and wanted to share my thoughts on something that may be of use, particularly if its developed a bit...

When approaching many things in life, particularly a case I'm investigating, I tend to classify things (image the scene in the Matrix where Agent Smith has Morpheus captive, and tells him that he's classified the human species as a virus*) based on information I've received...incident reports, interviews with the client, etc. By classify, I mean categorizing the incident in my mind...web page defacement, intrusion/compromise, inappropriate use, etc. To some extent, I think we all do this...and the outcome of this is that we tend to look for artifacts that support this classification. If I don't find these artifacts, or the artifacts that I do find do not support my initial classification, then I modify my classification.

A by-product of this is that if I've classified a case as, say, an intrusion, I'm not necessarily going to be looking for something else, such as illicit images, particularly if it hasn't been requested by the client. Doing so would consume more time, and when you're working for a client, you need to optimize your time to meet their needs. After all, they're paying for your time.

Now, what got me thinking is that many time in the public lists (and some that require membership) I'll see questions or comments that indicate that the analyst really isn't all that familiar with either the operating system in the image, or the nature of the incident they're investigating, or both. This is also true (perhaps more so) during incident response activities...not understanding the nature of an issue (intrusion, malware infection, DoS attack, etc.) can many times leave the responder either pursuing the wrong things, or suffering from simple paralysis and not knowing where to begin.

So, understanding how we classify things in our minds can lead us to classifying events and incidents, as well as classifying artifacts, and ultimately mapping between the two. This then helps us decide upon the appropriate course of action, during both live response (ie, an active attack) and post-mortem activities.

My question to the community is this...even given the variables involved (OS, file system, etc.), is there any benefit to developing a framework for classification, to include artifacts, to provide (at the very least) a roadmap for investigating cases?

Addendum, 30 Nov: Based on an exchange going on over on FFN, I'm starting to see some thought being put into this, and it's helping me gel (albiet not crystalize, yet) up my thinking, as well. Look at it this way...doctors have a process that they go through to diagnose patients. There are things that occur every time you show up at the doctor's office (height, weight, temperature, blood pressure), and there are those things that the doctor does to diagnose your particular "issue du jour". Decisions are made based on the info the doctor receives from the patient, and courses of action are decided. The doctor will listen to the patient, but also observe the patient's reaction to certain stimuli...because sometimes patients lie, or the doctor may be asking the wrong question.

Continuing with the medical analogy, sometimes it's a doctor that responds, sometimes a nurse or an EMT. Either way, they've all had training, and they all have knowledge of the human body...enough to know what can possibly be wrong and how to react.

Someone suggested that this may not be the right framework to establish...IMHO, at least it's something. Right now we have nothing. Oh, and I get to be Dr. House. ;-)

*It's funny that I should say that...I was interviewed on 15 May 1989 regarding the issue of women at VMI, and I said that they would initially be treated like a virus.