I've posted my presentations for GMU2006, which starts next week. I'm posting them so that anyone attending can get a look at the presentations ahead of time, and so that those folks who aren't attending can see the same thing. One word of warning, though...I'm not a huge proponent of "death by PowerPoint"...meaning that my entire script isn't on the slides. However, there should be more than enough there to give you a really good idea of what's going to be said. Also, I tend to be very interactive, discussing topics with the attendees rather than at them.
So, the archive contains my presentations on Windows memory analysis and tracking USB devices across Windows systems. There is a third presentation, as well, that is for the opening session...the folks running the conference asked me late last week to speak, and I thought I'd fill the time talking about issues we're facing as a community.
If you download the presentations and have questions or comments, please feel to share them here, or with me directly.
Addendum 1 Aug: Okay, here's my speaking schedule for the conference:
Mon, 7 Aug: Opening session, 9:30 - 10:30AM
Tues, 8 Aug: "Tracking USB Devices", 10AM
Wed, 9 Aug: "Windows Memory Analysis", 10AM
Thu, 10 Aug: "Tracking USB Devices", 8AM
Thu, 10 Aug: "Windows Memory Analysis", 10AM
In addition, there are a lot of great presentations going on...Cynthia Hetherington is a fantastic speaker, and Terri Gudaitis is giving her "Cybercrime Profiling" presentation again - it's always a winner. Also, I just spoke with Jesse Kornblum and he's only going to be on-site for his presentation on "Fuzzy Hashing" at 8am on Tues - boys and girls, Jesse's presentation on "Fuzzy Hashing" is a MUST SEE, even if you've listened to his Cyberspeak podcast interview!
I'd suggest buying Jesse a beer, but I don't know how he feels about imbiding that early in the day. I, however, am of the firm belief that it's 5 o'clock somewhere. ;-)
Tuesday, August 01, 2006
Monday, July 31, 2006
Extracting Executable Images from RAM Dumps
In his Cyberspeak podcast interview, Jesse Kornblum mentioned the tool I'd recently released called Lspi.pl, for LiSt Process Image.
As of this morning, SourceForge.net shows that it's been downloaded 32 times. If you're reading this, and you're one of the folks who downloaded and has tried it, I'd greatly appreciate any comments you may have.
As of this morning, SourceForge.net shows that it's been downloaded 32 times. If you're reading this, and you're one of the folks who downloaded and has tried it, I'd greatly appreciate any comments you may have.
"Genius" Kornblum on fuzzy hashing
Jesse Kornblum was recently interviewed by the CyberSpeak podcast guys with regards to his "fuzzy hashing" paper to be presented at DFRWS.
Jesse, the author of hashing tools such as md5-, tiger-, and whirlpooldeep, has come up with something called "fuzzy hashing" which can be used to combat the approach that's being taken to obfuscate files by making small changes, as with Word documents (intellectual property crime) and images ('nuff said).
Jesse clearly explains the concept behind "fuzzy hashing" in his interview...in a nutshell, if you have two similar bitstreams (ie, JPEGs, GIFs, etc.) that have small changes, his tool (dubbed "SSDeep") will be able to tell you if they are similar...whereas tools like MD5Deep will tell you if the tools are exactly the same via a mathematical algorithm.
So what are the applications of something like this? Well, first off, it's not meant to find evidence; instead, it's an awesome data reduction tool. One of the examples Jesse used in his interview is Word documents that are printed out. When you print out a Word document, the time that the document was last printed is modified within the document itself...so an MD5 hash generated for the original document will not match the one generated for the printed document. The bitstreams are essentially the same, with some small modifications, and Jesse says that his tool will let you know that the two files are similar.
There are many other applications for this tool, to include image identification, intellectual property theft, etc. So, go on over to Cyberspeak and give the podcast a listen. If you see Jesse at DFRWS or GMU2006 or HTCIA, say hi, and buy him a beer!
Interestingly, Jesse is presenting on Windows memory analysis at HTCIA (end of Oct)...I'll be presenting on the subject at GMU2006. Jesse's also presenting at GMU2006.
BTW...Jesse, if you're reading this...thanks for the shout-out in your Cyberspeak interview!
Jesse, the author of hashing tools such as md5-, tiger-, and whirlpooldeep, has come up with something called "fuzzy hashing" which can be used to combat the approach that's being taken to obfuscate files by making small changes, as with Word documents (intellectual property crime) and images ('nuff said).
Jesse clearly explains the concept behind "fuzzy hashing" in his interview...in a nutshell, if you have two similar bitstreams (ie, JPEGs, GIFs, etc.) that have small changes, his tool (dubbed "SSDeep") will be able to tell you if they are similar...whereas tools like MD5Deep will tell you if the tools are exactly the same via a mathematical algorithm.
So what are the applications of something like this? Well, first off, it's not meant to find evidence; instead, it's an awesome data reduction tool. One of the examples Jesse used in his interview is Word documents that are printed out. When you print out a Word document, the time that the document was last printed is modified within the document itself...so an MD5 hash generated for the original document will not match the one generated for the printed document. The bitstreams are essentially the same, with some small modifications, and Jesse says that his tool will let you know that the two files are similar.
There are many other applications for this tool, to include image identification, intellectual property theft, etc. So, go on over to Cyberspeak and give the podcast a listen. If you see Jesse at DFRWS or GMU2006 or HTCIA, say hi, and buy him a beer!
Interestingly, Jesse is presenting on Windows memory analysis at HTCIA (end of Oct)...I'll be presenting on the subject at GMU2006. Jesse's also presenting at GMU2006.
BTW...Jesse, if you're reading this...thanks for the shout-out in your Cyberspeak interview!
Thursday, July 20, 2006
LiSt Process Image upload
I've uploaded lspi 0.4 to my SourceForge site, and if you use lsproc or want to be able to automatically extract process image files from RAM dumps (of Windows 2000 systems, at this point), then you definitely want to check this out! This is the "automatic binary extractor" that Andreas mentioned a while back.
This code (the archive contains the Perl script and a Windows EXE "compiled" using Perl2Exe...be sure to keep the included DLL with the EXE at all times) makes use of some of the RAM dump file parsing code from tools like lsproc and lspd, as well as the code from my File::ReadPE module. Like the other tools, this one relies on the output of lsproc for it's input...specifically, the offset to the process in question. It uses pretty much the same method as Andreas mentioned in his first blog entry on reassembling binaries, for no other reason than it just makes sense. After all, why not use the "map" provided to you in the PE headers to reassemble the executable image file.
Let's take a look at an example, focusing on the same process that Andreas looked at...dd.exe with a PID of 284, from the first memory dump from the DFRWS 2005 Memory Challenge. The output of lsproc gives us:
Proc 1112 284 dd.exe 0x0414dd60 Sun Jun 5 14:53:42 2005
Very cool. So, using the offset to the process within the dump file, we can then launch lspi with the following command line:
C:\Perl>lspi.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
What we get as output is:
lspi - list Windows 2000 process image (v.0.4 - 20060721)
Ex: lspi
Process Name : dd.exe
PID : 284
DTB : 0x01d9e000
PEB : 0x7ffdf000 (0x02c2d000)
ImgBaseAddr : 0x00400000 (0x00fee000)
e_lfanew = 0xe8
NT Header = 0x4550
Reading the Image File Header
Sections = 4
Opt Header Size = 0x000000e0 (224 bytes)
Characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
Machine = IMAGE_FILE_MACHINE_I860
Reading the Image Optional Header
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00006bda
Image Base : 0x00400000
File Align : 0x00001000
Reading the Image Data Directory information
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x0000d000 0x00000430
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x0000af7c 0x000000a0
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x0000b25c 0x000000a0
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x00007000 0x00000210
Reading Image Section Header information
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00005ee0 0x00001000 0x00001000 0x00006000 0x60000020
.data 0x000002fc 0x0000c000 0x0000c000 0x00001000 0xc0000040
.rsrc 0x00000430 0x0000d000 0x0000d000 0x00001000 0x40000040
.rdata 0x00004cfa 0x00007000 0x00007000 0x00005000 0x40000040
Reassembling image file into dd.exe.img
Bytes written = 57344
New file size = 57344
Most of this is the PE header being parsed and displayed.
Now, a couple of caveats...first, this code ONLY works for RAM dumps from Windows 2000 systems (yes, I have been getting a lot of questions about that). Second, this does not take PAE into account. Nor does it take special cases into account, such as UPX compressed executables.
However, the code does check for things like pages that are paged out to the pagefile. Sounds kind of circular, I know, but basically, the pages in RAM that aren't being used can be paged out to pagefile.sys...since we're just dealing with a memory dump, we're assuming at this point that the pages in the pagefile aren't available.
Also, you will notice that the resulting executable image, once renamed to an .exe, does not run the way the original does. This is due to the fact that once the various sections are loaded into memory, some of the values in the different sections will change as the code is being run.
So, how is something like this useful? Well, if you're into malware analysis, or if you're performing incident response against an as-yet-unknown bit of code, this would be helpful.
Of course, there are things that need to be added to this code, as it performs only parsing. For example, some actual analysis would be in order...like analyzing the code at the entry point address, performing some analysis of the sections, extracting the import address (or name) tables, etc.
As always, comments are welcome...
This code (the archive contains the Perl script and a Windows EXE "compiled" using Perl2Exe...be sure to keep the included DLL with the EXE at all times) makes use of some of the RAM dump file parsing code from tools like lsproc and lspd, as well as the code from my File::ReadPE module. Like the other tools, this one relies on the output of lsproc for it's input...specifically, the offset to the process in question. It uses pretty much the same method as Andreas mentioned in his first blog entry on reassembling binaries, for no other reason than it just makes sense. After all, why not use the "map" provided to you in the PE headers to reassemble the executable image file.
Let's take a look at an example, focusing on the same process that Andreas looked at...dd.exe with a PID of 284, from the first memory dump from the DFRWS 2005 Memory Challenge. The output of lsproc gives us:
Proc 1112 284 dd.exe 0x0414dd60 Sun Jun 5 14:53:42 2005
Very cool. So, using the offset to the process within the dump file, we can then launch lspi with the following command line:
C:\Perl>lspi.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
What we get as output is:
lspi - list Windows 2000 process image (v.0.4 - 20060721)
Ex: lspi
Process Name : dd.exe
PID : 284
DTB : 0x01d9e000
PEB : 0x7ffdf000 (0x02c2d000)
ImgBaseAddr : 0x00400000 (0x00fee000)
e_lfanew = 0xe8
NT Header = 0x4550
Reading the Image File Header
Sections = 4
Opt Header Size = 0x000000e0 (224 bytes)
Characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
Machine = IMAGE_FILE_MACHINE_I860
Reading the Image Optional Header
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00006bda
Image Base : 0x00400000
File Align : 0x00001000
Reading the Image Data Directory information
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x0000d000 0x00000430
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x0000af7c 0x000000a0
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x0000b25c 0x000000a0
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x00007000 0x00000210
Reading Image Section Header information
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00005ee0 0x00001000 0x00001000 0x00006000 0x60000020
.data 0x000002fc 0x0000c000 0x0000c000 0x00001000 0xc0000040
.rsrc 0x00000430 0x0000d000 0x0000d000 0x00001000 0x40000040
.rdata 0x00004cfa 0x00007000 0x00007000 0x00005000 0x40000040
Reassembling image file into dd.exe.img
Bytes written = 57344
New file size = 57344
Most of this is the PE header being parsed and displayed.
Now, a couple of caveats...first, this code ONLY works for RAM dumps from Windows 2000 systems (yes, I have been getting a lot of questions about that). Second, this does not take PAE into account. Nor does it take special cases into account, such as UPX compressed executables.
However, the code does check for things like pages that are paged out to the pagefile. Sounds kind of circular, I know, but basically, the pages in RAM that aren't being used can be paged out to pagefile.sys...since we're just dealing with a memory dump, we're assuming at this point that the pages in the pagefile aren't available.
Also, you will notice that the resulting executable image, once renamed to an .exe, does not run the way the original does. This is due to the fact that once the various sections are loaded into memory, some of the values in the different sections will change as the code is being run.
So, how is something like this useful? Well, if you're into malware analysis, or if you're performing incident response against an as-yet-unknown bit of code, this would be helpful.
Of course, there are things that need to be added to this code, as it performs only parsing. For example, some actual analysis would be in order...like analyzing the code at the entry point address, performing some analysis of the sections, extracting the import address (or name) tables, etc.
As always, comments are welcome...
Monday, July 17, 2006
Automatic binary reassembly from a RAM dump
A bit ago, Andreas Schuster posted to his blog about reconstructing executable images from a RAM dump (1, 2, 3). The first method listed not only made the most sense to me at the time, but was also easy to implement, as it dovetailed right off of some code I'd written to parse PE file headers. As I blogged about earlier, getting the PE header information from the ImageBaseAddress offset is just the beginning.
I'm posting now to say that I recently got the code for automatic reassembly of executable images working. My results are identical to those shown in Andreas's first blog post. I suspect that Andreas may be correct in his third post that the reassembled binary won't run correctly due to changes in code as the program runs. However, there are other conditions to consider...for instance, what if pages from the image have been paged out to the pagefile?
After extracting the binary image for dd.exe from the first RAM dump used in the DFRWS 2005 Memory Challenge, I ran a script to extract the PE header info, and compared that to the PE header info for the original copy of the executable, retrieved from George Garner's site. Visually, the headers are identical. I've since used Jesse Kornblum's md5deep tool to verify that the .rsrc sections from both files (original and reconstructed) are identical.
More testing needs to be done, and the code needs to be cleaned up and brought in line with the other code already available. Once I've completed this, I'm going to redesign the format of the tools to be better suited to identifying the OS of the RAM dump, and then progressing on from there. At this point, like the other tools currently available, this code only works for RAM dumps from Windows 2000 systems.
You may be saying to yourself..."Yeah...and?" Some folks ask me why this kind of thing is important. Well, for one, if you're performing live response and suspect that there may be malware or a rootkit, you may want to actually get the executable for analysis. This may also be useful during dynamic analysis of malware, in which obfuscated malware is decompressed/decrypted when in memory.
I'm posting now to say that I recently got the code for automatic reassembly of executable images working. My results are identical to those shown in Andreas's first blog post. I suspect that Andreas may be correct in his third post that the reassembled binary won't run correctly due to changes in code as the program runs. However, there are other conditions to consider...for instance, what if pages from the image have been paged out to the pagefile?
After extracting the binary image for dd.exe from the first RAM dump used in the DFRWS 2005 Memory Challenge, I ran a script to extract the PE header info, and compared that to the PE header info for the original copy of the executable, retrieved from George Garner's site. Visually, the headers are identical. I've since used Jesse Kornblum's md5deep tool to verify that the .rsrc sections from both files (original and reconstructed) are identical.
More testing needs to be done, and the code needs to be cleaned up and brought in line with the other code already available. Once I've completed this, I'm going to redesign the format of the tools to be better suited to identifying the OS of the RAM dump, and then progressing on from there. At this point, like the other tools currently available, this code only works for RAM dumps from Windows 2000 systems.
You may be saying to yourself..."Yeah...and?" Some folks ask me why this kind of thing is important. Well, for one, if you're performing live response and suspect that there may be malware or a rootkit, you may want to actually get the executable for analysis. This may also be useful during dynamic analysis of malware, in which obfuscated malware is decompressed/decrypted when in memory.
Wednesday, July 12, 2006
Forensics Magazine
A bit ago, I blogged about cool technical e-zines that are available. Since then, CheckMate really seems to have come along, and I've also found some well-written content in the CodeBreakers Journal (be sure to check out the Magazine, as well).
While most of these e-zines are technical in nature, there don't seem to be many specific to forensic analysis. My first question is...is there any interest in such a thing? My thoughts are that such an e-zine would cover more than just forensic analysis of Windows systems, and would include topics in live response, legal issues, as well as (potentially) case studies, how-tos, etc.
Now, I know that there are several journals out there now, such as the DIJ and the IJDE, but I'm thinking of something a little more practical, down-and-dirty (though the article on iPod forensics from the IJDE is a lot like what I'm thinking of). If you're not familiar with it, check out SysAdmin Magazine. I like the format of this magazine because a lot of times, the articles don't simply refer to something being done...they actually provide the tools (be it a link to an executable, a shell script, etc.) to accomplish the task, and enough explanation for the reader to customize the script/process.
So...is there interest? If so, what would you like to see in such an e-zine? Or do you think that there's already enough magazines, journals and e-zines out there, and the last thing you want to see is another one?
While most of these e-zines are technical in nature, there don't seem to be many specific to forensic analysis. My first question is...is there any interest in such a thing? My thoughts are that such an e-zine would cover more than just forensic analysis of Windows systems, and would include topics in live response, legal issues, as well as (potentially) case studies, how-tos, etc.
Now, I know that there are several journals out there now, such as the DIJ and the IJDE, but I'm thinking of something a little more practical, down-and-dirty (though the article on iPod forensics from the IJDE is a lot like what I'm thinking of). If you're not familiar with it, check out SysAdmin Magazine. I like the format of this magazine because a lot of times, the articles don't simply refer to something being done...they actually provide the tools (be it a link to an executable, a shell script, etc.) to accomplish the task, and enough explanation for the reader to customize the script/process.
So...is there interest? If so, what would you like to see in such an e-zine? Or do you think that there's already enough magazines, journals and e-zines out there, and the last thing you want to see is another one?
Tuesday, July 11, 2006
Have you seen...?
I'm looking for a couple of things before I get started down the road in collecting my own data regarding forensic artifacts, so I thought I'd turn to the community at large to see what's already out there...
Specifically, I'm looking for credible sources regarding P2P application artifacts, including evidence of installation, searches, downloads, etc., within the Windows file system and Registry.
I'm also interested in forensic artifacts on Windows systems for popular steganography tools.
Has anyone seen any credible sites out there regarding these two areas?
Specifically, I'm looking for credible sources regarding P2P application artifacts, including evidence of installation, searches, downloads, etc., within the Windows file system and Registry.
I'm also interested in forensic artifacts on Windows systems for popular steganography tools.
Has anyone seen any credible sites out there regarding these two areas?
Book FAQ
In putting together my next book, one of the things I've put a lot of thought into is providing examples, as well as exercises. For example, I haven't found it very effective to say "run tool X against file Y"...instead, I'll provide a detailed walk-through (sort of like a mini case study) on how to do something, and then provide sample files that the reader can then run the tools/process against.
One thing that's been pretty consistent since my first book came out is folks wanting to know how to do specific tasks; how do I find movie files?, or how do I do X? For some of these specific, fairly frequent questions, I've been considering providing a FAQ in the book to answer/address them.
If you have questions like this, that you'd like see addressed, drop me a line and let me know. Please keep the questions specific to the forensic analysis of Windows systems...live or post-mortem.
One thing that's been pretty consistent since my first book came out is folks wanting to know how to do specific tasks; how do I find movie files?, or how do I do X? For some of these specific, fairly frequent questions, I've been considering providing a FAQ in the book to answer/address them.
If you have questions like this, that you'd like see addressed, drop me a line and let me know. Please keep the questions specific to the forensic analysis of Windows systems...live or post-mortem.
Thursday, June 22, 2006
New Forensics Book
I've found a publisher who wants to publish my second book. I've got a contract on my desk
right now. Our goal is to have this book on the shelves in late spring 2007.
This book will cover a variety of topics specific to information collection and analysis under live response and post-mortem conditions,
specifically for Windows systems. However, with the tools and techniques presented in this book, the analyst will
not be restricted solely to Windows as the analysis platform (many of the tools I created for this book
have been successfully testing on Windows, Linux, and Mac OS/X platforms).
This book will not cover topics that are not specific to Windows, such as imaging procedures, etc.
I've included a brief, conceptual outline below. My goal is to make this a valuable resource, full of
explanations, examples, and exercises. This will include sample memory captures, and links to images.
Some have suggested including sample system images on DVDs with the book, but in order to do so, I'd have to
include several DVDs. Talking with the publisher, most publishing systems are set up to press a single CD or
DVD for inclusion with the book...including additional media will drive the price of the book out of the range
of the intended audience.
I'd appreciate your input/comments on this, as well.
Some of the comments I've received from other sources include:
- Cover mobile devices: I'd love to...but I'm a one-man shop. I can't afford to purchase
mobile devices just for testing, nor can I afford the software to image such devices.
- Steganography: while not specific to Windows, it is definitely worth mentioning...but I'd
like to get some input from folks as to what needs to be addressed/discussed.
------------------------------------------------
Outline
------------------------------------------------
Chapter 1 – Introduction
- Purpose of the book, intended audience, what the book does/does not address
*Live Response section
Chapter 2 – Collecting Volatile Data
- Address live response, volatile data collection (ie, what to collect, how to collect it)
Chapter 3 – Analyzing Volatile Data
- How to understand what you've collected; data reduction/correlation techniques for volatile data
Chapter 4 – Windows Memory Analysis
- Description of \\.\PhysicalMemory, how to dump it, how to parse\analyze it.
*Post-Mortem section
Chapter 5 – Registry Analysis
- An explanation/description of the Windows Registry, how to locate information, etc. This chapter will
have many subsections covering specific areas, such as USB removable storage devices, etc.
Chapter 6 – Log/File Analysis
- Covers descriptions of files maintained by Windows for logging, etc. Covers several directories, explaining why/how they're used.
Chapter 7 – Malware analysis for Administrators
- PE file analysis for Administrators/investigators. This is not a debugger/disassembler training guide.
Chapter 8 – Rootkits and rootkit detection
- Descriptions of rootkits, detection techniques, etc.
right now. Our goal is to have this book on the shelves in late spring 2007.
This book will cover a variety of topics specific to information collection and analysis under live response and post-mortem conditions,
specifically for Windows systems. However, with the tools and techniques presented in this book, the analyst will
not be restricted solely to Windows as the analysis platform (many of the tools I created for this book
have been successfully testing on Windows, Linux, and Mac OS/X platforms).
This book will not cover topics that are not specific to Windows, such as imaging procedures, etc.
I've included a brief, conceptual outline below. My goal is to make this a valuable resource, full of
explanations, examples, and exercises. This will include sample memory captures, and links to images.
Some have suggested including sample system images on DVDs with the book, but in order to do so, I'd have to
include several DVDs. Talking with the publisher, most publishing systems are set up to press a single CD or
DVD for inclusion with the book...including additional media will drive the price of the book out of the range
of the intended audience.
I'd appreciate your input/comments on this, as well.
Some of the comments I've received from other sources include:
- Cover mobile devices: I'd love to...but I'm a one-man shop. I can't afford to purchase
mobile devices just for testing, nor can I afford the software to image such devices.
- Steganography: while not specific to Windows, it is definitely worth mentioning...but I'd
like to get some input from folks as to what needs to be addressed/discussed.
------------------------------------------------
Outline
------------------------------------------------
Chapter 1 – Introduction
- Purpose of the book, intended audience, what the book does/does not address
*Live Response section
Chapter 2 – Collecting Volatile Data
- Address live response, volatile data collection (ie, what to collect, how to collect it)
Chapter 3 – Analyzing Volatile Data
- How to understand what you've collected; data reduction/correlation techniques for volatile data
Chapter 4 – Windows Memory Analysis
- Description of \\.\PhysicalMemory, how to dump it, how to parse\analyze it.
*Post-Mortem section
Chapter 5 – Registry Analysis
- An explanation/description of the Windows Registry, how to locate information, etc. This chapter will
have many subsections covering specific areas, such as USB removable storage devices, etc.
Chapter 6 – Log/File Analysis
- Covers descriptions of files maintained by Windows for logging, etc. Covers several directories, explaining why/how they're used.
Chapter 7 – Malware analysis for Administrators
- PE file analysis for Administrators/investigators. This is not a debugger/disassembler training guide.
Chapter 8 – Rootkits and rootkit detection
- Descriptions of rootkits, detection techniques, etc.
Tuesday, June 20, 2006
RCFG/GMU2006
I'm due to present at the RCFG GMU2006 conference in August, on two topics. I'll be presenting on "Tracking USB Devices on Windows Systems" on Tues and Thu (download the agenda), and on "Windows Memory Analysis" on Wed and Thu - the agenda currently says that the second presentation will be "Windows File Metadata", but I've asked the conference coordinator to change it.
Are you planning to attend? If you're considering it, you should see who else is presenting. Jesse Kornblum will be there (check out one of his Cyberspeak podcast interviews), as will Cynthia Hetherington. Other topics include wireless and Mac forensics, as well as cybercrime profiling, presented by Terry Gudaitis.
See you there?
Are you planning to attend? If you're considering it, you should see who else is presenting. Jesse Kornblum will be there (check out one of his Cyberspeak podcast interviews), as will Cynthia Hetherington. Other topics include wireless and Mac forensics, as well as cybercrime profiling, presented by Terry Gudaitis.
See you there?
Friday, June 16, 2006
Case Issues
Sitting in my own little microcosm, my own little piece of the world, I tend to wonder sometimes if folks run into the same issues I do during a case, and if so, what they do about it...or, if not, what issues they do run into. I know lots of folks, in particular LEOs, don't usually discuss their cases, for fear of revealing too much information about the case...but for those willing to share bits and pieces of problems and solutions, I think that we could all benefit.
So, what are the issues you run into during live response (if you do live response)? Is it being surprised and unprepared? Is it not having the tools you need, either for collecting or analyzing evidence?
How about post-mortem investigations? What issues do you run into with regards to Windows systems?
One of the biggest things is that each case is different somehow...but I can guarantee you that somewhere, someone else has run into the same issues, and possibly come up with a solution.
As always, questions, comments, and concerns are welcome...
So, what are the issues you run into during live response (if you do live response)? Is it being surprised and unprepared? Is it not having the tools you need, either for collecting or analyzing evidence?
How about post-mortem investigations? What issues do you run into with regards to Windows systems?
One of the biggest things is that each case is different somehow...but I can guarantee you that somewhere, someone else has run into the same issues, and possibly come up with a solution.
As always, questions, comments, and concerns are welcome...
Monday, June 12, 2006
Malware update: Rootkit that uses NTFS ADS
Wow, two of my favorite subjects, in one bit of malware...neat! Rustock (a la Symantec's nomenclature) was discovered on 1 June (the Symantec page was updated on 9 June), and reportedly uses rootkit techniques to hide the files and Registry keys it creates.
Section 2 of the technical report says that this malware uses "hidden data streams". Interesting use of terminology, as by default, NTFS alternate data streams are hidden. Take a look at chapter 3 of my book, specifically page 83, for more info on ADSs...but the short version is that since MS does not provide any native tools for Windows for viewing or locating arbitrary ADSs, they are essentially "hidden".
I've located other references to this malware, but they all point back to the Symantec page...
Section 2 of the technical report says that this malware uses "hidden data streams". Interesting use of terminology, as by default, NTFS alternate data streams are hidden. Take a look at chapter 3 of my book, specifically page 83, for more info on ADSs...but the short version is that since MS does not provide any native tools for Windows for viewing or locating arbitrary ADSs, they are essentially "hidden".
I've located other references to this malware, but they all point back to the Symantec page...
I need your help...
...with two things, both with respect to the FRUC/FSPC.
The first thing I need your help with is based on a comment/request I received recently regarding launching the FSPC. Sometimes you may need to walk away from your forensics server system and you will want to launch the FSPC when you're ready, so having something accessible via a web browser might be useful. So what I'm looking for is someone who can put together some PHP or something that will allow you to not only launch the FSPC via a browser, but to shut it down when you're done. This should require authentication, and allow for all of the available switches to be set when launching the server component, and run on popular web servers (IIS 5/6, Apache, etc.). If you want to discuss requirements, or need some information, or need me to make changes/modifications to the FSPC, email me.
What I'd like to do is include several of the working submissions in my next book (I'm currently talking to a publisher), and for each submission that I include, provide the author with a free copy of my next book once it's published. The only things I would ask are that the submissions are fully documented, and there are no weird licensing issues.
The second thing I'd like your help with is circulating INI files. If you've put together an INI file that you use with the FRUC, and are willing to share it, please do so...email it to me, post a link, or whatever works for you.
The first thing I need your help with is based on a comment/request I received recently regarding launching the FSPC. Sometimes you may need to walk away from your forensics server system and you will want to launch the FSPC when you're ready, so having something accessible via a web browser might be useful. So what I'm looking for is someone who can put together some PHP or something that will allow you to not only launch the FSPC via a browser, but to shut it down when you're done. This should require authentication, and allow for all of the available switches to be set when launching the server component, and run on popular web servers (IIS 5/6, Apache, etc.). If you want to discuss requirements, or need some information, or need me to make changes/modifications to the FSPC, email me.
What I'd like to do is include several of the working submissions in my next book (I'm currently talking to a publisher), and for each submission that I include, provide the author with a free copy of my next book once it's published. The only things I would ask are that the submissions are fully documented, and there are no weird licensing issues.
The second thing I'd like your help with is circulating INI files. If you've put together an INI file that you use with the FRUC, and are willing to share it, please do so...email it to me, post a link, or whatever works for you.
FRUC and FSPC Cyberspeak Interview
The latest Cyberspeak podcast includes my interview regarding the latest version of the Forensic Server Project components. The interview was intended to be a "go-by" so listeners could follow along while playing with the tools.
If you've never listened to the Cyberspeak podcasts, give it a shot...very entertaining and very informative. Ovie and Bret do a fantastic job with the podcasts. If you enjoy the podcasts (or don't) or find something interesting, be sure to leave a comment.
If you've never listened to the Cyberspeak podcasts, give it a shot...very entertaining and very informative. Ovie and Bret do a fantastic job with the podcasts. If you enjoy the podcasts (or don't) or find something interesting, be sure to leave a comment.
Friday, June 09, 2006
Setting up the FRUC INI file
Now that the Forensic Server Project has been posted, I should take a moment to post something specifically about the First Responder Utility and the INI file used to configure it.
The First Responder Utility , or FRUC (the "C" stands for "command line"), is intended to make data collection from systems more efficient. We accomplish this in part by minimizing the interaction that the first responder has with the system. Have you ever tried typing the same 5 commands over and over again? How about at 2:30am, when you've already been up for almost 24 hrs, and you're under pressure to get many more machines done? As you can well imagine, this can lead to mistakes, which can have disasterous results. So, why not sit down ahead of time, when you have the time and you're not tired, and decide what tools you want to run? Then, put those tools in the order you want to run them. That way, the tools you want to run get run for you, and are essentially self-documenting (more on that later).
I included a sample INI file with the FRUC archive, so you can follow along looking at that while I go through the components of the file. The INI file is a standard Windows ini file and consists of four sections:
Configuration
This section allows you to designate certain settings for the FRUC, specifically the server to connect to and the port. These settings are overridden by whatever you enter at the command line.
Commands
This section is very important. This is where you enter the commands you want to run on the system, in the order you want to run them. Each of the tools you want to run must be in the same directory (usually on a CD) as the FRUC itself. The syntax of the lines containing the commands is as follows:
I will be releasing tools that you can use with the FRUC, as well as a list of tools/URLs that I would recommend. My current list of tools is available in chapter 5 of my book.
Registry Values
This section allows you to tell the FRUC which Registry values you're interested in. For example, you can use the Registry Reference spreadsheet posted on the SourceForge site to list specific Registry values of interest, and the FRUC will retrieve the data associated with those values. Please note the format used: a number designating the order of collection, and equals sign (=), the Registry key path (the hive can be abbreviated), a semi-colon, and the value name.
Registry Keys
This section allows you to designate the Registry keys that you would like to collect value names and data from. For example, you can put a reference to the ubiquitious Run key here, for both the HKLM and HKCU hives (using the correct path, of course). Whichever key you list, the FRUC will locate that key, and return the value names within that key and their data. The syntax for this section is simply a number designating the order, an equals sign, and the path to the key of interest. As with the Registry values, the hive can be abbreviated.
Note that throughout the INI file, comments are preceeded by semi-colons (ie, lines that begin with a semi-colon are ignored).
That's it. The INI file is pretty much just a script that tells the FRUC what to do, and in what order. The neat thing is that you can create and use multiple INI files, and even run an INI file from an alternate location...as long as the tools are on the CD/DVD along with the FRUC, you're golden.
The First Responder Utility , or FRUC (the "C" stands for "command line"), is intended to make data collection from systems more efficient. We accomplish this in part by minimizing the interaction that the first responder has with the system. Have you ever tried typing the same 5 commands over and over again? How about at 2:30am, when you've already been up for almost 24 hrs, and you're under pressure to get many more machines done? As you can well imagine, this can lead to mistakes, which can have disasterous results. So, why not sit down ahead of time, when you have the time and you're not tired, and decide what tools you want to run? Then, put those tools in the order you want to run them. That way, the tools you want to run get run for you, and are essentially self-documenting (more on that later).
I included a sample INI file with the FRUC archive, so you can follow along looking at that while I go through the components of the file. The INI file is a standard Windows ini file and consists of four sections:
Configuration
This section allows you to designate certain settings for the FRUC, specifically the server to connect to and the port. These settings are overridden by whatever you enter at the command line.
Commands
This section is very important. This is where you enter the commands you want to run on the system, in the order you want to run them. Each of the tools you want to run must be in the same directory (usually on a CD) as the FRUC itself. The syntax of the lines containing the commands is as follows:
- A number to designate the order you want to run the commands. Personally, I like to go sequentially, because its just easier to read
- An equals (=) sign
- The command line you want to run
- A double-colon (::) delimiter - this is important, as it separates the command you want to run from the file that will be created on the server to hold the output of the command. I ended up choosing a double-colon because tools like psloglist allow you to choose a delimiter such a semi-colon or even a colon as a delimiter for the output, and that would confuse the FRUC. Rather than using complicated logic to sort it out, I opted for something simpler.
- The name of the file you want the output to be placed in on the server. The FRUC will tell the FSPC to create a file based on this name, prepended by the system name. So, when I run the FRUC on my home system for testing, all of the files are prepended with "ENDER".
I will be releasing tools that you can use with the FRUC, as well as a list of tools/URLs that I would recommend. My current list of tools is available in chapter 5 of my book.
Registry Values
This section allows you to tell the FRUC which Registry values you're interested in. For example, you can use the Registry Reference spreadsheet posted on the SourceForge site to list specific Registry values of interest, and the FRUC will retrieve the data associated with those values. Please note the format used: a number designating the order of collection, and equals sign (=), the Registry key path (the hive can be abbreviated), a semi-colon, and the value name.
Registry Keys
This section allows you to designate the Registry keys that you would like to collect value names and data from. For example, you can put a reference to the ubiquitious Run key here, for both the HKLM and HKCU hives (using the correct path, of course). Whichever key you list, the FRUC will locate that key, and return the value names within that key and their data. The syntax for this section is simply a number designating the order, an equals sign, and the path to the key of interest. As with the Registry values, the hive can be abbreviated.
Note that throughout the INI file, comments are preceeded by semi-colons (ie, lines that begin with a semi-colon are ignored).
That's it. The INI file is pretty much just a script that tells the FRUC what to do, and in what order. The neat thing is that you can create and use multiple INI files, and even run an INI file from an alternate location...as long as the tools are on the CD/DVD along with the FRUC, you're golden.
Thursday, June 08, 2006
FSPC and FRUC posted
I've finally uploaded the FRUC v 1.2 (client component of the Forensic Server Project) and the FSPC 1.0c (server component of the Forensic Server Project) to my SourceForge site. These are vastly updated versions over what was included on the CD that accompanied my book.
Now, I'd like to take a moment to explain their use...
FSPC is the server component, which resides on your forensic workstation. This system will be where all of the data you collect is stored and managed, and then eventually analyzed. Getting started, type "fspc" or "fspc -h" at the command prompt and you'll see:
FSPC [-d case dir] [-n case name] [-p port] [-i investigator]
[-l logfile] [-c] [-v] [-h]
Forensic Server Project (CLI) v.1.0c, server component of the
Forensics Server Project
-d case dir....Case directory (default: cases)
-n case name...Name of the current case
-i invest......Investigator's name
-p port........Port to listen on (default: 7070)
-l logfile.....Case logfile (default: case.log)
-v.............Verbose output (more info, good for monitoring
activity)
-c.............Close FSP after CLOSELOG command sent (best used
when collecting data from only one system)
-h.............Help (print this information)
Ex: C:\>fspc -d cases -n testcase -i "H. Carvey"
C:\>fspc -n newcase -p 80
copyright 2006 H. Carvey
Most of what you see listed has default settings, as detailed in the syntax shown above. The easiest way to run the FSPC is using the first example. To see more information at the command prompt, add the "-v" switch.
The "-d", "-n", and "-i" switches are used primarily for case management. The "-d" switch is a subdirectory beneath the directory the FSPC resides in, and is the main holding area for information collected from systems. The "-n" switch is the name of an additional subdirectory where the case-specific files are kept. The "-i" switch is the name of the investigator (if spaces are included in the name, such as "keydet 89", then the name needs to be quotes) which is added to the case log file (denoted by the "-l" switch).
Finally, the "-p" switch tells the FSPC which port to listen on...the default is 7070.
FRUC is the client component, used to collect data from "victim" system. Download the zipped archive, and extract all of the files (2 EXE files and several DLLs) into a directory, add your third party tools, update your INI file (the default is "fruc.ini") appropriately, and then burn everything to a CD (or copy it to a thumb drive). Then you're ready.
Launch the FRUC with the "-h" switch and you'll see...
FRUC v 1.2 [-s server IP] [-p port] [-f ini file] [-h]
First Responder Utility (CLI) v.1.2, data collection utility
of the Forensics Server Project
-s system......IP address of Forensics Server
-p port........Port to connect to on the Forensics Server
-f file........Ini file to use (use other options to
override ini file configuration settings)
-v.............Verbose output (more info, good for monitoring
activity)
-h.............Help (print this information)
Ex: C:\>fruc -s -p -f
copyright 2004-2006 H. Carvey
As you can see from the syntax information, using FRUC is pretty simple. Many of the settings are set as defaults in the INI file (or can be), but those settings can also be overridden by the switches. For example, in the example INI file that ships with the archive, the default server IP address is set (as is the default port), but that can be overridden, as demonstrated by the example command line.
Okay...so here's what happens. FRUC is almost completely automated, minimizing the interaction that the first responder has with the program and the system. Besides efficiency and speed, FRUC also provides a modicum of validation, as commands do not have to be repetitively typed...if you're like me, this can lead to mistakes, forgotten commands, etc. So, basically, FRUC contacts the FSPC with a verb, telling the server what to expect. It then sends the output of the commands that are run to the server, where they are written to the server, hashed, and logged. Yes, the whole thing includes logging! And with timestamps!
The INI file for the FRUC has three main sections; external commands you want to run, specific Registry values you're interested in, and Registry keys that you just want to dump the values from. All this information is collected and shipped off to the FSPC over a socket, without writing to the local hard drive.
Each of these tools is provided as Perl source code, as well as a Windows compiled EXE. This is intended to make the FSP more accessible. Now, some folks have expressed concern about the use of Perl2Exe to "compile" tools such as this for use in an incident response (and potentially computer forensics) environment. If no switches or the "-small" switch are used when compiling the tools, additional modules are included in the resulting EXE and must be extracted to a temp directory before being used. Once your program has completed, the modules/DLLs are then deleted. This activity can be seen using tools like FileMon.
When I compiled FRUC, I used the "-tiny" switch, so that all required modules are "compiled" into DLLs that are separate from the main EXE. I've run FileMon in a few simple tests and found no Writes or Deletes. This help supports the tenet of computer forensics to minimize the impact on the "victim" system. However, I encourage you to run your own validation tests.
Please keep in mind, though, while doing your testing and using the tools in a live response situation, as well, that changes will be made to the system. These changes occur due to how the system and the shell react to programs being run; entries are added to several Registry keys (ie, UserAssist keys in particular), as well as files being added to the Prefetch directory on XP.
Another option is to not compile the tools at all, but instead install Perl on your system with all of the necessary modules, add the scripts, and then copy the entire installation to a CD. I outlined how to do this in my book. Again, though, I wanted to make this framework accessible.
Finally, in the spirit of "we eat our own dog food", I've used these tools (the FRUC is actually an updated version) myself and been very happy with the results. I do need to add an analysis suite, and that's something I'll be working on. Along with that, I'd like to post a more detailed user guide, as well as validation tests and results.
Your comments, questions, input and suggestions are always welcome.
Now, I'd like to take a moment to explain their use...
FSPC is the server component, which resides on your forensic workstation. This system will be where all of the data you collect is stored and managed, and then eventually analyzed. Getting started, type "fspc" or "fspc -h" at the command prompt and you'll see:
FSPC [-d case dir] [-n case name] [-p port] [-i investigator]
[-l logfile] [-c] [-v] [-h]
Forensic Server Project (CLI) v.1.0c, server component of the
Forensics Server Project
-d case dir....Case directory (default: cases)
-n case name...Name of the current case
-i invest......Investigator's name
-p port........Port to listen on (default: 7070)
-l logfile.....Case logfile (default: case.log)
-v.............Verbose output (more info, good for monitoring
activity)
-c.............Close FSP after CLOSELOG command sent (best used
when collecting data from only one system)
-h.............Help (print this information)
Ex: C:\>fspc -d cases -n testcase -i "H. Carvey"
C:\>fspc -n newcase -p 80
copyright 2006 H. Carvey
Most of what you see listed has default settings, as detailed in the syntax shown above. The easiest way to run the FSPC is using the first example. To see more information at the command prompt, add the "-v" switch.
The "-d", "-n", and "-i" switches are used primarily for case management. The "-d" switch is a subdirectory beneath the directory the FSPC resides in, and is the main holding area for information collected from systems. The "-n" switch is the name of an additional subdirectory where the case-specific files are kept. The "-i" switch is the name of the investigator (if spaces are included in the name, such as "keydet 89", then the name needs to be quotes) which is added to the case log file (denoted by the "-l" switch).
Finally, the "-p" switch tells the FSPC which port to listen on...the default is 7070.
FRUC is the client component, used to collect data from "victim" system. Download the zipped archive, and extract all of the files (2 EXE files and several DLLs) into a directory, add your third party tools, update your INI file (the default is "fruc.ini") appropriately, and then burn everything to a CD (or copy it to a thumb drive). Then you're ready.
Launch the FRUC with the "-h" switch and you'll see...
FRUC v 1.2 [-s server IP] [-p port] [-f ini file] [-h]
First Responder Utility (CLI) v.1.2, data collection utility
of the Forensics Server Project
-s system......IP address of Forensics Server
-p port........Port to connect to on the Forensics Server
-f file........Ini file to use (use other options to
override ini file configuration settings)
-v.............Verbose output (more info, good for monitoring
activity)
-h.............Help (print this information)
Ex: C:\>fruc -s -p -f
copyright 2004-2006 H. Carvey
As you can see from the syntax information, using FRUC is pretty simple. Many of the settings are set as defaults in the INI file (or can be), but those settings can also be overridden by the switches. For example, in the example INI file that ships with the archive, the default server IP address is set (as is the default port), but that can be overridden, as demonstrated by the example command line.
Okay...so here's what happens. FRUC is almost completely automated, minimizing the interaction that the first responder has with the program and the system. Besides efficiency and speed, FRUC also provides a modicum of validation, as commands do not have to be repetitively typed...if you're like me, this can lead to mistakes, forgotten commands, etc. So, basically, FRUC contacts the FSPC with a verb, telling the server what to expect. It then sends the output of the commands that are run to the server, where they are written to the server, hashed, and logged. Yes, the whole thing includes logging! And with timestamps!
The INI file for the FRUC has three main sections; external commands you want to run, specific Registry values you're interested in, and Registry keys that you just want to dump the values from. All this information is collected and shipped off to the FSPC over a socket, without writing to the local hard drive.
Each of these tools is provided as Perl source code, as well as a Windows compiled EXE. This is intended to make the FSP more accessible. Now, some folks have expressed concern about the use of Perl2Exe to "compile" tools such as this for use in an incident response (and potentially computer forensics) environment. If no switches or the "-small" switch are used when compiling the tools, additional modules are included in the resulting EXE and must be extracted to a temp directory before being used. Once your program has completed, the modules/DLLs are then deleted. This activity can be seen using tools like FileMon.
When I compiled FRUC, I used the "-tiny" switch, so that all required modules are "compiled" into DLLs that are separate from the main EXE. I've run FileMon in a few simple tests and found no Writes or Deletes. This help supports the tenet of computer forensics to minimize the impact on the "victim" system. However, I encourage you to run your own validation tests.
Please keep in mind, though, while doing your testing and using the tools in a live response situation, as well, that changes will be made to the system. These changes occur due to how the system and the shell react to programs being run; entries are added to several Registry keys (ie, UserAssist keys in particular), as well as files being added to the Prefetch directory on XP.
Another option is to not compile the tools at all, but instead install Perl on your system with all of the necessary modules, add the scripts, and then copy the entire installation to a CD. I outlined how to do this in my book. Again, though, I wanted to make this framework accessible.
Finally, in the spirit of "we eat our own dog food", I've used these tools (the FRUC is actually an updated version) myself and been very happy with the results. I do need to add an analysis suite, and that's something I'll be working on. Along with that, I'd like to post a more detailed user guide, as well as validation tests and results.
Your comments, questions, input and suggestions are always welcome.
Saturday, May 27, 2006
What's in YOUR wallet?
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.
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.
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)