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
▼
Tuesday, March 15, 2005
HOW TOs
Here's a question to the reader...with regards to incident response on Windows systems, what kind of "HOW TO" guides would you like to see? What are some topics that you feel need to be covered? I've got my own ideas, but I also have a different perspective...so I'd like to hear what you have to say...
I'd like to see a comprehensive guide to what registry keys are worth looking at for different kinds of investigations. For example, for a pr0n case I'd like to know about what files have been recently opened and accessed by a variety of programs. For a malware case I'd like to see about what programs are set to autorun plus a quick check for well known malware values. For an intrusion case I'd like to see what services are running and which are enabled by default.
ReplyDeleteMaybe that kind of check could even be automated? But there should still be a guide to which keys are important.
Jesse,
ReplyDeleteGreat comment. I'm actually looking at doing something very similar to that, right now.
One of the best tools for checking a live system is AutoRuns from SysInternals. I prefer the CLI version myself...and I'd also add some keys that allow programs to start when the user performs certain actions.
From the perspective of imaged systems, though, Chris Brown at TechPathways tells me he's adding a scripting language to ProDiscover, and he's opting for Perl...that should make things very interesting.
Again, great comment...
I agree, a reg key guide would be useful. Perhaps also "how to" verify hash values for a suspect *.exe, or what to look for when sniffing network traffic.
ReplyDeleteSK,
ReplyDeletePerhaps also "how to" verify hash values for a suspect *.exe
Well, that one's pretty straight forward...you use a tool to compute the hash value for the suspect .exe and then compare it to a list of known-bads. Did I miss something?
what to look for when sniffing network traffic.
Can you elaborate? Perhaps specify? Generally, when you're sniffing network traffic, you may already have reason to do so...an unusual open port on a system, or something suspicious in your firewall or IDS logs. So right there, you would already have something "to look for"...ports, IP addresses, etc.
Anything you can add to clarify would be useful...
Thanks!
SK,
ReplyDeletePerhaps also "how to" verify hash values for a suspect *.exe
Well, that one's pretty straight forward...you use a tool to compute the hash value for the suspect .exe and then compare it to a list of known-bads. Did I miss something?
what to look for when sniffing network traffic.
Can you elaborate? Perhaps specify? Generally, when you're sniffing network traffic, you may already have reason to do so...an unusual open port on a system, or something suspicious in your firewall or IDS logs. So right there, you would already have something "to look for"...ports, IP addresses, etc.
Anything you can add to clarify would be useful...
Thanks!
Ooops...sorry about the double post...
ReplyDeleteI am working on a Registry key guide, but for the life of me, there are some keys that I just cannot find any information on...the MSDN search site turns up nothing, and Google turns up people posting HiJackThis logs...
My experience with MS is that once you finally find someone to answer your questions, they either get re-assigned, or tell you that you need to sign an NDA...
SK,
ReplyDeleteFor the network side of things, you may want to check this HoneyNet SotM challenge out.
http://project.honeynet.org/scans/scan27/
You can not only d/l the packet captures themselves, but you can read through the write ups...