Cutaway does Windows IR
The Security Ripcord site has a great new article on Windows IR, and using system resources to get the data you need.
I know that some folks are going to have an issue with using system resources (ie, DLLs, etc) when performing any kind of IR, but to be honest, I honestly believe (based on experience) that if more folks had stopped using that as a roadblock for doing any kind of response at all, there would likely be fewer instances of reported breaches, and breaches may have been less severe.
All incident response starts with the same basic elements and questions as any other system troubleshooting. The problem seems to start when admins and responders simply have no idea what it is they need to be looking at, or for. Don's article does a great job of bringing that to light, as well as providing a means of acquiring the necessary data. Not only does Don explain what is accessed and why, he also provides caveats about the artifacts left on the system as a result of the admin or responder's interactions with the system. This is very important, as anytime you access a live system, you're going to leave artifacts of one kind or another...being able to distinguish between your actions and the user's actions may be very important. Scripts such as what Don provided are self-documenting, in that all you have to do is ensure that you keep track of when (as in "what time") you ran the script, and then include a copy of the script along with your case notes.
A great big thanks and Semper Fi to Don for providing this article and script! It's information like this that's going to break down the barriers of inaction and provide for better response to all sorts of issues, large and small.
I know that some folks are going to have an issue with using system resources (ie, DLLs, etc) when performing any kind of IR, but to be honest, I honestly believe (based on experience) that if more folks had stopped using that as a roadblock for doing any kind of response at all, there would likely be fewer instances of reported breaches, and breaches may have been less severe.
All incident response starts with the same basic elements and questions as any other system troubleshooting. The problem seems to start when admins and responders simply have no idea what it is they need to be looking at, or for. Don's article does a great job of bringing that to light, as well as providing a means of acquiring the necessary data. Not only does Don explain what is accessed and why, he also provides caveats about the artifacts left on the system as a result of the admin or responder's interactions with the system. This is very important, as anytime you access a live system, you're going to leave artifacts of one kind or another...being able to distinguish between your actions and the user's actions may be very important. Scripts such as what Don provided are self-documenting, in that all you have to do is ensure that you keep track of when (as in "what time") you ran the script, and then include a copy of the script along with your case notes.
A great big thanks and Semper Fi to Don for providing this article and script! It's information like this that's going to break down the barriers of inaction and provide for better response to all sorts of issues, large and small.