By "wallet", I'm referring to your CD wallet, or more specifically, your toolkit.
What tools do you use during Windows IR/CF activities?
What are your favorite/most relied upon tools for Windows Incident Response?
What tools to you use, in addition to the popular forensic suites (FTK, EnCase, PyFlag, ProDiscover, TSK, etc.) when analyzing a Windows system image, regardless of platform?
Finally, what tools would you like to see? What are some of the tools that you'd like to have that you just can't find? What are you trying to accomplish, specific to Windows IR/CF analysis, that you simply cannot find a tool to help you?
Think of this as a Windows IR/CF Top 75 Tools list. I'll accumulate responses here, and any I receive via email, and post the list.
Saturday, May 27, 2006
SF updates info
Folks, I just wanted to point out a couple of things regarding the tools I have posted, and will be posting, to the SF site.
First off, I still have some tools up on CPAN that I thought may be of interest. I'll have to bring those down, and include them in some capacity within the SF toolset. I have to say that I've found the File::ReadEvt module and associated scripts to be pretty handy, particularly the evtstats.pl script. It's pretty handy for pulling statistics on the event log records out of the .evt file quickly. If you're looking for certain types of statistics, it's easy to modify, as well. I also used the File::ReadPE module recently to examine the headers of several PE files.
The second thing I wanted to mention is updates to the tools. Every now and then I get requests to modify the functionality, either b/c the tool didn't respond the way the user expected, or b/c of something I didn't anticipate in my development and testing. If the tool and most users would greatly benefit from the update and it isn't a major rework/redesign of the tool, I'll update it. Requests for updates that are a bit out there usually take a bit longer.
If you have any questions regarding the use of the tools, or would like to see updates to the functionality...how the output is formatted, what's listed in the output, etc...please don't hesitate to let me know. Sometimes the thing that you think is little and doesn't matter will end up being extremely useful to someone else. Also, the feedback is important for providing useful tools to the community.
First off, I still have some tools up on CPAN that I thought may be of interest. I'll have to bring those down, and include them in some capacity within the SF toolset. I have to say that I've found the File::ReadEvt module and associated scripts to be pretty handy, particularly the evtstats.pl script. It's pretty handy for pulling statistics on the event log records out of the .evt file quickly. If you're looking for certain types of statistics, it's easy to modify, as well. I also used the File::ReadPE module recently to examine the headers of several PE files.
The second thing I wanted to mention is updates to the tools. Every now and then I get requests to modify the functionality, either b/c the tool didn't respond the way the user expected, or b/c of something I didn't anticipate in my development and testing. If the tool and most users would greatly benefit from the update and it isn't a major rework/redesign of the tool, I'll update it. Requests for updates that are a bit out there usually take a bit longer.
If you have any questions regarding the use of the tools, or would like to see updates to the functionality...how the output is formatted, what's listed in the output, etc...please don't hesitate to let me know. Sometimes the thing that you think is little and doesn't matter will end up being extremely useful to someone else. Also, the feedback is important for providing useful tools to the community.
Thursday, May 25, 2006
Forensic Analysis Issues
I ran across something recently that I had researched before, and hadn't thought a lot about, so I thought I'd blog about it.
You're analyzing the image of a system that turns out to be a Windows XP system. You notice that several files of interest are referenced in the RecentDocs Registry key for a particular user, however, searches of both the "active" file system and the deleted files turn up nothing. You've dumped the contents of the UserAssist keys for that user and you don't see anything that would indicate that the user ran a privacy tool. Looking at the contents of the Prefetch directory, you find entries for the defrag tool.
Checking the dates on Registry keys (application/system MRU lists, etc.) and files (MAC times, as well as the dates maintained within the Prefetch files themselves) you see that the Recycle Bin was emptied after the files were opened/viewed, and the defrag tool was run after the Recycle Bin was emptied...not immediately after, but within a day or two.
So...what's going on? Well, it seems that part of the user "eXPerience" that is XP includes the Prefetch functionality, ostensibly to speed up the loading/launching of frequently used applications. Where does the defrag come in, you ask? Read this. Right beneath figure 1 is an explanation of the defrag activity, and while it isn't a full defrag, it happens, and could cause deleted files that you would normally expect to find to be overwritten.
This is definitely something to keep in mind during your analysis, as well as something to look for/document.
What are some of the issues that you've run into?
You're analyzing the image of a system that turns out to be a Windows XP system. You notice that several files of interest are referenced in the RecentDocs Registry key for a particular user, however, searches of both the "active" file system and the deleted files turn up nothing. You've dumped the contents of the UserAssist keys for that user and you don't see anything that would indicate that the user ran a privacy tool. Looking at the contents of the Prefetch directory, you find entries for the defrag tool.
Checking the dates on Registry keys (application/system MRU lists, etc.) and files (MAC times, as well as the dates maintained within the Prefetch files themselves) you see that the Recycle Bin was emptied after the files were opened/viewed, and the defrag tool was run after the Recycle Bin was emptied...not immediately after, but within a day or two.
So...what's going on? Well, it seems that part of the user "eXPerience" that is XP includes the Prefetch functionality, ostensibly to speed up the loading/launching of frequently used applications. Where does the defrag come in, you ask? Read this. Right beneath figure 1 is an explanation of the defrag activity, and while it isn't a full defrag, it happens, and could cause deleted files that you would normally expect to find to be overwritten.
This is definitely something to keep in mind during your analysis, as well as something to look for/document.
What are some of the issues that you've run into?
Tuesday, May 23, 2006
Sourceforge updates
Okay, I know I haven't blogged in a while, but work's been busy.
On a positive note, I updated the contents of the WindowsIR Sourceforge site tonight, revamping the structure of the project itself. I've uploaded the lsproc, lspd, lspm, and RAMDump tools. If you remember, RAMDump is a GUI wrapper around George Garner's dd.exe, allowing the user to dump the contents of physical memory from a Windows 2000/XP system.
The rest of the tools are specific to Windows 2000 systems. That is to say, lsproc will parse through a dd.exe-style dump of physical memory from a Windows 2000 system and locate EPROCESS blocks. Lspd will extract process details based on the output of lsproc, and lspm will dump the memory used by a process based on the output of lsproc. Each of these three packages contains Perl source code, a Windows EXE compiled using Perl2Exe, and a required DLL.
Again...these three utilities are in the Windows2000 release because they work on memory dumps from Windows 2000 systems.
I will be posting other tools on this site over time, ranging from live response/IR tools to utilities meant for CF analysis.
Besides work (which I won't be posting about) I've been doing a lot of thinking with regards to live response, and I will be posting my thoughts.
Addendum: I uploaded the Offline Registry Parser, regp.pl, to the SF site, as well. The archive contains the Perl code, a Windows EXE compiled with Perl2Exe (you can use PAR, as well), and a required DLL.
On a positive note, I updated the contents of the WindowsIR Sourceforge site tonight, revamping the structure of the project itself. I've uploaded the lsproc, lspd, lspm, and RAMDump tools. If you remember, RAMDump is a GUI wrapper around George Garner's dd.exe, allowing the user to dump the contents of physical memory from a Windows 2000/XP system.
The rest of the tools are specific to Windows 2000 systems. That is to say, lsproc will parse through a dd.exe-style dump of physical memory from a Windows 2000 system and locate EPROCESS blocks. Lspd will extract process details based on the output of lsproc, and lspm will dump the memory used by a process based on the output of lsproc. Each of these three packages contains Perl source code, a Windows EXE compiled using Perl2Exe, and a required DLL.
Again...these three utilities are in the Windows2000 release because they work on memory dumps from Windows 2000 systems.
I will be posting other tools on this site over time, ranging from live response/IR tools to utilities meant for CF analysis.
Besides work (which I won't be posting about) I've been doing a lot of thinking with regards to live response, and I will be posting my thoughts.
Addendum: I uploaded the Offline Registry Parser, regp.pl, to the SF site, as well. The archive contains the Perl code, a Windows EXE compiled with Perl2Exe (you can use PAR, as well), and a required DLL.
Subscribe to:
Posts (Atom)