I was reading a list entry recently, looking at some of the functionality that was being added to a popular forensic analysis application, and I got to thinking...what areas of what we do (incident response and computer forensic analysis) are in need of innovation? What could we do better, through process or whatever, to do what we do better...more efficiently, more accurately, more completely?
What about adding functionality to forensic analysis applications? In the instance I was looking at, the request that had been granted was to add parsing of ASCII-based logs to the application. Is this really necessary? Is this something that needs to be added to applications that are still unstable, crash without notice or without any sort of debugging information, and currently contain far too much "functionality" so as to require a certification just to use the application (forget doing actual forensic analysis).
I'm not picking on any one application either. There's another one that I like a lot, and updates have been delayed while functionality is being added to it...functionality that is available in other tools.
What I'd like to see is a core, stable application capable of opening image files, and allowing the analyst to quickly and accurately perform keyword and grep() searches, for file content, file names, etc. From that point on, major functionality (such as parsing PST files) could be easily added as plugins, allowing the core application to remain stable.
I'm also a firm believer that too much functionality in a forensic analysis application moves that analyst further and further away from understanding the data itself. As analysts are removed from the data, their understanding of what's expected and what's unusual or suspicious lessens. One person can't be expected to know everything, but that's why we have a "community", right? Having analysts that understand how various pieces of data interact to build a more complete picture is extremely important, particularly as the sophistication of cybercrime continues to rise.
What are some areas that you feel need a little innovation? How about just shook up enough to flake off the shell of "...but that's how we've always done it"?
The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics", as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Pages
▼
Saturday, May 31, 2008
Monday, May 26, 2008
RegRipper Update
I wanted to let folks know that I've posted the latest version of RegRipper to SF.net. The file you're looking for is "rr_2.02.zip".
There is no longer a break between the Basic and Advanced editions of RegRipper...I've done away with the Basic edition all together, and posted what used to be the Advanced version. The download package includes everything you need...the executables, source, RTFM docs (PDF, FAQ) and even a couple of simple batch files that show you how to use rip.exe to perform/automate some real simple tasks.
Development of RegRipper will continue. I still need to add more documentation to each plugin, along with Analysis Tips (explain why/how the data collected displayed may be important, etc.), as well as add the separate consolidation of timeline information (for use in analysis and graphing).
The power of RegRipper is in the plugins, and I can only go so far developing plugins myself. If you find that there's a plugin that you'd like to see, let me know. Please keep in mind...sample data is far more helpful than a description.
As always, if you have any thoughts, questions, comments, etc., please feel free to drop me a line.
There is no longer a break between the Basic and Advanced editions of RegRipper...I've done away with the Basic edition all together, and posted what used to be the Advanced version. The download package includes everything you need...the executables, source, RTFM docs (PDF, FAQ) and even a couple of simple batch files that show you how to use rip.exe to perform/automate some real simple tasks.
Development of RegRipper will continue. I still need to add more documentation to each plugin, along with Analysis Tips (explain why/how the data collected displayed may be important, etc.), as well as add the separate consolidation of timeline information (for use in analysis and graphing).
The power of RegRipper is in the plugins, and I can only go so far developing plugins myself. If you find that there's a plugin that you'd like to see, let me know. Please keep in mind...sample data is far more helpful than a description.
As always, if you have any thoughts, questions, comments, etc., please feel free to drop me a line.
Sunday, May 25, 2008
More Free Tools
To continue adding to the list of free tools (earlier posts here and here), here are a couple of gems I found recently...
NetworkMiner - a free network forensic analysis tool that takes analysis of network traffic captures to another level. Very cool tool...I love how WireShark lets you reassemble streams, but NetworkMiner lets you do a bit more, and it's Windows-based. Don't have any packet captures available to try it with? Check out the HoneyNet Project's SotM #27.
Thanks goes to Claus for pointing these out...
Stinger and MVC...these are NOT full-bore AV applications, but rather free tools meant to target specific malware. Use these on a live system, or mount the acquired image as a live file system (as opposed to booting the image...) and scan the files.
OpenFilesView - Neat little tool to see which files are open on a system; GUI based but comes with command line options, making it a great tool for use in IR batch files. Say you've got a suspected intrusion and you need to know if sensitive data (pursuant to PCI, HIPAA, etc.) is being siphoned off of the system...well, grab process information w/ tools like tlist.exe and correlate that information to files opened on the system by process...
MUICacheView - The NirSoft site says, "Each time that you start using a new application, Windows operating system automatically extract the application name from the version resource of the exe file, and stores it for using it later, in Registry key known as the 'MuiCache'." This is one of those things I've looked into, and I'm not able to find what the OS would use this for...but hey, who am I to complain about it, right?
By the way, RegRipper has a plugin for this key, which means that you can parse the contents of this key by either extracting the hive from an image, or by firing up F-Response. ;-)
Addendum: Claus posted some of his own bloggy goodness about Evidence Collector, and from that post I learned about USBHistory, a nice little tool that extracts historical information about USB devices connected to a live system. The author even gives a shout out to ol' watashe-wa and his book! Very cool!
NetworkMiner - a free network forensic analysis tool that takes analysis of network traffic captures to another level. Very cool tool...I love how WireShark lets you reassemble streams, but NetworkMiner lets you do a bit more, and it's Windows-based. Don't have any packet captures available to try it with? Check out the HoneyNet Project's SotM #27.
Thanks goes to Claus for pointing these out...
Stinger and MVC...these are NOT full-bore AV applications, but rather free tools meant to target specific malware. Use these on a live system, or mount the acquired image as a live file system (as opposed to booting the image...) and scan the files.
OpenFilesView - Neat little tool to see which files are open on a system; GUI based but comes with command line options, making it a great tool for use in IR batch files. Say you've got a suspected intrusion and you need to know if sensitive data (pursuant to PCI, HIPAA, etc.) is being siphoned off of the system...well, grab process information w/ tools like tlist.exe and correlate that information to files opened on the system by process...
MUICacheView - The NirSoft site says, "Each time that you start using a new application, Windows operating system automatically extract the application name from the version resource of the exe file, and stores it for using it later, in Registry key known as the 'MuiCache'." This is one of those things I've looked into, and I'm not able to find what the OS would use this for...but hey, who am I to complain about it, right?
By the way, RegRipper has a plugin for this key, which means that you can parse the contents of this key by either extracting the hive from an image, or by firing up F-Response. ;-)
Addendum: Claus posted some of his own bloggy goodness about Evidence Collector, and from that post I learned about USBHistory, a nice little tool that extracts historical information about USB devices connected to a live system. The author even gives a shout out to ol' watashe-wa and his book! Very cool!
Wednesday, May 21, 2008
F-Response - Extend Your Arsenal
I recently played with F-Response Enterprise Edition, and I have to tell you, this stuff rocks! Excuse me...R0x0rz! Imagine as an incident responder if you could have read-only access to a remote disk...completely independent of your toolset? This means that once you get F-Response up and running, you have a disk on your system, which is the physical disk of the remote system...but it's read-only. Wanna grab files? Do it. Wanna image the drive? Do it.
Just so you know, you'll need to get the MS iSCSI Software Initiator as well.
So once I got everything set up (Matt's documentation is pretty straight forward) and running, all I had to do was run the installed service on the remote system...in this case, a Windows XP VMWare session. Once that was done, I had a nice little indicator that the remote system was connected to. Very good. Then I looked and saw that I had an icon for an F:\ drive now attached to my system. I could browse it, copy files, do whatever...it was all read-only. No changes (file modifications, adding files, etc.) appeared on the remote system drive.
So then I thought I'd replicate what Hogfly had done using RegRipper...and it worked like a champ! I simply fired up RegRipper 2.02, pointed it at the NTUSER.DAT for the user account on my remote system, and ran it, saving the report and log files locally.
Awesome! RegRipper ran very well, over F-Response...as if it were running against a file that I'd extracted from an image, locally.
The cool thing is that F-Response EE can be easily pushed out as part of an incident preparedness program, or pushed out remotely using tools like psexec.exe. By design (and an excellent choice, I must say), the F-Response service does NOT start automatically...which means that as an administrator, you can have the service sitting there until you need it. As an incident responder, once you get it set up and running, all you need to do is launch the service.
Matt Shannon, the creator of F-Response, also has two other versions of F-Response...I was using the Enterprise Edition. Check out his site and see which version may be suitable for you.
Great job, Matt! Excellent tool! I really look forward to seeing not only what updates you may have available in the future, but also some of the novel and inventive ways folks come up with for using and employing such a simple and yet 0h-so-powerful tool!
Note: Updating a license for F-Response is a breeze! Download the update file, download the updater, plug in the FOB, run the updater, point it at the update file...and bang, in a couple of seconds you're stick-a-fork-in-me-I'm-DONE!
Addendum:
Rob Hensing blogs about...this post!
Lance "The Man" Mueller's blog post
Just so you know, you'll need to get the MS iSCSI Software Initiator as well.
So once I got everything set up (Matt's documentation is pretty straight forward) and running, all I had to do was run the installed service on the remote system...in this case, a Windows XP VMWare session. Once that was done, I had a nice little indicator that the remote system was connected to. Very good. Then I looked and saw that I had an icon for an F:\ drive now attached to my system. I could browse it, copy files, do whatever...it was all read-only. No changes (file modifications, adding files, etc.) appeared on the remote system drive.
So then I thought I'd replicate what Hogfly had done using RegRipper...and it worked like a champ! I simply fired up RegRipper 2.02, pointed it at the NTUSER.DAT for the user account on my remote system, and ran it, saving the report and log files locally.
Awesome! RegRipper ran very well, over F-Response...as if it were running against a file that I'd extracted from an image, locally.
The cool thing is that F-Response EE can be easily pushed out as part of an incident preparedness program, or pushed out remotely using tools like psexec.exe. By design (and an excellent choice, I must say), the F-Response service does NOT start automatically...which means that as an administrator, you can have the service sitting there until you need it. As an incident responder, once you get it set up and running, all you need to do is launch the service.
Matt Shannon, the creator of F-Response, also has two other versions of F-Response...I was using the Enterprise Edition. Check out his site and see which version may be suitable for you.
Great job, Matt! Excellent tool! I really look forward to seeing not only what updates you may have available in the future, but also some of the novel and inventive ways folks come up with for using and employing such a simple and yet 0h-so-powerful tool!
Note: Updating a license for F-Response is a breeze! Download the update file, download the updater, plug in the FOB, run the updater, point it at the update file...and bang, in a couple of seconds you're stick-a-fork-in-me-I'm-DONE!
Addendum:
Rob Hensing blogs about...this post!
Lance "The Man" Mueller's blog post