Bejtlich on IR, Forensics

Richard Bejtlich, of TaoSecurity fame, recently blogged about an article he'd written for CSO Magazine, entitled Computer Incident Detection, Response, and Forensics: the Basics. It's a very interesting article, and supports a great deal of what I've seen from various sources over the past year, as well as some of my own practical experience as an incident responder.

The biggest thing I picked up on is that here is Richard talking about how "pulling the plug" is not necessarily the immediate-action-of-choice these days...this is very true. For example, a system gets compromised and network logs indicate that there is a significant amount of traffic leaving that system (albeit the fact that the network logs do not contain content...). The first thing that most IT admins tend to do is take the system off-line (off the network), and in some cases even shut down or simply reboot the system. Then the big, $64,000 question that needs to be answered...for the CIO or for an external regulatory body...is, what was going out? Was it some sort of homing beacon, or was it actual data (ie, sensitive data, as defined by CA's SB1386 or AB1298)?

In pulling the plug, other questions are also difficult to answer...was this system as stepping stone to other systems, or was itself attacked from another system? If so, what/where are those systems? Ooops...no more network connection information...now I have query every system in the infrastructure, and because I shut this system down, I don't have a recognizable footprint to look for. =(

Had the first responders had the right tools and training available, they could have captured necessary data prior to taking those immediate actions.

One aspect of the article I don't agree with is the statement that prevention eventually fails. Ever since I was in the military, I had a problem with folks saying that something was failure when it was never proper implemented in the first place. While it's true that defenders have to protect all avenues of ingress and an attacker only needs to find one way in, incident analysts have seen enough intrusion incidents over the past couple of years to know that a great many infrastructures (small and large) have enough poorly configured systems (not rogue or unknown...all of these systems are known, and quite simply not properly configured) as to not have much in the way of defenses. I do agree that detection needs to be properly implemented alongside prevention, but I'd like to see prevention properly implemented before we simply rule it a failure.

Overall, the article is a very good read...and like many articles that make predictions that this is the Year of Whatever, we'll have to wait and see.

Event Log Analysis

In keeping with the Getting Started posts, I wanted to include something that may be of interest with regards to finding corroborating artifacts when performing computer forensic analysis.

Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".

This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs against an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.

Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.

Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:

EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)

Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious

Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean

CIO article on the need for forensics

CIO Magazine out of the UK has an interesting article titled In-depth Investigation that discusses the need for computer forensics capabilities. While it is from across the pond, the message of the article is extremely applicable here in the US, as wel.

I know that as I agree with it, many folks are going to think, "well, yeah, you're a consultant...of course you agree with this article, because it recommends that companies hire you!" And yes, that's true...I am a consultant, and in most cases a company would have to hire someone like me to come in and do the kind of work that is recommended.

However, even taking e-discovery out of the equation for a moment, with the increase in state notification laws (goin' federal in the near future...), as well as the regulatory stuff (SEC, PCI Council, FISMA, HIPAA, etc.), a forensics capability is being mandated. The decision has been left to organizations, and they've opted not to develop the capability...and now many organizations are being told that they have to have it.

My personal thought on this is that ideally what an organization would want to do is develop an in-house capability for tier 1 response...trained folks whose job it is to respond to, triage, and diagnose a technical IT incident. By "trained", I mean in the basics, such as NSM, incident response, troubleshooting, etc...enough to be able to triage and accurately diagnose level 1 and 2 incidents, as well as preserve data until outside professionals can respond to level 3 or 4 incidents.

That leads to one other thought...many times when folks like me recommend that an outside third-party be called to perform incident response and/or computer forensic activities, it's not so much because we want your money (well, that IS part of it...), but look at it this way...if your organization is mandated (by the PCI Council, for example) to have a pen test performed, how well do you think they're going to accept the results when your report says that your own IT employees performed the pen test against the systems they set up, and they found no way to get in? Having an outside third party do this kind of thing adds credibility to the report...besides, this is what we do all the time. ;-)

Artifact Repositories

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?

Forensic Analysis

Often (well, often enough) we run into instances where it becomes evident that someone has an unrealistic expectation of what answers forensic analysis can provide.

I know that right now, most of you are thinking, "dude...no way!" But I say, truly, it is so. There's even a term for it...it's called the CSI Effect. There are even articles written about it (here, and here).

Let's look at an example of what I mean. Our hero, the forensic analyst and incident responder Dude Diligence gets a call from a company, and the caller says that they've been "hacked" ("hacked" is the new "smurfed", by the way...a verb with many nuances and flavors...). Dude gets on site to find that even before he was called, a considerable amount of remediation was going on...systems were being accessed and "cleaned" (another one of those verbs with many nuances and flavors...) by administrators, with no real focus as to who was doing what, when, or why?

I'm sure that by now, some of you who are consultants like our hero are now weeping into your beers, sobbing, "dude..." under your breath...but our story continues.

Dude does the best he can to get the story of what happened, and what systems were affected. In the end, he acquires images of about half a dozen systems and returned to the Dude Lab to do analysis. Before leaving, however, he made sure that he had a solid understanding of what questions needed to be answered for the customer...specifically, was this a targeted attack, and was sensitive data (could be credit card numbers, could be PII, PHI, etc.) compromised.

To make a long story short, ultimately what Dude finds is that...he can't find anything. Systems had not been configured for any sort of viable logging (the system, as well as applications), and what logs that were there had been removed from the system. Systems had been scanned with AV applications, etc., etc. Traces of the intruder's activity (if there was one) had been completely obliterated by the actions of those who "responded" to the incident. Even if Dude had determined that sensitive information was, in fact, on the system, he isn't able to provide a definitive response to the question of, does that information now, as a result of the intrusion/compromise, exist somewhere it shouldn't? Was it exposed?

Even under the best of circumstances, there are just some questions that forensic analysis cannot answer. One question that comes up time and time again, particularly in some of the online forensic forums, is, from an imaged system, can you tell what files were copied off of the system? Dude has found artifacts of files being uploaded to web-based email systems such as GMail, and found other artifacts, but what computer forensic artifacts are there if someone opens a Word or PDF document on their screen and copies information out of it onto a piece of paper, using a pen? How about if someone connects a removable storage device to the system and copies the files off onto to that device? Sure, there are artifacts of the device being connected to the system (particularly on Windows systems), but without actually imaging and analyzing that removable storage device, how would Dude determine what files were copied from the system to the device?

I've talked about alternative analysis techniques before, and the solutions I'm looking toward include, for example, how you may be able to show names of files that someone viewed, and possibly the dates, even if the user deleted and overwrote the files themselves, or viewed them from removable media, etc. There are lots of ways to get additional information through analysis of the Registry, Event Logs, and even of the contents of RAM captured from the system...but there are just some questions that computer forensics can not answer.

That being said, how does our hero Dude Diligence go about his dude-ly analysis? Well, to begin with, Dude is part-sysadmin. This means that he understands, or knows that he needs to understand, the interrelation between the different components of a system...be that the interrelation between the external router, firewall, and the compromised system within the network infrastructure, or the interrelation between the network, the apparently compromised host (i.e., the operating system), and the applications running on the host.

When it comes to analyzing intrusions, Dude doesn't have to be a pen-tester or "ethical hacker"...although it may help. Instead, Dude needs to shift his focus a bit and not so much concentrate on breaking into or compromising a system, but instead concentrate "around" it...what artifacts are left, and where, by various actions, such as binding a reverse shell to the system through the buffer overflow of an application or service? For example, when someone logs into a system (over the network via NetBIOS or ssh or some other application, or at the console), where would Dude expect to see artifacts? What does it mean to Dude if the artifacts are there? What if they're not there?

Remember Harlan's Corollary to Jesse's First Law of Computer Forensics?

This leads us back to the first statement in this post...there are some actions for which the artifacts are not available to forensic analysts like Dude when he's performing a post-mortem analysis, and there are some questions that simply cannot be answered by that analysis. There are some questions that can be answered, if Dude pursues the appropriate areas in his analysis...

Copying Files

I've been party to or heard a good number of discussions lately regarding USB removable storage devices, and one of the topics that invariably comes up is, how can you determine which files were copied from the system to a thumb drive, or vice versa.

In most instances, folks are working only with the image of a system, and do not have access to the thumb drive itself. They can easily find the information that tells them when a thumb drive was first connected, and when it was last connected...and then the next question is, what files were or may have been copied to the thumb drive (or from the thumb drive to the system)?

The fact is that Windows systems do not maintain a record of file copies or moves...there is simply no way for a forensic analyst to look at the image of a system and say which files were copied off of the system onto a thumb drive. In order to determine this, you'd need to have the thumb drive (or other media) itself, and be able to see that you had two files of the same or similar size (you can also compare the files with md5deep or ssdeep), one of which is on each piece of media. From there, you could then check the file MAC times and possibly make some conclusions regarding the direction of transfer.

Many times in a conversation on this topic, someone will bring up Windows shortcuts or LNK files. To be honest, I'm not really sure why this comes up, it just seems to be the case. Shortcuts can be created manually, of course, but with regards to files, they are created when a user double-clicks a file, such as a Word document, to open it. Repeated testing on my part (including testing done by others) has yet to turn a method by which normal (as in "normal user activity") dragging-and-dropping a file or using the "copy" command will result in a Windows shortcut file being created.

Does anyone out there have any thoughts or input on tracking this kind of activity, having nothing more than a single system image to analyze? If so, I'd appreciate hearing from you.

Forensic Laws

I mentioned a concept or idea in my book, but I wanted to follow up on it a bit...I believe to be a theorem. Okay, maybe not a theorem (there's no math involved), so how about a law. Let's call it the First Law of Computer Forensics. Yeah, yeah...that's the ticket! Kind of like "Murphy's Law".

With that being said...here goes:

There is evidence of every action.

Just to be above board on this, credit (or blame, you decide) goes to Jesse Kornblum. One thing to keep in mind about this law is that the evidence is there...it simply may not exist on the media that you're currently examining. For example, one question that I've seen in the lists is, how do you tell from an acquired image of a system if files were copied from it to, say, a thumb drive? Well, you may find the existence of the file on the system, and you will find that the thumb drive was plugged into the system (to see how to determine this on Windows systems, grab a copy of my book), but how do you determine if the file was copied to the thumb drive, if all you have is the image of the system? The fact is...you can't. You need the thumb drive. Even though the evidence you're looking for isn't on the image, it is on the thumb drive.

Now, here's Harlan's Corollary to the First Law of Computer Forensics:

Once you understand what actions or conditions create or modify an artifact, then the absence of that artifact is itself an artifact.

What this is saying is that not only is there evidence of every action, but the lack of that evidence is itself evidence.

Thoughts?

Addendum, 13 May: I wanted to point out that the example I gave of the laptop and the thumb drive is just that...an example. If you're starting to think that I'm making an absolute, definitive statement about the existence of an artifact on the thumb drive, please re-read the statement, and think of it only as an example. Thanks.

Forensic Challenges

Whenever something new comes out, one of the things people in particular fields ask is, how will this affect us and what we do? This is especially true in our field. With the recent release of new technologies, not the least of which is Vista, lots of folks have been asking about the challenges to digital forensics these new technologies will pose.

Thinking about this, I would suggest that the challenges don't come from "new" technologies being introduced, but rather from our community's myopic point of view.

I know what you're thinking...what did he just say? Well, I'm suggesting that new technologies...increased storage capacities, increased sophistication in cybercrime, new operating systems, etc...aren't imposing the "challenges" we think they are...we are. As a community, we're limiting ourselves, and imposing these challenges on ourselves somewhat artificially.

Rather than trying to describe my reasoning, let's look at a couple of examples. First, increased storage capacity...newer, smaller hard drives with greater capacity make things like iPods and cell phones that do everything for you possible. However, this is something that the forensic community has been dealing with for some time. This is not a 'new' challenge at all. The same holds true with new technologies, like Vista. New operating systems have been coming out all the time...at one time, Windows NT 4.0 was "new" (heck, even I remember that!).

What about drive encryption? Is this particularly a "new" challenge? Encryption has been around for a while, and we have to deal with encrypted files all the time. With freeware encryption for files, and even commercial products, it's not unusual to have to deal with such things. Those of us that haven't had to deal with such things specifically need to keep some knowledge of what to do, an "SOP", if you will, in mind in case we do encounter these things.

IMHO, the real challenges to the digital forensic community are largely self-imposed. New technology doesn't necessarily impose new challenges on the community, as the introduction of "new" technologies is almost a steady-state in this industry, isn't it? DOS led to Windows 3.1 and OS/2, which led to Windows 95 and NT 3.51/4.0, etc., etc. Storage capacity has increased over time. New devices have been introduced. There's really no "challenge" in this, per se...simply wait until someone produces a product to deal with the "new" technology, and things continue as before.

It appears that the real challenge is incorporating new ways of doing things, such as live response. Now, we won't always have the opportunity to employ live response, as not all of us have the benefit of talking to the "victim" prior to them taking some action on the affected system(s), but live response is one of those things that flies in the face of the traditional (dare I say "purist") approach to computer/digital forensics. However, live response can do a great deal to help us solve some of the other perceived challenges, if we can change the mindsets of the major players in the community. From there, this mindset change will permeate the minds of others...corporate IT, lawyers, etc.

What challenges do you see?

Why I like Perl for Forensic Analysis

Many times when I post to a list or give a presentation and talk about using Perl, I almost immediately hear comments back such as, "I can't do that because I don't know Perl".

Well, I have to say, it's not about knowing Perl, or how to program, really. Most of the stuff I'm doing with Perl is translating binary stuff into something readable (timestamps, checking flag values), and just doing repetitive stuff. For example, in Windows Memory Analysis, I just use Perl to implement various processes that are repetitive and boring, and therefore I would be prone to making mistakes. The same is true with tools like SAMParse and SECParse that I use to parse the contents of raw Registry files. The information is there for anyone to see, extract, and interpret. I simply use Perl to do it automatically. In some cases, I write the scripts I do because there is commercial application that provides anywhere close to the information I want or need.

I have written tools to parse RAM dumps, parse Event Log .evt files (without using the Windows API), parse raw Registry files, etc. I wrote these tools because I needed them, and as it was very likely that I would need to do those things again, I automated the process in a Perl script.

I also hear things like, "I don't want to have to keep Perl up-to-date". I think in a lot of cases, comments like these come from folks who don't know a great deal about Perl...and you know...that's fine. It's okay, people. I'm not being a Perl snob or forensics snob or whatever snob, I simply use Perl to automate the repetitive tasks that make up my work day. Besides, I also use Perl2Exe, so all the tools that will be provided on the DVD that comes with my next book (Windows Forensic Analysis, from Syngress/Elsevier) will be provided with Perl "source" code, as well as a standalone EXE file that will allow you to run the tools on a Windows system without having to install Perl.

Perl is an interpretted language, so I don't have to "compile" my scripts to run them, and I can easily make modifications and changes to the scripts, updating or correcting them quickly. The scripts are somewhat self-documenting, although I do add my own comments to give myself a better view of what's going on, so I can figure out was I was doing a year or two later, rather than just look at it and think, "*I* wrote this??". Finally, Perl gives me a freedom and flexibility that is not available in commercial tools. For example, there are commercial tools that will allow you to view certain Registry data in a nice GUI, but you can only view that data, and only one entry at a time. With Perl, I can output multiple entries, as well as correlate data from multiple keys, such as when I want to show USB removable storage devices, any drive letters they were mapped to, and the last time each device was connected to the system (I should call this one "USBParse"). Don't like ASCII output in block format? In a few moments, I can have CSV style output. Ta-da!

So...some folks don't like to use Perl or open-source tools for forensic analysis, and that's okay. I use Perl because I know that if I have to perform some kind of analysis or correlation once, I'll probably have to do it again, and in order to avoid (as much as possible) forgetting a step or making a mistake, I'll automate the process.

Besides, I give most of this stuff away for free, as in beer.

Intentional erasure

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.

Scripts for parsing the Registry

I was working on a script recently to expand the reach of the Registry Analysis material in my upcoming book, and I thought it would be a good idea to implement something that would parse the audit policy from a system. So I wrote poladt.pl, a Perl script that uses the Parse::Win32Registry module to extract the necessary value from the raw Security file and parse it, displaying the audit policy as shown below:

G:\perl>poladt.pl d:\cases\security
LastWrite: Fri Sep 9 01:11:43 2005 (UTC)
Auditing was enabled.
There are 9 audit categories.

Privilege Use..............None
Object Access..............None
Account Logon Events.......Both
System Events..............Both
Policy Change..............Both
Logon Events...............Both
Account Management.........Both
Directory Service Access...None
Process Tracking...........None

Note: I added the little dots so that the output would line up better and be easier to read; formatting in the blog is a little beyond my current skillset.

Pretty neat, eh? You can compare this to the contents of the Event Logs (I still use the File::ReadEvt module that I wrote to do this, as the Event Viewer still reports the files as corrupted sometimes when you extract them from an image and try to import them into the Event Viewer on your analysis system). If I get any information about other values to parse out of the raw Security file, I'll add that to a script and call it "SECParse".

This script is will be found in the Bonus section of the DVD that comes with my book. Look for Windows Forensic Analysis from Syngress later this spring.

Artifact classes

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.

Trends in Digital Forensics, and news

I ran across a Dr. Dobbs article of the same name as the title of this post...very interesting. The subtitle is Are "live" investigations are the trend we are heading towards?

An interesting quote from the article:
Thus the new trend in digital forensics is to to use the corporate network to immediately respond to incidents.

Hhhhmmm...this sounds pretty definitive.

My thoughts on the article are two-fold. First, I have to ask...is this, in fact, the trend (or at least a coming trend that we're seeing more of)? Are IT and IR teams using tools like those mentioned in the article (Encase, Wetstone's LiveWire - I have to wonder why the author doesn't mention ProDiscover) to perform incident response via the network? If so, how effective are these efforts?

Overall, the author discusses "live investigations" (which is cool, because my next book covers that, in part) but I have to wonder how much this is being done, and how effective it is.

Now for the "news"...there's a new CyberSpeak podcast out, I just downloaded it and still have to listen to it. I took a look at the show notes (which have moved) and saw that Jesse Kornblum is again being interviewed. Very cool. One of the news items I picked up from the show notes was about a guy in the UK who took over young girls' computers and extorted them into sending him dirty pictures of themselves. The scary thing about the article isn't things like this:

...used some of the most advanced computer programmes seen by police to hack into their PCs...

One of the youngsters said his level of expertise and his power over her PC reminded her of the cult science fiction film Matrix.

Well, okay...I take it back...maybe those excerpts do represent some scary things about the article..."scary" in the sense that an email-borne Trojan of some kind is equated to level of technology seen in the Matrix. Or maybe it's the fact that according to the article, these kids actually fell prey to this guy and sent the pictures, rather than notifying their parents.

Okay, I'm off to listen to the show...

Forensics Blogs/Podcasts

Does anyone know of any other purely forensics blogs and/or podcasts out there? I know that there're several neat, not-specifically-forensics sites, but I'm looking for just forensics; hardware or software, Windows, Mac, Linux, Atari, Commodore...anything specifically related to computer forensics.

Restore Point Forensics

I was doing some digging around the other day, researching System Restore points in XP...they're only in XP (and ME, but we're only concerned with the NT-style Windows OSs), and not something you'll find in 2000 or 2003.

So, what is "System Restore"? SR is a function of XP that creates "restore points" or limited backups of certain important files, depending upon certain triggers. For example, by default, a restore point will be created every calendar day. Also, restore points are created whenever the user installs software. This, of course, means that you could technically have multiple restore points created during a single day. Restore points can be used in case something goes wrong with the installation and the system is affected...the user can select a previous restore point, and "roll back" the system to that point. This is a very cool thing, and I've used it more than once myself. Keep in mind, though, restore points do not affect certain things, such as login passwords or a user's data, so don't be afraid to select a restore point from 3 days ago because you think you might loose that spreadsheet you built yesterday.

So what do restore points mean to us? Well, they're full of a wealth of information about the system. I've presented on the topic of "the Registry as a logfile" in the past, and this is a great example of that. Important files are backed up, but so are portions of the Registry, such as the System and Software files, the user's profile(s), and portions of the SAM. These Registry files have keys in them, and the keys have LastWrite times.

Where do these come into play? I've seen several questions in some of the lists lately, asking about things like "was this user account on the system", or "did the user change their name", as well as other questions where, on the face, would best be answered if there were some way to take a glimpse into the past. Restore points let you do that.

The structure of the restore points is pretty simple. On the root of the system drive, you'll find a "System Volume Information" directory, and beneath that a directory named "_restore{GUID}". Beneath that, you'll have numbered restore points...RP35, RP36, RP37, etc. You get the idea. Within each of these "RP**" directories, you'll have some backed up files (depends on the nature of the restore point), and a file called 'rp.log'. This is a binary file that contains the description string (null terminated string starting at offset 0x10) for the restore point, as well as the FILETIME object of when it was created (QWORD starting at offset 0x210). Finally, there is a snapshot directory holding all of the Registry file backups.

If you're interested in peering into these restore points, but don't have an image available, you can look at them on your own XP system. One way to get some information is through WMI. Using the SystemRestore and SystemRestoreConfig objects, you can get information about each restore point, as well as configuration settings about the System Restore, respectively. I wrote a Perl script to do this...here's an excerpt of what I got on my system:

64 13:28:07 09/27/2006 Installed Windows Live Messenger
65 15:07:48 09/28/2006 System Checkpoint
.
.
.
73 12:45:41 10/09/2006 System Checkpoint
74 14:03:53 10/09/2006 Installed QuickTime
75 19:25:09 10/09/2006 Installed Microsoft .NET Framework 1.1
76 20:21:54 10/10/2006 System Checkpoint
77 20:52:59 10/11/2006 System Checkpoint
78 22:00:48 10/12/2006 System Checkpoint
79 22:20:18 10/12/2006 Installed Windows Media Player 11
80 22:20:41 10/12/2006 Installed Windows XP Wudf01000.
81 10:45:08 10/14/2006 Software Distribution Service 2.0
82 12:35:54 10/18/2006 System Checkpoint
83 18:29:09 10/19/2006 System Checkpoint
84 20:38:49 10/19/2006 Removed ProDiscover IR 4.8a
85 20:43:48 10/19/2006 Installed ProDiscover IR 4.84

Kind of cool. This gives me something of a view of the activity of the system, not only when it was online, but also what was going on. Notice that on 19 Oct, three restore points were created. Not only was the normal System Checkpoint created, but there was a software removal and an installation. This script is very useful, not only for incident response (include it with the FRU and FSP), but also for general system administration. It works remotely as well as locally, and gives the admin some good visibility into the system.

The other interesting thing about this is the order of the restore points. Notice that as the restore point indexes increase, so do the timestamps. If I were to have modified my system time several days ago, things might not appear to be in order...so this is a good little sanity check to see if maybe the system time was modified. It's not definitive, mind you, but a good check.

If you just want to take a look around, go to SysInternals and get a copy of psexec. Once it's on your system, type:

psexec -s cmd

and a command prompt will open, but you'll have SYSTEM level privileges. Then type:

cd \Sys*
cd _restor*

Now, select one of the restore points and cd to that directory, then to the snapshot directory. If you do a 'dir' at this point, you'll see all of the various Registry files that are backed up, each one beginning with "_REGISTRY_MACHINE_*". At this point, you can copy any of these files out to a "normal" directory, and either open the file in a hex editor, or run it through the Offline Registry Parser and see the contents in ASCII. I tried this and dumped out one of the SAM files I found, and saw that I could see the C values that hold group membership information, as well as the F and V values for user's account information. One of the things I've got in the works is a set of scripts that will parse through these files (and the "normal" Registry files), reporting on what it finds...but in a way that's readable to an investigator. So, rather than spewing out binary data for the F and V values for a user account, translate that into something readable, like my UserDump ProScript. Something like this could be used to 'diff' the various files from restore points.

I've developed a ProDiscover ProScript for sorting through the restore points on an XP system, and I'll make it available when the next version is released.

Additional Resources:
Steve Bunting's site (he uses EnCase)
Bobbie Harder's site (links to KB articles)
Windows XP System Restore
Wang's Blog (tells you how to open the RP** Registry files in RegEdit)
Restore Point Log Format