I wanted to share the responses I received with regards to my Blog Topics post...
First off, there really weren't many responses at all...less than half a dozen. Of those, the predominance seemed to be along the lines of "talk about how you've used tools to investigate incidents". Hhhmmm...that's all well and good, and I'll try to do more of that sort of thing, either using real incidents or by using more contrived examples.
Two of the emails I received asked specifically about open-source tools. This was interesting, as I've been considering talking more about the Forensic Server Project and it's uses. I'm going to be making posts on the FSP and accompanying First Responder Utility (or "FRU") in the future. I'm also working on a standalone version of the FRU that incorporates much of the functionality of the FSP itself, but writes to an arbitrary storage location, rather than a server.
As I've stated before, though, data collection is easy...it's the analysis that's the key to an investigation. As such, I am leaning more towards posting collected data for the reader to examine, and providing my analysis at a later date, rather than just posting a "here's what happened". I did this in my book, providing the output of the FSP for the reader to comb through.
So, keep your eyes peeled for upcoming posts, and as always, comments and emails are welcome.
3 comments:
That sounds like fun, I'm looking forward to your future posts. Regarding FSP, since it's mainly for collecting, do you plan on adding any analysis features to it? An easy way to do time analysis on files, log entries, and registry keys would be a lot of help.
Great blog, I've got it bookmarked. :)
Yes, I am planning to add an analysis suite to the server component of the FSP, but it's difficult to create the one thing that does everything that everyone wants. Also, based on what I've seen so far via email, etc., there just hasn't been a single person asking for anything specific. I released an initial approach at an analysis/presentation tool with the book, and so far have not received any feedback or response at all with regards to its usefulness.
If you have a specific request, please post it here, or email me.
Thanks,
Harlan
Well just so you know, I'm still learning, not quite an investigator yet... but I've been messing around with Log Parser recently, and it seems like it could be a great tool to use to manage some of the evidence, and even better if it had a GUI. One of the sample files (EventLogs.tpl) that comes with it is a template that you can use to output event logs in a nice html file. If you could dump all of the event logs, as well as the metadata of all the files to the FSP server, you could create a GUI that uses Log Parser to analyze that and other evidence. It could have a web browser interface similar to Autopsy for the Sleuth Kit. A top frame with the interface to Log Parser allowing you to select the log files, and specific content you want to observe, and in the main frame have the output html.
One link could be time analysis where you can select the file activity, registry write times, and which event logs you want Log Parser to merge and sort by time, also giving you the ability to zone in on a time range. Make it so you can click on the + by the entry to view the rest of the metadata, or log entry. It could also automatically highlight suspicious entries such as the event log clearing, WFP protected files being deleted, files that contain ADS, executables that contain the wrong file extension, and other indications of suspicious activity.
Another link could process related. Your procdump.pl would be a great start to this. Highlight known trojan ports, programs that have been misnamed to appear standard, or common program names that are running from a non-standard directory. List autorun programs, showing their MAC times so you can see which one was the most recent addition, which might be the most suspicious. It might also be good to highlight which files are set to autorun in the above time analysis section.
Another link could be general information about the case, or computer information from psinfo or servicceinfo, etc.
Here is a good article on how Log Parser can be used to parse IIS logs, showing its usefulness in a forensic investigation.
http://www.securityfocus.com/infocus/1712
Many thanks for making the FSP. Right now I say it ranks up there with Snort, tcpdump, nmap, and others in that it does it's job, and does it extremely well. It should be the standard incident response tool, and I'm looking forward to wherever you take the analysis phase of it.
Post a Comment