More Perl-y goodness
I've uploaded a new script (handle.pl) to the files section of the Win4n6 Yahoo group...this is a script I wrote this morning to process the output of "handle -a" (collected during live response), based on a couple of things mentioned by Kris Harms and Pete Silberman (both of Mandiant) during the SANS Forensic Summit.
The script extracts, parses, and lists all entries for "pid:", which is something Kris mentioned during his presentation is a means of collecting the same information (ie, process listing) using a disparate means (ie, different API calls). After completing this iteration of the script, I figured that the next version will include additional processing of other items.
The script also processes the output for mutants and displays them all based on the "frequency of least occurrence". Pete mentioned that malware is (should be) the least frequent thing to occur on a system, and malware authors are using mutexes to ensure that infected systems are not continually infected over and over again. Many times, these mutexes are random names, whereas they usually appear as easily readable strings in most cases.
So, during live response, should the responder opt to run "handle -a > handle.log" as part of a batch file, the resulting output of the command (ie, handle.log) can be quickly and easily parsed using scripts like this. Also, this acts as a force-multiplier, in that the knowledge developed by a few is made easily available to many. Seriously...how often do you hear someone say, "...find interesting or suspicious processes..." with no mention of what constitutes "interesting" or "suspicious"?
Thoughts?
Addendum, 20090720: I've updated the handle.pl Perl script to include include some disparity checking in processes (searches for PIDs vs process/thread handles), etc. I see this script as being extremely useful and very valuable for performing some automated parsing and analysis of collected data, as codifying the "rules" for initial processing of the data allows for the use of automation as a force multiplier and error reduction technique. I can also see how it would be useful to add Least Frequency of Occurrence (LFO) checking for other (Event, Device, File, Key) handles, as well as process listing disparity checking against the output of other process listing tools (ie, pslist, tlist, etc.)
The script extracts, parses, and lists all entries for "pid:", which is something Kris mentioned during his presentation is a means of collecting the same information (ie, process listing) using a disparate means (ie, different API calls). After completing this iteration of the script, I figured that the next version will include additional processing of other items.
The script also processes the output for mutants and displays them all based on the "frequency of least occurrence". Pete mentioned that malware is (should be) the least frequent thing to occur on a system, and malware authors are using mutexes to ensure that infected systems are not continually infected over and over again. Many times, these mutexes are random names, whereas they usually appear as easily readable strings in most cases.
So, during live response, should the responder opt to run "handle -a > handle.log" as part of a batch file, the resulting output of the command (ie, handle.log) can be quickly and easily parsed using scripts like this. Also, this acts as a force-multiplier, in that the knowledge developed by a few is made easily available to many. Seriously...how often do you hear someone say, "...find interesting or suspicious processes..." with no mention of what constitutes "interesting" or "suspicious"?
Thoughts?
Addendum, 20090720: I've updated the handle.pl Perl script to include include some disparity checking in processes (searches for PIDs vs process/thread handles), etc. I see this script as being extremely useful and very valuable for performing some automated parsing and analysis of collected data, as codifying the "rules" for initial processing of the data allows for the use of automation as a force multiplier and error reduction technique. I can also see how it would be useful to add Least Frequency of Occurrence (LFO) checking for other (Event, Device, File, Key) handles, as well as process listing disparity checking against the output of other process listing tools (ie, pslist, tlist, etc.)
More Perl-y goodness
![More Perl-y goodness]()
Reviewed by 0x000216
on
Sunday, July 19, 2009
Rating: 5