Recent rootkit news

I hope you weren't expecting things to stand still...

This past Monday, F-Secure had an entry in their blog about a custom version of Hacker Defender. In this case, "custom" means "private commercial", meaning that someone paid for a specific version of the rootkit. And don't think for an instant that this is the only one...there are other rootkit authors who do the very same thing.

According to the F-Secure blog entry, the version of the rootkit has anti-detection mechanisms. Specifically, it detects modern rootkit detectors via their binary signature, and if it does find one of the detectors, it can modify itself or the detector. F-Secure says that the most recent version of their BlackLight product can detect this rootkit.

This brings up something I saw over on the Incidents.org blog. Handler Patrick Nolan posted an entry about rootkits that run even in safe mode. Yes, that's right...when you try to boot your computer in safe mode (here's the description of Safe Mode for Windows 2000) so that certain Registry keys aren't parsed, such as autostart locations, the rootkit will still launch. Check out this description from Symantec (btw...take a look at everything that last bit of malware does...).

The Registry key you're interested in is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot

On a side note, Autoruns has been updated to v8.22, and includes new functionality. I've run it on my system, and it doesn't seem to check the SafeBoot key mentioned above. However, when running your cases and parsing the Registry files from an image, be sure to add this one this one to your list of keys to check. Remember, though...on an image, the correct path would be "ControlSet00x", rather than "CurrentControlSet".

Addendum 14 Oct: I caught an interesting item on the Spire Security ViewPoint blog this morning...there's a link to a VNUNet article (ZDNet's version) that mentions three guys in the Netherlands who got busted with a 'botnet army of 100K nodes/zombies. The bots were evidently W32.ToxBot, which Symantec states has "0-49" infections. In all fairness, though, Symantec's definition of "number of infections" is "Measures the number of computers known to be infected". This leads me over to a post on the TaoSecurity blog about digital security, and the differences between the real, "analog" world and the indicators of engineering failures, and those in the digital world. I can't imagine that all 100K of the zombies infected with W32.ToxBot were simply home user systems. It's entirely possible that many of them were academic and corporate systems...and in the case of the corporate systems, someone should have realized that something was going on.

I've dealt with incidents in the past in which admin machines were infected. When I was the security admin at a financial services company, I had a script that would pull down the most recent IIS 4.0 web server logs from a system that we had (and that I'd locked down, in part by removing all but the necessary script mappings) and parse out the other-than-ordinary entries. Over the course of a couple of days, I noticed Nimda scans from the same IP address. So, I did a lookup of the IP space to see who owned it, and in the end, I got lucky. The infected system was owned by the administrator, who was also the technical contact for the domain. I talked to him via the phone...he stated that he didn't realize that he'd had a web server on his system, and didn't know that his system was infected with Nimda (had been for several days), but once he started receiving calls (mine wasn't the first), he really had no idea what do to about it.

Okay...back to our little 'bot. Take a look at the Symantec write-up for the 'bot, in particular these items:

• Installs as a service, and oddly enough, it actually writes a description for the service, as well
• Besides the Registry keys for the service, it adds entries under "Control\SafeBoot\Minimal" and "Control\SafeBoot\Network" so that it is initiated even if the system is booted to Safe Mode
• It looks for the "HKLM\Software\VMware" key, and doesn't run if it finds it (Note: this same technique was used in SotM 32)

Nothing in the write-up indicates the use of rootkit capabilities, but from the capabilities this bot does have...wow. How much harder would it have been for normal admins to detect it if it did have rootkit capabilities (ie, the use of rdriv.sys, for example)?

CA's write up on the ToxBot family

Addendum 21 Oct: VNUNet posted an article 2 days ago, announcing that rootkit creators have gone professional, selling custom versions of their software. While "creators" is plural, there is only one such rootkit announced in the article. This was /.'d, as well. Contrary to what the author of the article would have you believe, this is NOT new.

More on Word Metadata

This past summer, I gave a couple of presentations, one that covered file metadata. I got to thinking...I've parsed Event Log files and Registry files in binary format...why not do the same with Word documents and see what else is in there besides what the MS API is telling me? After all, a particular value that references "hidden" data may be set to 0 (or 0x0000), but the actual data itself may still be there.

Remember the issue with Blair's gov't? When I found this, I tried using the MS API (via OLE) to retrieve the metadata concerning the last 10 authors of the file, and I simply could not get it to work. However, Richard Smith had no trouble doing so.

I started looking around and found the MS Word 97 binary file format (BFF) (here in HTML). I haven't had any trouble parsing the file information block, but what I am having a bit of trouble doing is locating the beginning of the table stream. Many of the values I'm interested in are listed as "offset in the table stream", indicating (to me, anyway) that the offset is from the beginning of the table stream.

If anyone has any information on this, I'd greatly appreciate some help with this.

Also, for testing/verification purposes, I was wondering if anyone out there with a Mac would do me a favor and create a couple of simple Word documents on that platform, zip them up, and send them to me. Some of the metadata within the Word document tells you whether the file was created or revised on a Mac. When you send the files, if you could specify the platform and version numbers (of the os and the application), I'd appreciate it. Thanks!

Perl Programming on Windows

Let's see a show of hands for everyone out there who uses programs Perl on Windows systems. Okay, thank you...please put your hands down. Now, how many of you use Perl to manage Windows systems? Okay, thank you very much.

Now...how many of you want to use Perl to manage your systems?

Whether you're an experienced Perl programmer and not familiar with Windows, or you're a Windows admin and don't know much about Perl, let me the first to tell you...Perl is a very powerful tool that you can learn to use, and use to harness your infrastructure.

Books like Learning Perl and Learning Perl on Win32 Systems will get you started. Even Advanced Perl Programming and Perl for System Administration can help. Dave Roth's books and web site can help. But to really get into the guts of what you can do, you need to (in the words of Nike), just do it.

At it's simplest, Perl can be used to automate tasks. Using Perl, you can create a Scheduled Task that reports certain information and has it waiting and available when the sysadmin comes in in the morning. Throw in a little error checking, and you will have reports on why some things may not have completed successfully...like systems being turned off, services not being available, etc. What would you like to do? Run nmap? Not a problem. Run it against your systems first thing in the morning, or over lunch, and have the output written to a file on your system. Once that's done, use Nmap::Parser to sort through the data and create reports. Great for sysadmins, pen testers, and security analysts running vulnerability assessments.

Perl can be used to implement WMI, and collect information from managed systems. Many of the tools I have available on my web site implement WMI. Using WMI, you can scan remote systems for processes, services, and even perform software inventory scanning from a continent away. Or how about reaching out across the country to locate rogue WAPs via managed Windows XP systems?

Perl is a very powerful tool that can harnessed to automate a wide variety of tasks performed by sysadmins, as well as security analysts. Data collection and parsing, as well as some modicum of analysis, can all be easily automated. Some of the things I use Perl for include:

• Retrieve data from deep within the local system, or from remote systems
• Parse binary files, based on structure documentation, knowing what each DWORD means, etc. (ie, PE header analysis, Event Log and Registry parsing, etc.)
  
• Retrieve metadata from files (ie, Word/Excel docs, JPGs, PDF files, Prefetch files, etc.)
• Querying service information
• Data correlation across multiple sources (ie, Registry, files, etc.)
• Automation of information discovery in ProDiscover IR
  

A side effect of all this is that you end up learning how Windows systems function by themselves, as well as within a domain. If you're automating a task, you end up learning a great deal about the task and the issue that the task addresses, as well.

If this is something you're interested in, drop me a line, post a comment, etc.

Book Report

I haven't blogged in a while, and I came across something worth blogging about. While I don't have the actual numbers in front of me, I've received word from my publisher that my book has only shipped 3500 copies domestically since it was published in July, 2004. From the numbers I received in April of this year, 3055 of those copies were in the first couple of months.

So what does this mean? I have no idea at this point, other than it doesn't seem to be enough justify another book. That's right...given all the material I've produced in the 15 or so months since the first book was published, I've already started putting another book together - an advanced version of the first one, with more technical, detailed information.

The last bit I got from the publisher is that it's up to me to find out what you, the readers, want in another book in order to get the final, published product to move off of the shelves. From what you've told me so far, it just about amounts to incident response war stories, case studies, and maybe even challenges you can work through. All that I can do...but again, it really doesn't sound promising.

I guess I need to start looking around for another avenue for publication. Fortunately, I got one good pointer at lunch today that I need to follow up on...

Addendum 5 Oct: I thought maybe I should give a brief description of what I was looking to provide in the next book. I wasn't planning for my next effort to be a second edition of the first...rather, my thought was to use the first as a stepping stone and launch off into a more advanced effort. I'd like to go more deeply into actual forensic analysis, with the focus being on analysis. Too many times, I've read papers and books that talk about analysis, and for the most part will only go so far as to say "run this tool, and if you see this in the output, something may be amiss..." I'd like to address data correlation and analysis, across the board...use multiple sources of information (i.e., file system, Registry, Event Log, etc.) to build out as complete a view of the issue as possible. I think that the best way to do that is to present the information, and then present examples via live case studies. This book would be interspersed with "war stories", case studies, and examples. I'd also like to include challenges, and exercises for the reader to work. This one would cover both live and post-mortem analysis.

If you've followed this blog, you're familiar with some of what's going to appear in the book...the tools I've released, things I've mentioned here (with more detailed research and analysis) will all be part of the book.

What do you think of something like this? Is this a pipe dream, or is it something you'd like to have on your reference shelf?

Remote Forensics System

I was grabbing some tools from the Foundstone tonight, for a presentation I'm working on, when I ran across something called the "Remote Forensics System". That sounded very interesting, so I Googled it and found a PDF at the Foundstone site that describes the RFS.

I read through the document and found a lot of very good information. In fact, I was envious...to be a grad student again, and have the time to do this kind of work [heavy sigh]. At least part of the system runs on the JRE, and they've incorporated triggers in to the overall system, so that if something pops up on the IDS, for example, data will be automatically retrieved from systems. Cool!

I'll need to read through the document again to get some idea of how the data collected is actually analyzed. However, it does sound like a great idea! My hat's off to Chris Prosise, listed in the Acknowledgements as the advisor.

Imagine my surprise when I found the Forensic Server Project mentioned in section 5 of the document! Wow! Someone actually went by the site and took a look at what I'd done. Unfortunately, the bibliography

System Clock

Recently, a post in a public forum appeared, asking about how to verify the accuracy of the system clock. That got me to thinking...how do you verify the accuracy of the system clock, given nothing more than an image of a Windows system?

I decided to start some of my own research, and to post in other lists to see what others were doing. I received several responses, but most have been along the lines of:

• Completely missing the part about an "image"
• Using email headers
  

Now, these responses aren't bad, because they do point out something very important...that there really isn't any set way to establish the accuracy of the system clock, based solely on the contents of an image. The use of email headers does, however, assume that the intermediate systems that stamp the email have accurate system clocks...something I wouldn't be willing to bet on.

So I set about performing my own experiments to see what happened. First, I ran InControl5 to baseline my system. When the baseline was complete, I double-clicked the time display on the far right of my Task Bar, and that opened the "Date and Time Properties" window, which is essentially the timedate.cpl Control Panel applet. I modified the system time, clicked "OK", then ran the second half of the InControl5 process.

Viewing the results, I ran across a couple of interesting things. First off, the following UserAssist key had been updated.

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}/Count

I ran my "uassist.pl" Perl script to translate the values under this key, and found "timedate.cpl". Unfortunately, this key doesn't maintain its values along with an MRU list, so we don't know which was the last value, and therefore, the LastWrite time of the key is of little value to us.

When I actually opened the Control Panel and double-clicked the "Date and Time" applet, another entry occurred in the above UserAssist key...specifically, "UEME_RUNCPL:"C:\WINDOWS\system32\timedate.cpl",Date and Time".

Since I'm on an XP system, I thought I'd take a look in the Prefetch directory and see if there were any tidbits lurking around. Well, the thought didn't simply occur to me...the output of InControl5 told me that the file named "Rundll32.exe-randomstuff.pf" had been changed in some way. Knowing that rundll32.exe is a legit MS app, and that it's used to run things like Control Panel applets, I opened the .pf file in BinText and found Unicode strings that referenced timedate.cpl and w32time.dll, amongst other things.

All this is fine, in that it gives us clues, but I don't think that it's all that definitive. Another place to look, however, is in the Event Log. Specifically, within the Security Event Log there may be an event ID 520 (Category is "System Event") that states that the system time was changed, and includes the username, previous time, and new time. Very helpful!

Barring that (pretty definitive, isn't it??), there may be discrepancies in the actual times associated with the event records themselves. For example, if an event record with a higher number (more recent event) has a generated or written time that's before a previous event, then you may be on to something.

So far, many of the responses I've seen have said something along the lines of "look at your watch when you're standing in front of the system, before you unplug it and image it"...but, like I said, answers like that sort of miss the point of the question.

So...thoughts?

Projects

Every now and again, I poke my head up for a breath of fresh air and a look around...and I wonder if others face the same issues and challenges I do. For example, knowing where to look during forensic analysis for information relevant to the case at hand.

So, my question to all of you out there is this...what issues do you face? What things do you see, need more information/documentation about? What are the things during a case (or just after you've completed one) that leave you wondering? What are those things that would make great research projects?

Sometimes, those things you are wondering about may already have been solved, addressed, or encountered by someone else.

Please feel free to post a comment here, or email me directly...which ever works. If you email me, I might post your idea, but I won't use your name without your consent.

Addendum 28 Sept: Well, I've received a single email so far in response to this post, and the ideas are (a) case studies, and (b) challenges. I'll see what I can do about posting both, but I'm sure that it would be extremely beneficial to hear from others.

Besides the usual suspects that provide forensic challenges (ie, HoneyNet, DFRWS), there are others available. Try TigerTools (the page has links to three different challenges; Feb, March, and July). I'm sure there are others...

Some way cool visualization stuff

F-Secure has a way cool visualization presentation on the Bagle worm...check it out. Scroll down to the Fri, 23 Sept entry entitled, "A different look at Bagle". Very cool.

I know that there are visualization tools available for social network analysis. Raytheon's SilentRunner (who owns it now??) uses n-gram analysis to build context and create a basis for it's mapping, and is very interesting. I wonder if the above malware visualization will eventually include details of the actual functions themselves...

Creating a timeline analysis tool

I'm not a DBA, and I don't play one on TV. So when it comes to writing a timeline analysis tool, I'm not going to be able to do it myself. But here's what I propose...

I'm most comfortable on Windows platforms, and I know folks that prefer Linux, so that's cool. I know that there are people out there who are familiar with databases, and others that are good graphics programmers. What I'd like to see about doing is opening a project on SourceForge, and see if we can't get a decent start on developing a solution. Here's how I envision it going...and please keep in mind that this isn't the be-all-and-end-all, just my impressions:

• Identify data sources (we've already gotten started with this, but we don't have to be restricted to Windows systems)
• Identify data sets (data source/log normalization, etc.)
• Identify a database format, using mySql (table definitions, etc.)
• Identify and create a graphic component for presenting the data sets

So...here's what I think we need...and please feel free to weigh in here...we'll need someone to take responsibility for the database structure. I think I remember some good install instructions for mySql on Windows - if anyone knows of a resource that's not from the mySql site, please let me know. I do think that the database is pretty important...even if the actual graphic representation of the data never really comes to fruition, at least we'll have a good structure for a single structure to analyze the actual data.

As far as the graphics programming goes, I'm not really sure where to go with that one. Would it be better to go with some of the stuff that's already out there, or create something new with Java or some other cross-platform solution?

So...who's interested? If I get enough interest, I'll go ahead and see about creating a project on SourceForge. Like I said, I can provide various means of extracting the data. For example, most of my Perl scripts that parse raw binary files from Windows can be made cross-platform, and easily modified to dump the information into a database. I can also write the necessary scripts for ProDiscover. Providing solutions to pull data from a source and populate the database is something that will be on-going, I'm sure.

Now, there's no doubt in my mind that this sort of project will take a while...if it were easy, everyone would be doing it. I don't expect it to be done overnight. However, I would like to see it get done, b/c I do think that it would be extremely useful to a lot of people.

So...thoughts?

Addendum: I just did a search on SourceForge for "timeline" and there are several projects listed, but most don't have anything more than a simple page...no project files, nothing. There are some projects with files, but I'm not entirely sure that they'd be suitable.

However, there is something promising...check out the Timeline view of GenealogyJ. My concern would be the volume of data, but it does look like a good start.

Also, my hope is that this will be compartmentalized...meaning that the graphics component won't be database-dependant. That way, there can be several different interfaces for presenting the data, and they can develop over time.

ISC Rootkit Discovery

This post appeared on the Incidents.org (ISC) blog two days ago, and is a very interesting read. The handler, Tom Liston, who works with Ed Skoudis over at IntelGuardians, writes the post in a humorous, Ian Fleming-esque style.

Take a look at the section marked "A view to a kill". Here, Tom mentions a couple of .sys files that seem to be a rootkit. I've run across this before...specifically a file named "rdriv.sys".

Tom's write-up in the final section of the post that describes what actions the malware takes on a system is very interesting, and an excellent read. The one big thing I took away from all this is that the good guys really need to get off their butts and start sharing information like this...tools, techniques, what's been found, etc. This needs to really start happening, because the bad guys are obviously doing it...and doing it much better than the good guys. It's pretty clear that the bad guys are moving away from the old days of "hacking" and writing malware as pranks, and this sort of activity is now driven, at least in part, by economics and financial gain.

Visualization

I've started to see that this issue of "timeline analysis" really isn't one of getting data as much as it is one of visualization. Graphically representing data in some manner for presention it to the audience, can be very powerful. It's been said that a "picture is worth a thousand words", and in many cases, this is true. So, the question becomes, how does one best present a timeline of activity on a system?

For starters, let's simply consider any system. One would hope that any solution would provide for mulitple systems, with the Windows host-based data sources having been covered in previous posts. We could incorporate firewall logs, logs from other systems, syslog, etc., all under the same case heading. There would need to be some sort of normalization process, of course, before the data was incorporated into a database. Along these lines, I'd met with the MountainWave folks many moons ago, in a previous life (...once, in a galaxy far, far away...), before they were purchased by Symantec. Their CyberWolf product was pretty cool, and performed normalization of logs, in a manner similar to what I'm referring to here.

Okay...so once you've populated your database, what next? Ah, yes...queries.

For presenting your data, there are many freeware visualization toolkits available, such as VTK, OpenDX, and GraphViz...but how useful are these...really? Well, GraphViz may have some potential.

One of the commercial tools I've been told is being used is CaseMap from CaseSoft. From what I've been told, though, getting the data into CaseMap can be almost as much of a manual process as Analyst's Notebook. A caveat, though...I haven't worked a great deal with either of these products, so I don't know if the issue of manually entering data is one of operator error or not.

This is all still kind of up in the air...how do you present the data? I think that culling information from a database and presenting a scalable view is still a viable option. The analyst can choose a date and time, and the tool will provide a zoomable view of the data, much in the same way as when you do a search on

Cross-platform scripts

I've heard back from one or two people who've run the lsevt.pl, lsreg.pl, and regp.pl scripts I posted a bit ago. For the most part, I've heard pretty positive comments...things have worked well for most folks. The scripts seem to work just fine so far, regardless of the operating system they're run on...as long as it's running on an x86 processor. Yep, you guessed it...endianness is an issue.

However, one astute user was running the scripts on a G5 (PPC processor) and let me know that if you change the arguments of the unpack() function, the scripts work just fine, regardless of which microprocessor they're run on. The change comes in replacing all of the "S" (short, WORD, 2 bytes) and "L" (long, DWORD, 4 bytes) with "v" and "V", respectively. So, take the regp.pl script for example...in the _getNodeType() subroutine, you'll see:

return unpack("S",$record);

Change that to:

return unpack("v", $record);

In the readNkRecord() subroutine, you'll find:

my (@recs) = unpack("SSL3LLLLLLLLLL4LSS",$record);

Change that to:

my (@recs) = unpack("vvV3VVVVVVVVVV4Vvv",$record);

I won't be making these changes to the scripts myself...at least not right away. However, I am working on another book, so I will include those changes in the scripts before I add them to the CD.

Issues with timeline analysis

I've been doing some searches regarding timeline analysis, delving deeper into this. I still don't think that scatter plots and histograms are the way to report on and present this sort of information...there is just too much information that can and needs to be presented, and too many possible ways that it can be viewed.

In my Googling, I'm finding a good deal of references to "timeline analysis", as well as to the term "reconstruction". A lot of this is being offered as a service. There are also products available that can assist you in your timeline development and analysis, but many seem to be limited strictly to file MAC times. Given the various sources for timeline analysis that are available on a Windows system, relying simply on the file MAC times is not doing anyone any good.

So, I think that we're doing pretty well when considering sources of information, and now the question is, how do we present this information so that it's understandable? Is there an "access view" that looks at last access times of files, where a "modified view" would look at last modification times of files, as well as Registry key LastWrite times? What about things like times maintained in the document properties of OLE docs (ie, Word docs, Excel spreadsheets, etc.)? At what point is there too much information? How does one winnow out the valid, normal, usual stuff to get to the interesting stuff?

There's definitely some room for thought and development here. At this point, my thoughts are that there there'd be some sort of database involved, along with perhaps a Java interface for issuing queries and displaying the information. I haven't written Java GUIs in while, but perhaps a zoomable, scalable depiction of a timeline would be a good start...the investigator could pick a time of interest, and the initial queries would display a view of the timeline of activity, plus and minus a certain amount of time (determined by the investigator). Perhaps an interface into the database that shows which information is available, and lets the investigator select items to add and subtract from the view would be helpful. Add to that color coding of event records from the Event Log, and some other graphical representations of severity of events, and we may have something useful.

I mentioned Java above so that the whole thing would be cross-platform, but I can easily see where HTML or XML would work as well. With a mySql database, and the necessary filters to parse out any sort of information that is available to the investigator and get it into the database, I think we may have a pretty serious tool on our hands.

Thoughts? I know for my own part, I still have a lot of thinking to do, regarding such things as anomoly detection and anti-forensics. However, I think that this may be best handled by discussion within the community.

Addendum 21 Sept: As I think about this more and more, and even go so far as to draw out diagrams on a sheet of paper, trying to conceptualize what a "timeline" should look like, I'm even more convinced that a scatter plot isn't the way to go. Why? Well, a horizontal line (representing a time scale) with a bunch of little dots is meaningless...it has no context. Even if you gave different sources separate icons, and even color-coded them, without more information, it can be useless. Let's say you have a cluster of events around a particular time...Registry key LastWrite times, file last access times, and event records. Well, this could be a boot event. But you don't know that until you dig into things and take a look at the event records from the Event Logs.

Somehow I think that a scatter plot in which each of the dots has some identifying information would be just too much...the graph would be far too busy.

Something that may be of value in this effort is something like fe3d. Yes, I know that it's intended to provide visualization for nmap scans, but I think that something like this, with modifications, would be of value. Take a look at some of the screenshots and try to imagine how to map timeline information to this sort of representation. Of course, there are other freeware visualization tools out there...something else may be easier to use.

I will say this...one of the things that caught my eye with fe3d is the different nodes. Given information dumped into a database, one could include sources from other systems, such as Event Log records from a file server, or data from an IDS, or even firewall logs or syslog data...and have that timeline information represented on a different node, but correlated at the same time scale as the system(s) you're investigating.

Sources for timeline analysis

I just wanted to take a moment and list out some of the sources for timeline analysis on a Windows system:

• MAC file times
• Registry key LastWrite times
• Event Logs
• Other logs (ie, setupapi.log, schedlgU.txt, etc.)
• INFO2 files

Are there any other sources that should be added?

On a side note, does anyone have any credible/supported information regarding which Registry key maintains the audit policy? This may be something that's very important to check.

Timeline analysis

I've blogged about different forms of analysis in the past, and thought I'd take a look at timeline analysis. I had an opportunity to dig around in EnCase v5.0 recently and noticed a nice graphical timeline visualization tool. Very cool. This would have been helpful in a recent situation, had the issue been with filetimes, and not Registry key LastWrite times.

I know that the TimeLine view is not a new feature for EnCase...I simply haven't had to get really deeply involved in using EnCase in a while. However, lsevt.pl and regp.pl. These scripts parse the Windows Event Log and Registry files, respectively. Lsevt.pl contains instructions within the comments for the code for formatting the output in semi-colon-delimited format, suitable for opening in Excel. Let's say we did that, and then sorted everything on the column with the "Time Generated" field from the event records. Then we could do easy (albiet non-graphical) analysis of events that occurred at a certain time.

The regp.pl script doesn't do this specifically, but minor modifications to the file will print out only the key name and LastWrite times, in semi-colon- or comma-delimited format. Again, open the file in Excel, sort on the LastWrite time column, etc.

I think that it would be interesting to have a tool that does all of that, don't you? One that presents a timeline in a spreadsheet or graphical format, but incorporates not only file/directory MAC times, but Registry key LastWrite times, Event Log event record "time generated" times, etc. Being able to trace back to a specific date and time that, say, a file was created on the system, you might see the progression of files installed, Registry keys created, etc., as well as any preceeding events, such a failed login attempts to an Admin-level account, etc.

Addendum 17 Sept: The more I think about it, the more I find that I'm not really sure what I mean when I say "timeline analysis". I received an email from someone that pointed out limitations in Excel (i.e., the number of lines it could handle) and recommending that I look at gnuplot. That's good information, but how useful is it, really? Think about it. A colorful histogram might be nice, but what does it tell me?

When I've had to use timeline analysis of some sort, I've had a date in mind...usually from a complaint or incident report. In some cases, I've noticed "interesting" events that occurred around the same time, such as the LastWrite time on the Registry key for a service called "rdriv.sys". At that point, what I'd like to be able to do is (a) get a snapshot of everything else that occurred around that time...file changes, other Registry keys, events from the Event Log, etc....within a pretty immediate time frame (within seconds), (b) get another snapshot, but with a bit wider scope (hours, maybe less than a day), and (c) "interesting" events that occurred following the initial event.

In my mind, I'm not entirely sure that this is something that is suitable, particularly during the initial phase of the investigation, to be displayed in a candlestick or even a histogram plot. In some cases, I think it would be way too messy. In others, I'm not sure that sorting on groupings of activities or concentrations of events would be necessarily informative, either...you'd see events like reboots.

Don't get me wrong, though...I do think that perhaps something like gnuplot would be useful in the presentation phase of the investigation. During the investigation, a plot of the frequency of certain types of events, such as failed login attempts, network logins, or of the types of queries to appear in IIS logs, would be useful, I think.

With the glut of files on a Windows system, one would need some method for winnowing the wheat from the chaff. Any sort of plot you do based on the last accessed time of a file, looking for the "bad things" will likely be hidden behind the noise of all of the "normal things" that go on on a system.

So...at this point, my thoughts are along these lines...some sort of database will need to be used in order to facilitate searching...I'm thinking mySql. At this point, I'm not entirely sure what kind of table structure would be most useful, but I do have an idea of the data that would need to go into the database. From files, you'd want things like full path, MAC times, hashes, file version information (useful in narrowing down searches to all non-MS files), file signature status (i.e., pass or fail), any alternate data streams, etc. I think I'd want to populate the database with information from Event Logs, and other logs on the system...schedlogu.txt, IIS logs, setupapi.log, etc. Of course, I'd also want to include Registry key LastWrite times, as well.

Once all this information was in the database, I'd start with some sort of default search queries that allow the investigator to target specific dates and look for anything "interesting" within certain windows of time, around the target event. I don't see simply having a dot showing a file change, or a number representing how many files changed, as useful. For me, I'd have to see which files changed, by name and location, as well as Registry keys that may have changed just prior to or immediately following those file changes/additions. I think that used in combination with the file hashes and versioning information, something like this might be very useful to investigators, and help in narrowing down the time it takes to find "interesting" events.

Addendum 19 Sept: I received the following email over the weekend: "I've long desired a consolidated timeline view of "what happened on this box and when". The filesystem MAC times tell a big part of the story, and now with your perl scripts, I can add two more important pieces of events and registry key writes. In a single view, I can see "DCOM service unexpectedly restarted, file backdoor.exe was created, and the CurrentVersion\Run key was last written". That is powerful!"

Combining MAC times with Event Logs, Registry key LastWrite times, and other log resources, along with explanations (ie, what the Event Log entries mean) would be a pretty valuable source of information, wouldn't it?

Not your everyday Perl on Windows

I program Perl. I program Perl on Windows systems. My Perl scripts don't usually do general stuff like file manipulation; ie, open a file containing lines of text, read in the lines, sort/manipulate the lines in some manner.

I've written scripts the implement the Windows Management Interface (WMI), and the Windows Driver Model (WDM).

I've written scripts that open and parse files in binary mode; ie, the Registry and Event Log files, as well as PE headers.

I've written scripts that use the Perl API, or directly access the Windows API, and I've completely bypassed the Windows API all together.

I'm not an expert...I see myself simply as trying really hard. And I find myself wondering if others want to see what I've done...not just the code, but the process I've gone through.

Is this something others are interested in seeing? If so, in what format?

Offline Registry parser on Linux

I thought I'd post this, as I found it pretty interesting...

I got some feedback from someone who'd used the offline Registry parsing script...he told me that it worked well for him. What was interesting to me was that he was running the script in Perl v5.8.4, on Debian Stable, with kernel 2.6.5 for the i686 architecture.

He pulled down the script, and copied some Registry files over from a Windows VMWare session, and things worked fine.

Wow. That's great feedback! And positive, too.

Rewriting the MS API

I've released lsevt.pl, a Perl script that I developed to parse through raw Event Log files. As I mentioned in my GMU2005 presentation on the subject of Event Log files, I had one instance in which parsing through an Event Log file manually revealed a "hidden" event record, one not seen by the MS API.

I released my initial script earlier, but it was proof-of-concept, and I received requests to complete the script and return all available information from the event records. So I added parsing of the event source, computername, message strings, data, etc.

To run the script, simply pass in the path to the Event Log file that you're interested in, and redirect the output to a file:

C:\Perl>perl lsevt.pl c:\windows\system32\config\sysevent.evt > sys.log

An example of the output that the script generates is:

Record Number : 10876
Source : Service Control Manager
Computer Name : ENDER
Event ID : 7036
Event Type : EVENTLOG_INFORMATION_TYPE
Event Category: 0
Time Generated: Tue Aug 2 02:12:25 2005
Time Written : Tue Aug 2 02:12:25 2005
Message Str : iPod Service stopped

Record Number : 10877
Source : EventLog
Computer Name : ENDER
Event ID : 6006
Event Type : EVENTLOG_INFORMATION_TYPE
Event Category: 0
Time Generated: Tue Aug 2 02:12:31 2005
Time Written : Tue Aug 2 02:12:31 2005
Message Data : ff 00 00 00

I've included directions in the script itself for those who prefer the output in a semi-colon delimited format, suitable for opening in Excel.

As always, I hope someone finds this useful.

Memory dumps revisited

A while back, I blogged on Memory Collection and Analysis. Since then, the results of the DRFWS Memory Challenge have been posted, and the results look promising. I haven't had a chance to work with either of the tools, as they don't seem to be available, but they do look interesting.

John H. Sawyer has commented in his blog. One of his more interesting comments, with regards to the MS Debugging Tools, is, "The tools weren't intuitive, I'm not a programmer and you have to have the machine preconfigured to make the dump that the debugging tools can read. LAME!" I think that his sentiment sums up the issue quite nicely...most of the folks using the MS Debugging Tools likely aren't programmers, haven't had the opportunity to work with and learn how to use the tools, and simply haven't configured their systems to use the MS tools...which, like any tool, has it's own inherent strengths and weaknesses.

It does look as if this issue is taking a step in the right direction...we'll see how useful this sort of thing is as long as the tools remain private.

Updated Registry parsing tool

Well, this isn't so much an update as it is a modification. I've released lsreg.pl, a Perl script that allows the administrator/investigator to search raw Registry files (ie, NTUSER.DAT, system32\config\SYSTEM, system32\config\SOFTWARE) for specific keys and values.

The Perl script takes two arguments...the path to the raw Registry file, and the path to the file containing the keys/values you're looking for. An example of the output is:

Key -> CurrentControlSet\Control\Windows\ShutdownTime
LastWrite : Tue Aug 2 12:06:56 2005
Value : ShutdownTime;REG_BINARY;c4 96 a0 ad 5a 97 c5 01

Key -> Select
LastWrite : Wed Feb 23 09:37:25 2000
Value :Current;REG_DWORD;1
Value :Default;REG_DWORD;1
Value :Failed;REG_DWORD;0
Value :LastKnownGood;REG_DWORD;2

Key -> Setup
LastWrite : Tue Apr 29 21:33:53 2003
Value :SetupType;REG_DWORD;0
Value :SystemSetupInProgress;REG_DWORD;0
Value :CmdLine;REG_MULTI_SZ;setup -newsetup -mini
Value :SystemPrefix;REG_BINARY;d2 03 00 00 00 00 39 80
Value :SystemPartition;REG_SZ;\Device\HarddiskVolume1
Value :OsLoaderPath;REG_SZ;\
Value :CloneTag;REG_MULTI_SZ;Wed Feb 23 01:44:25 2000

The script uses no MS APIs (so basically, I rewrote the API), but instead parses the Registry files in binary mode. Notice that the output includes the LastWrite time of the keys. If a key is being searched for, the script returns all of the values in that key, if there are any. If a value is being searched for, the script returns the value and data, if found.

As always, comments and questions are welcome.

The Windows Registry as a Forensic Resource

The subject article is now online at ScienceDirect. I wrote this article back in July. In the article, I walk through some of the basics of the Registry and its structure, and then get into where the investigator can look in the Registry for certain information that may help with a case.

Besides addressing autostart locations, the article also discusses Registry entries that pertain to USB removable storage devices and the key/values that contain information on wireless SSIDs that the system has connected to.

Comments are welcome and appreciated.

Updated offline Registry parsing script

I've updated the offline Registry parsing script...it's here. The updates include:

• Cleaner, more modular code
• Better documentation of the code
• Better handling of binary data types
• Translation (i.e., "decrypting" Rot-13 encoding) of UserAssist Registry key value names

The zipped archive also contains a JPEG image of a PPT slide I put together to shed some light on how the raw Registry files are architected. There's no explanation or description with the image, so if you have some questions or comments, feel free to drop me a line.

To run the script, simply use a command-line similar to this:

C:\Perl>perl regp.pl [path to Reg file] > regp.log

For example, I have a couple of raw Registry files in C:\reg, so my command line looks like:

C:\Perl>perl regp.pl C:\reg\software > regp.log

As with the earlier version, this file is also easily compiled into a stand-alone executable for Windows systems.

Be forewarned...this script will take a while when being run against the "Software" file...the one that holds the HKLM\Software hive. This is due in part to the fact that the Classes key is HUGE!

The next step for me with this project is to complete a script that will allow the investigator to search for arbitrary Registry keys and values. It's been challenging so far, but I've got a pretty good handle on it, so hopefully I'll be able to post something soon.

A couple of final notes...
1. Testing has been limited, as I have only a limited number of VMWare images to pull test files from.

2. This script is intended for raw Registry files (ie, system32\config\software, system32\config\system, ntuser.dat) from NT/2K/XP/2K3 systems.

3. I haven't tested this script on Linux systems, because I don't have regular, unimpeded access to such systems. I am trying to get some things tested on a Mac, but that's someone elses machine.

4. If things don't work as expected, please feel free to let me know. When you do that, though, please give me as much info as you can. I received on email from someone who said that things "looked wonky"...I have no idea what that is. Can you send me the output file, and maybe post the file you ran the script against somewhere (i.e., on a web or FTP site??)? That would be helpful in troubleshooting.

Thanks!

USB device descriptors and serial numbers

Whenever I've talked about USB storage devices and their serial numbers, someone always seems to ask me, "If I have an image of a thumb drive, can I find the serial number somewhere in the image?"

My answer to this question has been, "Why not go back and take a look at the image with a hex editor...or at least, say, the first megabyte of the image, and tell me if you find the serial number listed?" After all, you can see if a USB device has a serial number (and if so, what it is) using tools like UVCView. Well, so far, I haven't received any email from someone who's done this, so I started taking a look into this myself.

The answer to the question is simply, "No." The reason for this answer is that the device descriptor is usually stored in EPROM, Flash, or some form of ROM, and is not read when the device is imaged using tools like 'dd'. Generally speaking, you wouldn't want to allow the device descriptor to be modified, as a user could alter some of the data, causing an incorrect driver to be loaded, and the device could potentially then be unusable.

Therefore, I'd like to make a suggestion to law enforcement (and everyone else) when it comes to imaging USB storage devices. Make sure that you have a tool like UVCView (or whatever is suitable or available for your platform) on hand as part of your imaging kit, and copy the device descriptor from the device as part of the imaging process.

One of the elements of the device descriptor is the vendor ID, which is assigned by the fine folks at USB.org. This information can be used in a manner similar to the first couple of octets of a MAC address; ie, to identify the vendor of the product.

Upcoming Speaking Engagement

I received word this weekend that I will be presenting at the DoD Cyber Crime Conference 2006 in Palm Harbor, FL, in Jan 2006. I will be presenting a case study, a walk-through of an investigation that takes place on a Windows system. I will be basically tying a couple of my previous presentations (i.e., "The Windows Registry as a Forensics Resource", "Tracking USB Storage Devices on Windows Systems", etc.) together with some "practical" application.

The agenda for the 2005 conference looks pretty interesting, with a good deal of emphasis on LEO-type information (i.e., courses/presentations on ILook, law, etc.)

It seems that Richard Bejtlich will be there, as well. I look forward to meeting him, and listening to his presentations.

NTFS ADSs, again

I was browsing over on CPAN today, as I do a couple of times a week, to see if there were any new and interesting Perl modules available. I found one called Win32::StreamNames, and decided to take a look. This module, by Clive Darke, takes a filename as an argument and lists any ADS stream names associated with it. I don't see the StreamNames module on the list of Windows packages at ActiveState, but hopefully, it won't be long until it appears.

I haven't installed this module yet, but I will try to do so once (if??) it appears on the ActiveState site. It looks as if it might be useful for automatically parsing and categorizing ADSs, and flagging what's bad, and what Windows just does normally.

Offline Regisry Parser

I've posted the current iteration of the code I wrote for an offline Registry parser here.

The code is written in Perl, and uses only one module...and that's just to handle time/date translation. I've got some documentation in the code, and I know that I need to clean it up a bit...but take a look.

Here's what the code does...let's say that you've got an imaged Windows boxen, and you want to take a look at the Registry to get certain values out. Well, the script will dump the contents of the NTUSER.DAT file, or the SOFTWARE or SYSTEM files.

To run the script, use a command line like:

C:\Perl>perl reg.pl [path_to_file] > output.log

The script parses the Registry file in binary mode, and prints out the keys with LastWrite times (in GMT format), as well as values, the data type of the value, and the data associated with the value.

This script isn't the most efficient way of parsing the Registry, but it works. You can search/grep through the output file to find the information you're looking for.

I developed the script on Windows, but my goal is to make it cross-platform. Also, I'm going to use the subroutines in the script as building blocks for scripts that search for specific keys and values, based on user input.

When does size really matter?

Well, when you're talking about Registry values, that's for sure!

On 24 Aug, Secunia released an advisory about how overly-long Registry value names were not being displayed in the Registry Editor. The advisory basically says that Registry values names that are "overly-long" will not be displayed in the Registry Editor, and that this "problem reportedly also exists for overly long registry keys."

So...what's the issue? Well, a great deal of malware maintains persistence on a system by creating a reference to itself in an autostart location, meaning that by making a reference to itself in one of these locations, it will automatically be started when the system starts, when a user logs in, or when the user takes some action. No direct interaction is required from the user to launch the application. Most folks doing incident response and forensics on Windows systems know to check these locations for indications, but now, it seems that some tools are not capable of displaying the value names if the name is longer than 254 bytes/characters.

The Internet Storm Center has a couple of diary entries about this, and are working to not only create a list of tools that do and do not display/react to these long names, but also to get vendors to update their products appropriately. Tom Liston, one of the ISC watchstanders, created a tool that will search your Registry for long value names.

I've written a Perl script that will parse offline Registry files...I'll need to add a check for value names that are longer than 254 bytes.

Quoted

I was quoted in Tony Bradley's article in "Processor". The article talks about involving IT in the planning of the infrastructure, to include the physical facilities. One of the things I've seen over time is that some companies hire cut-rate admins and IT staff because in the short term, it's less expensive. After all, it makes good business sense to save money in the short term, right? Why hire someone (or a couple of someone's) for $65K a year, when you can get them for $40K? Well, that may be all well and good if you're trying to beef up an already experienced staff, but not good if you're trying to create a staff.

Something the article really doesn't go into is the development of IT staff...that's something that needs to be addressed in a lot of organizations. Some places will go out of their way to incentivize the marketing and/or sales dept, or HR, or other areas, but sometimes the IT staff is largely overlooked. Apathy in your IT staff can be a pretty big security risk.

Morpheus Searches

Many times, law enforcement will have a need for information concerning specific applications. In some cases, those specific applications are P2P file sharing clients. Recently on another list, someone asked about Morpheus, and I thought I'd take a look. After all, you never know when you're going to have that same question yourself.

I got a copy of the P2P client application and installed it. I opened and then minimized the application. I ran the first half of the "two-phase mode" for InControl5. I ran a couple of searches in the client, then completed the "two-phase mode" for InControl5, and took a look at the report. As I suspected, the search terms were not kept in a file, but were instead maintained in the Registry, in the following key:

[HKCU|HKEY_USERS]\Software\Morpheus\GUI\SearchRecent

The LastWrite time on this key will tell the investigator when the key was last written to, ie, when the last search term was added to the list.

I'm sure that more comprehensive testing could be done; in fact, it might be of benefit to compile information about several P2P clients, such as where search terms are maintained, etc.

Anyone out there need or have this info? What are the specific P2P/file sharing clients that you're running across, and what information are you looking for about them?

Event Log Analysis and Reporting

I've long thought about what kinds of things can be derived from a normal, default Event Log, mostly based on my needs at the time. What I was looking for usually depended upon what my job function happened to be at the time. In some cases I might be looking for a particular user's logon time, and in others, I was looking for reports from A/V software.

Now, I'm looking at Event Logs from the perspective of...I don't really know what I'm looking for, or what might be useful. For example, I can cull through a System Event Log and look for instances of event ID 6005 followed by an instance of event ID 6009, which indicate when the system was started. Depending upon the audit configuration of the system, other information can be derived as well.

So...what kinds of things are other looking at, or looking for, in the Event Logs? What types of things should be correlated?

GMU2005 in review

Well, GMU2005 is over with...I'm looking forward to GMU2006, or whatever they'll end up calling it.

First off, shoutz out to the staff, volunteers, sponsors and attendees who made GMU2005 possible. It was fairly well put together, though not without its hiccups...but that's too be expected.

I ended up giving a total 4 different presentations, but was on the podium 6 times. Usually, after 4 hrs of presenting, I wasn't really in the mood to attend any of the training or other presentations. Funny how having to keep the balls in the air for four hours straight can sort of take it out of you. Some presentations ended up being cancelled, either due to good reason, or b/c the speaker wasn't able to make it. I did want to attend Terry Gudaitis's presentation on cybercrime profiling, but she presented at the same time I did, albiet in a different room. However, she was nice enough to send me a copy of her presentation, which I found very interesting.

During and after my presentations, I got a lot of great questions...questions are always good. I could see from the questions that a lot of folks were interested in actually using what I was talking about, especially with regards to my USB storage device presentation. After lunch on Thursday, one of the attendees told me that he'd received an email from the HTCIA listserv, asking how to determine if an iPod had been connected to the system. So, this guy broke out my presentation and sent the original poster the answer! Very, very cool! And Cory, if you're reading this...thanks for putting me on the spot with this guy - I did end up giving him a free copy of my book.

Speaking of giving away free copies of my book...if the publisher doesn't have a bookstore at the conference, I usually get in touch with them and ask them to provide me with free copies of the book to give away at the end of my presentation. I usually give one away to someone who can answer a trivia question. For the first presentation on Tues, I gave a copy of my book to the guy who brought a video cable to the room so I could plug my laptop into the projection system (that was one of the hiccups).

A couple of notes/comments for attendees of conferences like this...most presenters work pretty hard in order to not only put a presentation together, but to also make it pertinent and useful to the audience. Sometimes, this can be tough...the content of the presentation depends upon the make-up of the conference attendees. If you think that the presenter did a good job, tell him or her that. If you've got comments about what the presenter could have done to make the presentation a little better, let them know. Keep in mind that there are some things that a presenter can control, and other things they can't...such as providing desks to write on and paper copies of the slides ahead of time, etc. This sort of thing really helps, as it lets the presenter know how they did, and maybe even what they can do next time that might improve the presentation.

A question I get a lot (and I mean A LOT) when I give presentations is, "...what happens if you...?". This is the case, whether I'm talking about NTFS alternate data streams, USB connected storage devices, or embedding/merging OLE documents. I've developed a stock answer for these questions..."why don't you try it and tell us." I don't do this to be mean or rude...I just think that a lot of times, the questions aren't reasoned through before they're asked. Now, don't get me wrong, I love questions...they get me thinking and if I can give a presentation and walk away having learned something, I'm happy. But, members of the audience, please keep this in mind...I'm not rich, and I do have a life. Yes, there are a lot of things out there that maybe I didn't cover in my research or presentation...but that's usually because I didn't have the time (I have a life, or had a deadline) and/or because I'm not rich and can't afford to purchase one or two of every type of USB device available on the market. I'm sure that in the course of a case, you're going to come across a specific piece of equipment that I didn't specifically cover in my presentation, but that's why I try to lay out the process I used to get the information that I did...so you can follow that process.

So...I just wanted to say that in case anyone attending my presentations thought that I was being rude when I responded the way I did to that particular question.

Anyway, as a wrap-up for this entry, I heard other attendees say that some of the presentations were good, others weren't so good, but overall they were pretty happy with the conference as a whole. Next year should have a much larger attendence, so if you're interested in attending or presenting, keep your eye on the RCFG website.

Linux vs Windows TCO

There's an interesting article by Lauro DiDio over on NewsFactor about the Linux vs. Windows Total Cost of Ownership (TCO) argument. The article has some really interesting comments (for the popular media, that is), specifically, that there is no one-size-fits-all, silver bullet solution.

Wow. This harkens back to the "which is more secure" argument...I think the best response to that one is that the operating system is irrelevant in the face of poor administration.

Something that really jumped out at me from the article was the following: "If you do not know what is on your network...then you cannot truly evaluate whether Linux, Windows or Unix is right for your business."

How true is that? I've seen it with large as well as small networks...folks just have no idea what's out there. The same holds true with incident response...

Industry_Insider article

An article I wrote appeared in the MS Industry Insider blog recently. The article is about two misconceptions I see in the IT world when it comes to incident response, specifically on Windows systems...that the best thing to do if you think that a Windows system has been compromised or infected is to wipe it and re-install from clean media, and that bootable Linux distributions are the best tools to use for Windows incident response.

My comments on these misconceptions are supported by the recent NIST document SP 800-86: Guide to Computer and Network Data Analysis: Applying Forensic Techniques to Incident Response. I found the link to this paper over on Keith Jones' blog.

So...take a look, I'd appreciate any comments you may have, particularly regarding the article.

GMU2005 presentations updated!

Well, the first day of GMU2005 went off without a hitch. Sunday evening I updated my presentations...nothing major, just a bullet here, a link there. I've also added some of the Perl scripts mentioned in my presentations...after posting the presentations, some folks reviewing them began asking me for the scripts. I didn't provide them because, well, in the past, no one seemed interested.

To get the new archive, just click here.

There was a glitch with presenters this morning, so I pulled out an already-approved presentation and gave that one to fill the time (and yes, that one's included in the archive as well..."The Windows Registry as a Forensics Resource").

Everything went pretty smoothly, and I got some interesting comments, both during and after the presentations. Some folks would come up and say, "great job!", while others would say something along the lines of, "I'm working on a case where I could really use this information."

To all who attended my presentations today...thanks!

Tomorrow and Thursday, I'll be presenting two presentations each day...one on file metadata, and another on USB-connect storage devices. After each presentation, I'll ask a question, and whomever answers it correctly gets a free copy of my book!

GMU2005 presentations posted!!

I finally received approval for public release of my presentations for GMU2005...which starts Monday. ;-) Ugh...don't even...

There are three PPTs in the archive...one on the Windows Event Log file format, one on tracking USB storage devices across Windows systems, and one on file/document metadata. Take a look, and if you have any questions or comments, please feel free to post them here, or email me...

FRUC INI files

If you're currently using the FSPC/FRUC tools, what would you think about posting your INI files for others to see?

An explanation of the FSPC and the FRUC

Okay, so I posted my updates of the FRUC yesterday, and I'm glad I got that out of the way. But I probably need to give an explanation of the FRUC, and talk about why I wrote it in the first place.

When performing incident response activities, it's generally considered a GOOD THING to get the data you're collecting off of the victim system. In some cases, writing files to the hard drive of the victim system may overwrite important data that's in slack space, but just getting the data off of the system so that it can be analyzed quickly is important. You may simply want to determine quickly whether you have a real incident or not.

Well, on way of doing this is to write the files to the drive, archive them using a zipping utility, and then FTP/TFTP the archive to a waiting server. Hhhhmmm...lots of steps, creates files on the drive...okay, that may work sometimes, but what else have you got?

Another option is to use netcat to get the data off of the system. The way it works is this...you open netcat as a listener on your forensic server and head on over to the victim system. Once there, you run the commands you would use to gather data...command line tools that will display their output at the console, or STDOUT...and rather than viewing the output of the commands on the screen in front of you, you "pipe" the output through netcat, sending the data to the waiting server. For the sake of brevity, the specifics of this are covered in my book, as well as in online resources like this one from Keith Jones.

Okay, so what we've got here is a way to get data off of the system. When you're all done, it ends up on your forensic server in one big file, which you have to parse apart before you analyze it. Also, you've had to maintain a notebook detailing everything you've done...commands you ran, when you ran them, etc. Just typing in all those commands can be pretty tedious, even if you have them written down...right? Say that you have multiple boxes you're looking at...what then? You've got to retype all of those commands...and maintain the notebook.

There must be an easier way...and there is!

Let's start with the server component first...the FSPC. This is the component that sits on your forensic server, waiting for connections. The FSPC basically handles data management...when a connection is received, the FSPC puts the files that it's sent into a directory, and keeps a timestamped log of everything that goes on. When data is sent to the FSPC, it generates a hash for the file that it creates. If a file is copied to the FSPC, it will verify the hashes of the file when it writes it to the hard drive.

The FRUC is the "First Responder Utility (Commandline)"...this means that there's no GUI, no buttons to push. The FRUC runs from a preconfigured .ini file, or via arguments entered at the commandline. Basically, the investigator or first responder copies the FRUC files (.exe files, supporting DLL, .ini file) and any third-party utilities that the FRUC will run to some media...a CD, a USB-connected thumb drive, etc. Once done, she carries it with her, or deploys it for someone else to use. Once the media is inserted into the machine, a single command is run, and all of the data that the investigator wants to collect is sent to the forensic server for storage.

Pretty simple, eh? Powerful tools, automated (to minimize mistakes and reduce the amount of time necessary to collect data), and minimal interaction required by the user.

The framework seems to be pretty complete for data collection at this point. As I've said before, data collection is easy...and from looking at the FSP, I hope you see that, too. It's the data analysis that's tough. One way to deploy this is to have multiple .ini files on the media. The user will insert the media and run the first .ini file, which collects certain data...say, process and network connection information, etc. On the server side, the investigator can run quick analysis tools/scripts, and determine whether a more detailed look is necessary. For larger investigations involving multiple machines, the investigator can open multiple FSPC listeners on the server, each on a different port, and instruct first responders to run the FRUC with the necessary commandline switch to change the port used in the .ini file.

There are other toolkits for pulling information from Windows systems, most notably IRCRv2 and WFT. However, I prefer the FSP framework...not just because I wrote it, but because I think that by removing some of the interaction that the first responder will have with the tools, it's easier to deploy and use, particularly in larger environments.

Also, while the FSPC and FRUC are deployed as executables, their Perl source is also provided (ie, the tools are compiled into executables using Perl2Exe). This makes the tools very extensible...using the Perl source, you can easily make your own modifications to the code, and extend the tools for your own use, in your own environment.

FRUC Updated!!

Finally!

I finally completed my development and testing of an updated version of the First Responder Utility (Commandline), the data collection portion of the Forensic Server Project.

A bit ago, one of the FSP users pointed out two things...first, that the commands listed in the INI file weren't run in order (he had included "date /t" and "time /t" at the beginning and the end of the list of commands...), and that there were some issues with commands that would hang.

So, I wanted to get this blog entry out...I'll be writing more about the use of the FSP and the FRUC as time goes on, but I wanted to let you know that the new version is out.

A web site in an alternate data stream

A new blog by Inge Henriksen of Norway was pointed out to me today, and the posts so far are very interesting. One of the posts describes how to create an entire web site within NTFS Alternate Data Streams (ADSs).

An interesting thing about ADSs is that if you have a file with an ADS associated with it on a file share, and you drag-n-drop that file to another NTFS partition, the ADS will remain with the file. However, if you download files via HTTP or FTP, the ADSs are not persistent. But that's not what Inge is doing...the web server is simply serving up a file, and that's all that an ADS really is anyway...a file.

Remember, while Windows has native tools for creating ADSs, there are no tools native to the Windows distributions that allow you to view the existance of arbitrary ADSs.

If you're not familiar with ADSs, take a look at this article that I wrote on the subject...or read about ADSs in chapter 3 of my book.

USB blocking software

I ran across this NetworkWorld article on USB blocking software products, by Ellen Messmer, this morning. There's not a whole lot of interest in the article, from my perspective...it basically says that McAfee and Sygate are adding the functionality to their products.

What did catch my attention is the first sentence: Unauthorized use of USB hardware to gain access to information in laptops and servers is a growing concern.

Really? A growing concern for whom? What about all of those systems out there that haven't had the software installed on them yet, and may possibly have already been used in this unauthorized manner?

Well, if you're a regular reader of this blog, you already know how to go into systems and check to see if any USB removable storage devices have been connected to the system.

Hashing code updates

Jesse Kornblum has updated md5deep, so head on over and pick up your copy. The tools include hashing programs for MD5, SHA-1, SHA-256, Tiger, and Whirlpool. Very, very cool. Jesse is THE MAN when it comes to these hashing programs, and he even goes so far as to provide a Windows binary of the tools.

MSRC Strider HoneyMonkey Project

I ran across the MS Security Response Center's (MSRC blog) Strider HoneyMonkey project this morning...very interesting stuff. From the web site:

The Strider HoneyMonkey Exploit Detection System, as the research project is code-named, was created to help detect attacks that use Web servers to exploit unpatched browser vulnerabilities and install malware on the PCs of unsuspecting users. Such attacks have become one of the most vexing issues confronting Internet security experts.

Sounds like it's kind of a client-based honeypot, with the system automating the actions of a user to have the browser go out and visit suspect web sites. This would be done by automating IE, and analyzing the system after it was infected. Wanna see how easy it is to automate IE? Check out Dave Roth's Perl on Win32 web site. Go to the Scripts archive and check out his IEEvents.pl script. This shows you how to use the Win32::OLE module to automate IE (which is a COM server) and have it do things for you.

And yet, like the GhostBuster thingy, this won't be a product that's released for use by anyone outside of MS.

Addendum [9 Aug]: It seems that others have (had??) picked up on the ol' honeymonkey. Rob Lemos has a SecurityFocus article on the honeymonkey, which points to a paper that MS just released this month. The paper even mentions that the honeymonkey detected a zero-day exploit, specifically the javaprxy.dll vulnerability (1, 2) that was known, but did not have an available patch. At the time it was detected (ie, early July 2005) it was not known whether it was being publicly exploited or not.

Analysis of a Win2K rootkit

I ran across this site recently (can't remember where I originally got the link) and finally got around to actually reading through it.

The first thing that jumps out at me is that the content is incorrectly titled. When talking about rootkits, particularly on Windows systems, the term most generally refers to tools that are used to hide the attacker's presence from not only the Administrator, but the operating system and native tools, as well. However, I suppose that since the attacker "had root", used two self-extracting archives (kits) to move his tools over, and "hide" from casual viewing by (a) using the attrib command, and (b) deleting some files, then technically, it is a "root kit".

Like I've said before, I really like to see things like this posted...seriously. I've heard from others that not only are such things interesting to read, but they provide a great learning opportunity, and I wholeheartedly agree.

I do have a couple of suggestions for improvement, and a question. First, the question...the author makes reference to the HKU\{SID}\Software\Microsoft\Internet Explorer\Explorer Bars\{GUID}\FilesNamedMRU key, and seems to indicate that this location can be used as an autostart location (ie, "...thus executing all of the files listed if any one of them is started.").

Does anyone have any insight on this? I'm going to try this out and see what happens, but I'd love to know how close he is on this.

Okay...suggestions...constructive stuff. I like the screen captures, but there's a lot going on in the article that would really benefit from a screen capture or two. For example, ...used an MSBlaster style exploit to open port 4444 with root privileges... Okay...but can we see that? For example, how about showing the output of fport/openports side-by-side with the output of handle.exe, showing the user context of the process? That would be cool.

Throughout the article, the author speculates as to the intentions of the attacker. I don't necessarily disagree with his assessment of the skill level of the attacker (though I'd like to see more detailed information), but I think that sometimes we can misguide ourselves when we try to guess someone's intentions.

Finally, there are some confusing statements in the article. For example,

1. The svc.bat file sets the user name of the IRC bot in win.dll (which is actually just a plain text file)...
2. ...but instead sets the machine up as a warez server via IRC. The bot installed connects to irc.efnet.com and joins the channel #XiSO...
3. Edit the C:\WINNT\system32\Setup\svchost\x.pid file to find the process id (PID) of the IRC daemon
4. This stops the IRC daemon from running
5. ...suggest the intended use for this kit is not just to run an IRC bot...

So, is it a 'bot or a daemon? Client or server? It sounds like it's a 'bot/client, based on the explanation, but the use of the term 'daemon' suggests a server or service. This is an important distinction.

The author says, "This results in 3 processes called lsass.exe, though only one is legitimate." This demonstrates a "hiding" technique that still works. Basically, the attacker started several processes named "lsass.exe", but because the executable images weren't in the system32 directory, there were no issues with WFP. Even though you won't see the full path to the executable images in the Task Manager, just having more than one copy of lsass.exe running should be a tip to even the most casual observer. Now, using 'svchost.exe' is another matter entirely...

Overall, a great job. Shout-outs/greetz to the author.

MS Office 2003 Redaction tool

I got an email this morning about a tool released by MS called the "Office 2003 Redaction Tool". This tool is an Office 2003 add-in that allows you to redact documents.

Now, many of us are aware of issues with redaction, as well as with metadata in Office documents in general. In the past, folks have posted "redacted" PDF documents to the web, only to have someone with a slow download speed find out that the redaction was...well...not a good as expected. Talk about low-tech! Some of the earliest issues I'm aware of involved someone downloading a PDF document, and then being surprised when, through a slow link, serveral words were suddenly replaced with black blocks! Hey! In a nutshell, it simply took a few more seconds for the redaction blocks to crawl through the link and make their appearance on the page. At that point, all the reader had to do was remove the blocks.

So, I downloaded and installed the redaction tool, and opened up a small document I have on my desktop. I redacted two unique words in the document, and saved the resulting document. I then opened the resulting document in a hex editor and found that in hex, the redacted words had been replaced by "7C". Wow.

This is simply an initial test. There's lots more to do. For example, it appears that the redaction tool also looks in the document properties (ie, metadata) for the same redacted words...I say "appears" because I don't know for sure yet.

Something else to consider is this...let's say that you have a Word document, and in the interests of national security, you need to redact the phrase "small happy dog". Now, let's then assume that you have the phrase "I'm really happy about my job" in the comments (metadata) for the document.

Process monitoring and malware analysis

As part of looking into ways of improving malware analysis, I got to thinking about some things. For instance, some malware may maintain encrypted strings (ie, passwords or URLs) which it then decrypts in memory, and deletes once the string has been used. Some data used by the malware process may be transient in memory. So what do you do?

Well, I had a thought...what if you could run a process for a specified period of time, dump the contents of memory (and maybe run some other tools), then resume the process for a short period of time? Using Perl, we can do this! Here's the code:


#! c:\perl\bin\perl.exe
# strap.pl
# use to launch an application (malware) and then at predefined
# intervals, suspend() the process, perform some actions (ie, dump
# contents of memory, run external programs like listdlls.exe, etc.)
# then resume the application
use strict;
use Win32::Process;

So, we're using the Win32::Process module. Now, let's set up our variables. For testing purposes, I used AIM...

my $proc;
my $app = "c:\\program files\\aim\\aim.exe";
my $args = "";
my $dir = ".";
my $exit_code;

Now, let's go ahead and create our process...

if (Win32::Process::Create($proc,$app,$args,0,NORMAL_PRIORITY_CLASS,$dir)) {
print "Process created.\n";
# Get PID
my $pid = $proc->GetProcessID();
print "Process $pid created.\n";

Now that we've created our process, let's let it run for a bit (in this case, 3 seconds), then suspend the process. What we're doing, for testing purposes is running this loop only 10 times. This can be expanded (and the Wait() time changed, as well), or an entirely different loop structure can be used.

foreach (1..10) {
$proc->Wait(3000);
$proc->Suspend();
print "Process suspended.\n";

Now that the process has been suspended, we can go ahead and do things like dump process memory (with pmdump.exe), or run tools like handle.exe, listdlls.exe, etc.

sleep(3);

Once we're done, go ahead and resume the process...

$proc->Resume();
print "Process resumed.\n";
}
}

Now, just a little error checking...

else {
print "Process creation failed: ".Win32::FormatMessage Win32::GetLastError()."\n";
exit(1);
}

So, once this script has completed, you can conduct your analysis. For memory dumps, run strings.exe against the files, or use scripts to extract email or IP addresses, etc.

Addedum: In responding to some comments this morning, I thought that something I said should be included in the text of the post itself.

What I've presented above is not meant to replace anything. Rather, it's a tool...nothing more. Like any tool, it's effectiveness depends upon how you use it. One possible scenario for the use of this tool would be where an administrator or analyst has an unknown bit of software (we won't call it malware yet b/c we don't know). When looking at the program with a hex editor (part of performing static analysis), the analyst may believe that the program is encrypted or obfuscated in some manner. Now, most admins/analysts don't have tools like IDAPro at their disposal, and don't have the necessary skill sets to use things like debuggers and disassemblers. So, moving on to dynamic analysis, they want to run the program on a "sacrificial lamb" system to see what it does. Loading up monitoring tools, the analyst may want to run the application in a more controlled fashion, dumping memory contents along the way.

The above script will let you do that. Admittedly, the script itself is raw, and in it's early stages...but the basic idea is there. The great thing about scripts like this is that they can be easily expanded. For example, let's say we replace sleep(3) the necessary command to run pmdump.exe. When the above script ends, you'll have a directory with a bunch of memory dump files. Well, at that point, the script can then:

1. Hash each of the files (using Jesse's tools)
2. Run strings.exe against each file
3. Grep() through each file looking for email or IP addresses, keywords, etc.
4. Run 'diff' between all of the files to see what changed between snapshots
5. Save the results to a flat file, a spreadsheet, or a database for analysis

To me, it's all kinda cool! Something like this would have been kind of interesting when I was using netcat to demonstrate Locard's Exchange Principle.

iPod info

I was doing my monthly check of the e-Evidence.info site this morning, and I ran across an interesting article on how iPods are used as hard drives. So I plugged an iPod into my Windows box and fired up UVCView, and pulled the serial number from the device...in this case, "0000008A0136".

From there, I went to the Registry and navigated to the HKLM\System\CurrentControlSet\Enum Registry key, then dropped down and opened up the USBStor subkey. There, I found the device ID I was looking for...Disk&Ven_Apple&Prod_iPod&Rev_1.62. Beneath this subkey, I found the instance ID that contained the serial number of the device; "0000008A0136&0". From there, I mapped the ParentIdPrefix value to the corresponding value under HKLM\System\MountedDevices and located the drive letter that the device had been mapped to; in my case, \DosDevices\G:.

So what does this all mean? If you're looking around for who's been using iPods at work, you know which key to check. If you're performing a forensic investigation, you should check under the ControlSet00x key, rather than the CurrentControlSet key.

Training Poll

A while ago, I posted about a training course based on my book. Since then, I've received emails from folks, asking about when such a course would be available near them, so I thought I'd post here and see what folks are interested in...

When I taught my Windows 2000 Incident Response course, I would generally go on-site and teach approximately 20 folks at a time, for two days. In some cases, attendees would ask me to come on-site to their location, and provide specialized content, based on the needs of their particular group. This sort of set-up (ie, having me come on-site) worked out really well for the folks who took advantage of it, because they saved a ton of money. Having me come on-site for two days to teach a dozen (most cases were closer to 20) folks the material was less expensive than sending 3 people off to other training courses (that shall remain nameless). Also, they didn't have to deal with processing travel claims for all those folks...and the material that I presented could be...and was...used immediately.

However, this kind of set up does not work for everyone. Not everyone can provide 8, 10, or more folks at one time, in one location, for two days. Some folks would be happier going off-site for three or four days. And still others would be happier doing it all online.

So, here're my questions to you, dear reader...

1. Would you be interested in a training course (2-3 days), based on my book? The material would be technical, with a lot of hands-on work, includes labs/exercises.

2. If you would be interested in such a course, what information, specifically, would you be interested in? My data hiding presentation has always been popular, but my "Windows Registry as a forensic resource" can be a bit out of reach for some folks. What type of content would you like to see, specifically? Would you be more incident response oriented?

3. What type of setting/forum would you like to see? Would you prefer to have me come on-site, or would you like to go somewhere off-site? If you're more interested in an web-based approach, can you point me toward some services?

Thanks. Feel free to post a comment (please sign it) or email me...