I wanted to let everyone know that since October, I've been working on the second edition of this book, and I'm almost done with the initial rewrites. I'm finishing up chapter 4, Registry Analysis, now, and this is the last chapter that needs to go to the tech editor. Once this chapter has been sent off, I'll be going back to chapter 1 and addressing the tech editor's comments...the next stop is the publisher!
What's changed...a good deal of the original information is still in the book, but has been added to and in many cases expanded and brought up to date. For example, the binary structure of Registry hives and PE files haven't changed, so there's no reason to take any of that information out of the book...it's still pertinent. However, new tools are available, new techniques have been developed, and I've tried to highlight that in the additional information. In chapter 4, I focus primarily on RegRipper and rip.pl, rather than standalone scripts and tools. The standalone scripts and tools are still there, though...I moved them to another directory on the DVD.
I've also added two new chapters, not based on any specific requests, but rather upon things I've seen over time. Chapter 8 is "Tying It All Together", where I try to illustrate incidents I and others have responded to (in general terms, of course), and show how information from different chapters in the book get pulled together and correlated to create an overall picture of the incident or examination. Chapter 9 discusses getting a great deal of analysis capability out of freely available (in some cases, low cost) tools...the vast majority (albeit not all) of the tools discussed in this chapter were not brought up anywhere else in the book.
This time around, I've included more information about Vista, and while the recent release of Windows 7 Beta makes it too soon to really be included in the book, it does open the door for a third edition. ;-) Some other things that are on the DVD that accompanies the book (besides tools and other items referenced in the chapters) will be a number of PDFs I've written up over the past year or so to act as training manuals...each PDF addresses a single topic and is short enough to print out and take on a plane with you, or simply read at your leisure. I'm also including a document that shows, in detail, how to deploy F-Response EE remotely, and what physical memory from the remote system "looks like" to the analysis system.
From what the publisher tells me, this book should be out by May/June of this year, although it is already up on Amazon for pre-order.
Saturday, January 17, 2009
Sunday, January 11, 2009
Windows 7 Beta Registry
I've seen recently how folks have gotten access to the Windows 7 Beta for download from Microsoft, and being interested, I jumped right up on that bandwagon. I mean, from a forensic perspective, this "Jump List" thing is just going to be a gold mine for an analyst, much like RecentDocs and UserAssist keys have been since Windows 2000. Wikipedia has a nice write-up, and I look at all the great usability stuff that's talked about and all I can think of is "artifacts". ;-)
So, I took a look around to see if anyone was trying to install Windows 7 Beta into VMWare, and I ran across a Windows 7 Beta VM at TuxDistro. I fired up BitTorrent and downloaded the zipped archive, and then unzipped the VMDK file, and opened it in FTK Imager. Now, I saw a "Documents and Settings" directory, and a "Users" directory...so was this REALLY Windows 7?
Well, one question I heard a LOT when Vista came out was "what changed?" Was the Registry different enough that all of our current tools no longer worked? So, there's one way to find out! I dumped the hive files out of the VMDK file from their usual locations, including one called "Components". So I wanted to see if my tools worked, so I fired up rip.pl to see what I was working with:
C:\Perl\forensics\rr>rip.pl -r d:\cases\win7\software -p winnt_cv
Plugins Dir = C:\Perl\forensics\rr\plugins/
Launching winnt_cv v.20080609
WinNT_CV
Microsoft\Windows NT\CurrentVersion
LastWrite Time Fri Dec 12 18:26:31 2008 (UTC)
RegisteredOrganization :
CurrentVersion : 6.1
CurrentBuild : 6956
CurrentBuildNumber : 6956
SoftwareType : System
InstallationType : Client
EditionID : Ultimate
SystemRoot : C:\Windows
PathName : C:\Windows
ProductName : Windows 7 Ultimate
CurrentType : Multiprocessor Free
ProductId : 00428-015-8630506-70665
BuildLab : 6956.winmain.081122-1150
InstallDate : Fri Dec 12 20:52:50 2008 (UTC)
BuildLabEx : 6956.0.x86fre.winmain.081122-1150
Very cool! Not only do the tools seem to work just fine, but it looks as if the VMDK is a Windows 7 Beta VM. Very nice. Other plugins, such as samparse, seemed to work just fine, but parsing the UserAssist key in the NTUSER.DAT file was problematic...the "normal" GUID key didn't seem to be in the hive.
So, it would seem that the binary format of the Windows 7 (the Beta, anyway) Registry hive files has not changed. I'm sure that the content has, as keys have changed names and functionality, and values and ways of recording data have changed. However, as with the move from Windows 2000 to XP, there may simply be more opportunities for forensic analysts. I'll be interested to see who writes some of the first RegRipper plugins specific to Windows 7.
So, I took a look around to see if anyone was trying to install Windows 7 Beta into VMWare, and I ran across a Windows 7 Beta VM at TuxDistro. I fired up BitTorrent and downloaded the zipped archive, and then unzipped the VMDK file, and opened it in FTK Imager. Now, I saw a "Documents and Settings" directory, and a "Users" directory...so was this REALLY Windows 7?
Well, one question I heard a LOT when Vista came out was "what changed?" Was the Registry different enough that all of our current tools no longer worked? So, there's one way to find out! I dumped the hive files out of the VMDK file from their usual locations, including one called "Components". So I wanted to see if my tools worked, so I fired up rip.pl to see what I was working with:
C:\Perl\forensics\rr>rip.pl -r d:\cases\win7\software -p winnt_cv
Plugins Dir = C:\Perl\forensics\rr\plugins/
Launching winnt_cv v.20080609
WinNT_CV
Microsoft\Windows NT\CurrentVersion
LastWrite Time Fri Dec 12 18:26:31 2008 (UTC)
RegisteredOrganization :
CurrentVersion : 6.1
CurrentBuild : 6956
CurrentBuildNumber : 6956
SoftwareType : System
InstallationType : Client
EditionID : Ultimate
SystemRoot : C:\Windows
PathName : C:\Windows
ProductName : Windows 7 Ultimate
CurrentType : Multiprocessor Free
ProductId : 00428-015-8630506-70665
BuildLab : 6956.winmain.081122-1150
InstallDate : Fri Dec 12 20:52:50 2008 (UTC)
BuildLabEx : 6956.0.x86fre.winmain.081122-1150
Very cool! Not only do the tools seem to work just fine, but it looks as if the VMDK is a Windows 7 Beta VM. Very nice. Other plugins, such as samparse, seemed to work just fine, but parsing the UserAssist key in the NTUSER.DAT file was problematic...the "normal" GUID key didn't seem to be in the hive.
So, it would seem that the binary format of the Windows 7 (the Beta, anyway) Registry hive files has not changed. I'm sure that the content has, as keys have changed names and functionality, and values and ways of recording data have changed. However, as with the move from Windows 2000 to XP, there may simply be more opportunities for forensic analysts. I'll be interested to see who writes some of the first RegRipper plugins specific to Windows 7.
Friday, January 09, 2009
Got your YARA??
I ran across an interesting post yesterday on the Offensive Computing blog about YARA, a malware ID and classification framework. Interestingly enough, it ships for Linux, Windows, and as a version you can run via Python. The user manual that's available with YARA is short enough to be a quick read, and clear enough to give you a pretty good idea of how to get started using it.
Is anyone using it? How are you using it? The interesting thing is that YARA seems to use almost Snort-like rules for classifying files, which intuitively leads to some pretty incredible flexibility. For example, perhaps with some more detail as to where to look in files for some of these "signatures" and what different values can mean, YARA looks like a very good way to get one step ahead of AV products, even though we'd still be one step behind the malware itself. What a lot of folks are seeing these days is that their commercial grade AV products are capable of protecting themselves from variants A through F of a particular piece of malware, but then they get hit with variant G, or AB.
While YARA won't quarantine or delete the malware, it will help you classify it.
Another means of using YARA would be in conjuction with some of the new modules for Volatility that allow you to extract executable images from memory dumps. Extract the image, create a signature, and share it. You never know who else is using Volatility (or any of the other memory analysis tools) that may run across something similar.
Finally, I thought about perhaps turning YARA around and using it as means of going beyond file hashes. It's very hard to keep up with the latest versions of file hashes, particularly when so many things can change when MS releases patches. Using YARA, perhaps we can extend file signature analysis, and use this to perform data reduction...instead of asking for all "bad files" and relying on a perhaps incomplete list of rules, we could ask for all "good files" and then look at what's left over...
Thoughts?
Addendum: It looks like Jamie over at Mandiant is going to be doing something similar to Yara with Memoryze, by adding the ability to use Snort rules to detect malware in memory. Speaking of malware analysis, check out ZeroWine...this looks REALLY cool!
Is anyone using it? How are you using it? The interesting thing is that YARA seems to use almost Snort-like rules for classifying files, which intuitively leads to some pretty incredible flexibility. For example, perhaps with some more detail as to where to look in files for some of these "signatures" and what different values can mean, YARA looks like a very good way to get one step ahead of AV products, even though we'd still be one step behind the malware itself. What a lot of folks are seeing these days is that their commercial grade AV products are capable of protecting themselves from variants A through F of a particular piece of malware, but then they get hit with variant G, or AB.
While YARA won't quarantine or delete the malware, it will help you classify it.
Another means of using YARA would be in conjuction with some of the new modules for Volatility that allow you to extract executable images from memory dumps. Extract the image, create a signature, and share it. You never know who else is using Volatility (or any of the other memory analysis tools) that may run across something similar.
Finally, I thought about perhaps turning YARA around and using it as means of going beyond file hashes. It's very hard to keep up with the latest versions of file hashes, particularly when so many things can change when MS releases patches. Using YARA, perhaps we can extend file signature analysis, and use this to perform data reduction...instead of asking for all "bad files" and relying on a perhaps incomplete list of rules, we could ask for all "good files" and then look at what's left over...
Thoughts?
Addendum: It looks like Jamie over at Mandiant is going to be doing something similar to Yara with Memoryze, by adding the ability to use Snort rules to detect malware in memory. Speaking of malware analysis, check out ZeroWine...this looks REALLY cool!
Thursday, January 08, 2009
Solving problems with Perl
Many times, some problems just don't seem to have an obvious or easy solution. Take for instance some of the more recent malware to be seen, like Conficker (...and a rose by any other name would smell as sweet...)...it gets on your network, but initially isn't detected. That's because your AV product protects you from variants A through D, and what you've got on your network is a variant somewhere between F and P. Or let's just say you want to see if you do have something unusual on one of your systems. How would you do this?
Well, there are a number of ways you can do this, but if you look at the descriptions available for the Conficker malware, one of the commonalities you see is that it creates a Windows Service with a random name, which means that you can't just search for "Conficker" and hope to find it. Then the malware creates an ImagePath value that points to "svchost.exe -k netsvcs", which runs it when the system starts, but runs it as System level privileges. Also, note that a LOT of Services start this way, too. Then the malware creates a Parameters\ServiceDll value name that points to a randomly named DLL.
Interestingly, there's a number of bits of malware that use this same or a similar persistence mechanism. Okay, great. So, besides going to each machine individually, opening RegEdit, and clicking through the GUI, what do you do?
That's where Perl comes in! I ducked inside a telephone booth, pulled out my laptop and found some previously written code that accesses the live Registry in read-only mode. I then opened up one of my RegRipper plugins, grabbed a bit of already-written and -tested code, added it, shook it (one does NOT stir!), and presto! RegScan was born!
So here's what regscan does...you run it on your local system and it accesses the HKLM\System\CurrentControlSet\Services key, gets a list of subkeys, and then goes to each one and gets the LastWrite time, the ImagePath value (if there is one), the Parameters\ServiceDll value (if there is one), sorts everything by LastWrite time, and prints each Service entry on a single line with each element pipe ('|') separated. Okay, take a breath.
You run regscan like so:
C:\>regscan.pl
And you get a bunch of stuff like this:
Sat Jan 3 00:34:43 2009Z|WebClient|%SystemRoot%\system3\svchost.exe -k LocalService|%SystemRoot%\System32\webclnt.dll
Sat Jan 3 00:34:43 2009Z|winachsf|system32\DRIVERS\HSX_CNXT.sys||
Sat Jan 3 00:34:43 2009Z|Windows Workflow Foundation 3.0.0.0|||
Sat Jan 3 00:34:43 2009Z|winmgmt|%systemroot%\system32\svchost.exe -k netsvcs|%SystemRoot%\system32\wbem\WMIsvc.dll
Sat Jan 3 00:34:43 2009Z|Winsock||
Uh...okay. Well, this is command line, so to weed out some of the stuff you aren't interested in, you could type:
C:\>regscan.pl | find "svchost.exe -k netsvcs"
But wait...there's more! If you want to access remote systems (that you have admin access to, such as in your lab or in your corporate infrastructure), just type:
C:\>regscan.pl IP_address
...or...
C:\>regscan.pl System_name
Pretty cool, eh? And no, you don't need to have Perl running on the remote system. And yes, I've 'compiled' it into an EXE w/ Perl2Exe. And yes, it'll be included on the media that accompanies WFA 2/e. Oh, and it's also available for download at the RegRipper site, in the Downloads section. Enjoy!
Well, there are a number of ways you can do this, but if you look at the descriptions available for the Conficker malware, one of the commonalities you see is that it creates a Windows Service with a random name, which means that you can't just search for "Conficker" and hope to find it. Then the malware creates an ImagePath value that points to "svchost.exe -k netsvcs", which runs it when the system starts, but runs it as System level privileges. Also, note that a LOT of Services start this way, too. Then the malware creates a Parameters\ServiceDll value name that points to a randomly named DLL.
Interestingly, there's a number of bits of malware that use this same or a similar persistence mechanism. Okay, great. So, besides going to each machine individually, opening RegEdit, and clicking through the GUI, what do you do?
That's where Perl comes in! I ducked inside a telephone booth, pulled out my laptop and found some previously written code that accesses the live Registry in read-only mode. I then opened up one of my RegRipper plugins, grabbed a bit of already-written and -tested code, added it, shook it (one does NOT stir!), and presto! RegScan was born!
So here's what regscan does...you run it on your local system and it accesses the HKLM\System\CurrentControlSet\Services key, gets a list of subkeys, and then goes to each one and gets the LastWrite time, the ImagePath value (if there is one), the Parameters\ServiceDll value (if there is one), sorts everything by LastWrite time, and prints each Service entry on a single line with each element pipe ('|') separated. Okay, take a breath.
You run regscan like so:
C:\>regscan.pl
And you get a bunch of stuff like this:
Sat Jan 3 00:34:43 2009Z|WebClient|%SystemRoot%\system3\svchost.exe -k LocalService|%SystemRoot%\System32\webclnt.dll
Sat Jan 3 00:34:43 2009Z|winachsf|system32\DRIVERS\HSX_CNXT.sys||
Sat Jan 3 00:34:43 2009Z|Windows Workflow Foundation 3.0.0.0|||
Sat Jan 3 00:34:43 2009Z|winmgmt|%systemroot%\system32\svchost.exe -k netsvcs|%SystemRoot%\system32\wbem\WMIsvc.dll
Sat Jan 3 00:34:43 2009Z|Winsock||
Uh...okay. Well, this is command line, so to weed out some of the stuff you aren't interested in, you could type:
C:\>regscan.pl | find "svchost.exe -k netsvcs"
But wait...there's more! If you want to access remote systems (that you have admin access to, such as in your lab or in your corporate infrastructure), just type:
C:\>regscan.pl IP_address
...or...
C:\>regscan.pl System_name
Pretty cool, eh? And no, you don't need to have Perl running on the remote system. And yes, I've 'compiled' it into an EXE w/ Perl2Exe. And yes, it'll be included on the media that accompanies WFA 2/e. Oh, and it's also available for download at the RegRipper site, in the Downloads section. Enjoy!
Tuesday, January 06, 2009
Memory Collection and Analysis Tools
Recently, there was a post on the SANS Forensics blog about memory collection and analysis tools, but for some reason, it seems that folks are STILL having trouble with this process; I'm seeing posts in forums (forii??) saying that "...this tool doesn't work..." or "...that tool crashed when I tried to use it...". My suspicion is that the tools aren't being used correctly as folks may not understand their limitations.
Collection
I tend to separate collection and analysis...I've found that it's better to do each one right separately than it is to try to do both at the same time and split your resources.
XP/2003
There are a number of tools that allow for collection of physical memory on Windows XP and 2003 systems. The first and perhaps best known was a version of dd.exe modified by George M. Garner, Jr. This tool is no longer available, but it was used as the exemplar tool for collecting physical memory for the DFRWS 2005 Memory Challenge. Another tool is dcfldd.exe, written by Nick Harbour (currently with Mandiant). However, this blog post is one of several locations where it seems that someone's discovered that attempting to dump the \\.\PhysicalMemory object doesn't work, but dumping /dev/mem (yes, on Windows) appears to have an affect. Nigilant32 is a GUI-based tool that you can use to dump the contents of RAM, as well.
These tools are also available on the Helix CD. In addition, HBGary released their fastdump tool for dumping physical memory.
The delineation mark for the tools came with Windows 2003 SP1, as that's when MS removed user-mode access to the PhysicalMemory object. This, in turn, required a change in tools to collect physical memory.
2003 SP1 and Above
The tools used to collect the contents of physical memory for Windows 2003 SP1 and above (Vista) systems can also be used on XP and 2003 systems.
The first tool available to dump (and analyze) the contents of Physical Memory from Windows 2003 SP1 systems and above was the KntTools from George M. Garner, Jr. Then came ManTech's MDD, Matthieu Suiche's win32dd, GSI's winen (and winen64, for 64-bit systems), and Mandiant's Memoryze. All of these are great tools, but like any tool, each has it's strengths and weaknesses.
For example, right on the main page for the MDD tool, it states, "The software can copy up to 4 GB of memory to a file for later analysis." I'll leave it to smarter folks to tell you why, but I think that most tools have this same limitation. Matthieu's win32dd will dump memory in a raw, dd-style format as well as a crash dump-compatible format in case you'd like to use MS Debugger tools to analyze the dump. GSI's winen dumps memory in the EWF-style format (requires additional support for most tools to analyze). While most of the other tools download as an EXE, Memoryze downloads as an MSI file, and creates quite a footprint on the system.
One tool that must be mentione
d here is F-Response. By itself, F-Response does not provide the capability to dump the contents of physical memory, but the most recent version of F-Response provides you with remote, read-only access to physical memory on Windows systems; you can then use tools like FTK Imager, or any other acquisition tool (dd.exe, dcfldd.exe, etc.) to acquire your memory dump. The figure I've posted here shows what physical memory on a remote system "looks like" on your investigation system...in this example, it shows up as \\.\PhysicalDrive2, and can be accessed by tools such as FTK Imager. Go here to see how to install F-Response EE remotely on Windows systems.
All of these tools work best if tested and deployed before an incident occurs, before the tool itself is actually needed. Tools such as mdd.exe and win32dd.exe can be deployed on CD or a thumb drive, and F-Response can be deployed remotely (even in stealth mode) over the network, allowing you to accelerate your response.
Note: I don't want to leave out hibernation files. While I don't recommend hibernating a system as the default process for collecting the contents of physical memory, there may be times when its the only option. For example, if a system already has a hibernation file on it, IMHO, I'd prefer to use that file for historical analysis, to establish or validate a timeline of activity on the system. However, if the system is capable of hibernating, there may be times when forcing the system to hibernate may be the only way to collect the contents of physical memory. You can use powercfg.exe to configure the system to hibernate, and then use run32dll.exe to force it to hibernate.
Analysis
There are some frameworks available that provide a means of analysis on memory dumps from several versions of Windows, such as Andreas's PTFinder Collection. Andreas's Perl scripts are primarily used to list processes (and pool tags) from within Windows memory dumps.
About the only tools I can think of that provide more than what Andreas's scripts provide for analyzing Windows 2000 memory dumps are my own scripts, which are still available on SourceForge, as well as on the Windows Forensic Analysis DVD (and they will be provided on the DVD with the second edition of WFA).
When it comes to analyzing memory dumps from Windows XP SP2 and 3 systems for an incident response perspective, the Volatility Framework is the way to go. Yes, I know it's CLI, requires Python (which is free), but to be honest, this framework gives you unprecedented access to the contents of the memory dump. I say "contents" because not only can you get things like the active process list and active network connections at the time of the dump, but you can also run a linear scan through the dump for exited processes and expired network connections. The DFRWS 2008 Rodeo includes a memory dump you can try this out on. The output of the various commands can be easily redirected to files, and then correlated using Perl or Python scripts (such as vol2html.pl).
Volatility includes the capability of working with hibernation files (incorporating Matthieu's work; note that Matthieu has also released a standalone hibernation shell, in alpha) and crash dump-format memory dumps, in addition to the raw, dd-style format dumps. Also, Volatility is extensible, and others have taken the opportunity to create modules that can be easily installed and used with the framework (ie, Jesse Kornblum's cryptoscan and suspicious modules, and Moyix's Windows message queue module).
Addendum: I've recently seen the release of additional plugins; malfind from MNIN Security, and moddump from Moyix. I've gotta take a look at and try these plugins...man, it's it AWESOME the way Volatility can be extended??
Note: This is one of those places where I have seen folks say, "It doesn't work." As of now, Volatility works on XP SP 2 and 3 memory dumps. Please feel free to try it on other memory dumps, but as a courtesy, please refrain from stating "it doesn't work" (most of us already know that), as well as asking "why doesn't it work?" Thanks!
Mandiant's Memoryze is an XML-based tool that started life as part of the Mandiant Intelligent Response (MIR) product, and will allow you to collect and analyze memory dumps from Windows XP, 2003, and Vista systems. To install Memoryze, download the MSI file and the installation wizard will guide you through the process. Memoryze ships with a number of batch files that make it a bit more user-friendly, and Mandiant also include the Audit Viewer, a wxPython-based GUI tool that makes viewing the output of Memoryze a bit easier. Posts on the M-unition blog that describe how to use and extend Memoryze.
Also, please feel free to use tools such as strings or grep to extract information from memory dump files. However, keep in mind that if these tools are run against the entire dump file, the information you find may be without context. However, using any of the available tools to dump process memory for a memory dump file, and then searching it using strings/grep will provide you with a modicum of context.
It wouldn't be fair of me not to note HBGary's Responder product. I had an opportunity to try out the Responder Pro product a while ago, and found it be very useful for malware analysis. I haven't had an opportunity to try the Field edition.
Collection
I tend to separate collection and analysis...I've found that it's better to do each one right separately than it is to try to do both at the same time and split your resources.
XP/2003
There are a number of tools that allow for collection of physical memory on Windows XP and 2003 systems. The first and perhaps best known was a version of dd.exe modified by George M. Garner, Jr. This tool is no longer available, but it was used as the exemplar tool for collecting physical memory for the DFRWS 2005 Memory Challenge. Another tool is dcfldd.exe, written by Nick Harbour (currently with Mandiant). However, this blog post is one of several locations where it seems that someone's discovered that attempting to dump the \\.\PhysicalMemory object doesn't work, but dumping /dev/mem (yes, on Windows) appears to have an affect. Nigilant32 is a GUI-based tool that you can use to dump the contents of RAM, as well.
These tools are also available on the Helix CD. In addition, HBGary released their fastdump tool for dumping physical memory.
The delineation mark for the tools came with Windows 2003 SP1, as that's when MS removed user-mode access to the PhysicalMemory object. This, in turn, required a change in tools to collect physical memory.
2003 SP1 and Above
The tools used to collect the contents of physical memory for Windows 2003 SP1 and above (Vista) systems can also be used on XP and 2003 systems.
The first tool available to dump (and analyze) the contents of Physical Memory from Windows 2003 SP1 systems and above was the KntTools from George M. Garner, Jr. Then came ManTech's MDD, Matthieu Suiche's win32dd, GSI's winen (and winen64, for 64-bit systems), and Mandiant's Memoryze. All of these are great tools, but like any tool, each has it's strengths and weaknesses.
For example, right on the main page for the MDD tool, it states, "The software can copy up to 4 GB of memory to a file for later analysis." I'll leave it to smarter folks to tell you why, but I think that most tools have this same limitation. Matthieu's win32dd will dump memory in a raw, dd-style format as well as a crash dump-compatible format in case you'd like to use MS Debugger tools to analyze the dump. GSI's winen dumps memory in the EWF-style format (requires additional support for most tools to analyze). While most of the other tools download as an EXE, Memoryze downloads as an MSI file, and creates quite a footprint on the system.
One tool that must be mentione
d here is F-Response. By itself, F-Response does not provide the capability to dump the contents of physical memory, but the most recent version of F-Response provides you with remote, read-only access to physical memory on Windows systems; you can then use tools like FTK Imager, or any other acquisition tool (dd.exe, dcfldd.exe, etc.) to acquire your memory dump. The figure I've posted here shows what physical memory on a remote system "looks like" on your investigation system...in this example, it shows up as \\.\PhysicalDrive2, and can be accessed by tools such as FTK Imager. Go here to see how to install F-Response EE remotely on Windows systems.All of these tools work best if tested and deployed before an incident occurs, before the tool itself is actually needed. Tools such as mdd.exe and win32dd.exe can be deployed on CD or a thumb drive, and F-Response can be deployed remotely (even in stealth mode) over the network, allowing you to accelerate your response.
Note: I don't want to leave out hibernation files. While I don't recommend hibernating a system as the default process for collecting the contents of physical memory, there may be times when its the only option. For example, if a system already has a hibernation file on it, IMHO, I'd prefer to use that file for historical analysis, to establish or validate a timeline of activity on the system. However, if the system is capable of hibernating, there may be times when forcing the system to hibernate may be the only way to collect the contents of physical memory. You can use powercfg.exe to configure the system to hibernate, and then use run32dll.exe to force it to hibernate.
Analysis
There are some frameworks available that provide a means of analysis on memory dumps from several versions of Windows, such as Andreas's PTFinder Collection. Andreas's Perl scripts are primarily used to list processes (and pool tags) from within Windows memory dumps.
About the only tools I can think of that provide more than what Andreas's scripts provide for analyzing Windows 2000 memory dumps are my own scripts, which are still available on SourceForge, as well as on the Windows Forensic Analysis DVD (and they will be provided on the DVD with the second edition of WFA).
When it comes to analyzing memory dumps from Windows XP SP2 and 3 systems for an incident response perspective, the Volatility Framework is the way to go. Yes, I know it's CLI, requires Python (which is free), but to be honest, this framework gives you unprecedented access to the contents of the memory dump. I say "contents" because not only can you get things like the active process list and active network connections at the time of the dump, but you can also run a linear scan through the dump for exited processes and expired network connections. The DFRWS 2008 Rodeo includes a memory dump you can try this out on. The output of the various commands can be easily redirected to files, and then correlated using Perl or Python scripts (such as vol2html.pl).
Volatility includes the capability of working with hibernation files (incorporating Matthieu's work; note that Matthieu has also released a standalone hibernation shell, in alpha) and crash dump-format memory dumps, in addition to the raw, dd-style format dumps. Also, Volatility is extensible, and others have taken the opportunity to create modules that can be easily installed and used with the framework (ie, Jesse Kornblum's cryptoscan and suspicious modules, and Moyix's Windows message queue module).
Addendum: I've recently seen the release of additional plugins; malfind from MNIN Security, and moddump from Moyix. I've gotta take a look at and try these plugins...man, it's it AWESOME the way Volatility can be extended??
Note: This is one of those places where I have seen folks say, "It doesn't work." As of now, Volatility works on XP SP 2 and 3 memory dumps. Please feel free to try it on other memory dumps, but as a courtesy, please refrain from stating "it doesn't work" (most of us already know that), as well as asking "why doesn't it work?" Thanks!
Mandiant's Memoryze is an XML-based tool that started life as part of the Mandiant Intelligent Response (MIR) product, and will allow you to collect and analyze memory dumps from Windows XP, 2003, and Vista systems. To install Memoryze, download the MSI file and the installation wizard will guide you through the process. Memoryze ships with a number of batch files that make it a bit more user-friendly, and Mandiant also include the Audit Viewer, a wxPython-based GUI tool that makes viewing the output of Memoryze a bit easier. Posts on the M-unition blog that describe how to use and extend Memoryze.
Also, please feel free to use tools such as strings or grep to extract information from memory dump files. However, keep in mind that if these tools are run against the entire dump file, the information you find may be without context. However, using any of the available tools to dump process memory for a memory dump file, and then searching it using strings/grep will provide you with a modicum of context.
It wouldn't be fair of me not to note HBGary's Responder product. I had an opportunity to try out the Responder Pro product a while ago, and found it be very useful for malware analysis. I haven't had an opportunity to try the Field edition.
Monday, January 05, 2009
Characteristics of Effective Incident Response
The Need
There is a need for effective incident response, now more than ever. However, the key to incident response is incident preparedness. Responding without being prepared to respond correctly is what turns an incident into a major data breach and a major embarrassment.
Addendum: If you don't think incidents are going to happen, or that they aren't going to happen to you, take a look at this SecurityFix post from Brian Krebs. To be clear, the very first sentence says "reported"...which perhaps indicates a subset of what was actually detected.
There are three primary characteristics of effective incident response, and knowing and understanding these lead to being better prepared to respond to incidents:
1. Completeness of Data
When I am called to respond to an incident, there are four sources of data I will generally look for, to some degree, regardless of the type of incident:
- Network traffic captures
- Logs from network devices (firewalls, routers, etc.)
- Host-based volatile data
- Host-based non-volatile data
Now, you may not need data from every source for every incident, and the value of the data from these sources may vary depending upon the incident. In all the time I've been doing IR, in various capacities, I can't recall a single time when I've had all four sources of data available...in fact, in most cases, I'm lucky to get one, and it's a miracle to have two.
2. Accuracy of Data
How accurate the data is in many cases can depend upon what it is you're actually trying to do. For example, capturing portions of volatile memory using a batch file and third party tools (ie, tlist.exe, tcpvcon.exe, etc.) to get the list of active processes, network connections, etc., may be accurate enough for your needs. However, in other instances, collecting the full contents of physical memory may be the only means of achieving accuracy (and completeness) of data.
3. Temporal proximity
This is a term I borrowed from Aaron Walters (of Volatility fame), not because it's cool and Star Trek-y sounding, but because it makes perfect sense. The sooner you begin responding to an incident, the more complete and accurate data you're going to get, and your overall response is going to be more effective and lead to better remediation, etc.
Since this field is wrought with analogies, let's try this one...as a homeowner, do you have smoke detectors in your home? How about fire extinguishers? I do. How about insurance? When you called for your insurance, did the insurance company ask how far you are from the nearest hydrant? How about from the nearest fire department? Did you get a home inspection prior to purchasing your home? Is it up to code with respect to exits, etc? Do you know what to do in case of a grease fire in your kitchen?
So, your home is full of valuables, in particular, your family. If your home were to catch fire, what would you do? First off, how would you know? Then, once you knew, what would you do? Would you just wait until the house burned down to call the fire department?
Now, map your home to your network infrastructure, and a fire to a data breach. Where are your valuables? Do you have a detection mechanism? Are you able to respond immediately and correctly to a grease fire?
This example shows, in part, that temporal proximity plays an important role in incident response, but it also highlights the need for approaching it the right way, which may include training. So what does this mean for the coming year? Well, it should mean that training will be more important than ever. Think about it. If a small fire starts in your house, would you (a) wait for an hour, then call the fire department, (b) wait for the house to burn down completely, or (c) begin putting the fire out yourself immediately? With respect to computer security incidents, who is in a better position to respond immediately...the sysadmin who is currently logged into the console, or an responder such as myself who is 24-48 hrs away from being on-site? Not only is the sysadmin there, but she more than likely knows the systems and the architecture very well; an external responder such as myself is going to have to get up to speed on your architecture, and even then won't have all of the little nuances.
This is all fine and good, but as Lon Solomon is fond of saying, "so what?" The fact is that many organizations simply don't put any effort or resources into their response plan because they feel that there's no requirement to do so.
External Forces
I'm not going to make a prediction for the future, but the primary drivers for incident response in 2009 (and beyond) will continue to be external forces; specifically, legislative and regulatory compliance requirements. Why is that? Because they have to be. After all, most of us think that if someone is making a business out of storing and/or processing our sensitive (PII, PHI, PCI) data, then of course they'll do everything they can to protect and secure that data. I mean, why wouldn't they, right? After all, if a buddy wants you to hold $50 for him, or the ring he's going to present his bride at their wedding, then you're going to do everything you can to protect that data, right? For many of us, this is just what we think of as common sense, but that's sadly not the case with your sensitive data. Look here, or here. And things only start to change when some external forces come into play, and those forces are strong enough to act as the stimulus to cause that change...those external forces being legal (think CA SB-1386, etc.) or regulatory compliance (think HIPAA, Visa PCI, etc.) requirements.
There is a need for effective incident response, now more than ever. However, the key to incident response is incident preparedness. Responding without being prepared to respond correctly is what turns an incident into a major data breach and a major embarrassment.
Addendum: If you don't think incidents are going to happen, or that they aren't going to happen to you, take a look at this SecurityFix post from Brian Krebs. To be clear, the very first sentence says "reported"...which perhaps indicates a subset of what was actually detected.
There are three primary characteristics of effective incident response, and knowing and understanding these lead to being better prepared to respond to incidents:
1. Completeness of Data
When I am called to respond to an incident, there are four sources of data I will generally look for, to some degree, regardless of the type of incident:
- Network traffic captures
- Logs from network devices (firewalls, routers, etc.)
- Host-based volatile data
- Host-based non-volatile data
Now, you may not need data from every source for every incident, and the value of the data from these sources may vary depending upon the incident. In all the time I've been doing IR, in various capacities, I can't recall a single time when I've had all four sources of data available...in fact, in most cases, I'm lucky to get one, and it's a miracle to have two.
2. Accuracy of Data
How accurate the data is in many cases can depend upon what it is you're actually trying to do. For example, capturing portions of volatile memory using a batch file and third party tools (ie, tlist.exe, tcpvcon.exe, etc.) to get the list of active processes, network connections, etc., may be accurate enough for your needs. However, in other instances, collecting the full contents of physical memory may be the only means of achieving accuracy (and completeness) of data.
3. Temporal proximity
This is a term I borrowed from Aaron Walters (of Volatility fame), not because it's cool and Star Trek-y sounding, but because it makes perfect sense. The sooner you begin responding to an incident, the more complete and accurate data you're going to get, and your overall response is going to be more effective and lead to better remediation, etc.
Since this field is wrought with analogies, let's try this one...as a homeowner, do you have smoke detectors in your home? How about fire extinguishers? I do. How about insurance? When you called for your insurance, did the insurance company ask how far you are from the nearest hydrant? How about from the nearest fire department? Did you get a home inspection prior to purchasing your home? Is it up to code with respect to exits, etc? Do you know what to do in case of a grease fire in your kitchen?
So, your home is full of valuables, in particular, your family. If your home were to catch fire, what would you do? First off, how would you know? Then, once you knew, what would you do? Would you just wait until the house burned down to call the fire department?
Now, map your home to your network infrastructure, and a fire to a data breach. Where are your valuables? Do you have a detection mechanism? Are you able to respond immediately and correctly to a grease fire?
This example shows, in part, that temporal proximity plays an important role in incident response, but it also highlights the need for approaching it the right way, which may include training. So what does this mean for the coming year? Well, it should mean that training will be more important than ever. Think about it. If a small fire starts in your house, would you (a) wait for an hour, then call the fire department, (b) wait for the house to burn down completely, or (c) begin putting the fire out yourself immediately? With respect to computer security incidents, who is in a better position to respond immediately...the sysadmin who is currently logged into the console, or an responder such as myself who is 24-48 hrs away from being on-site? Not only is the sysadmin there, but she more than likely knows the systems and the architecture very well; an external responder such as myself is going to have to get up to speed on your architecture, and even then won't have all of the little nuances.
This is all fine and good, but as Lon Solomon is fond of saying, "so what?" The fact is that many organizations simply don't put any effort or resources into their response plan because they feel that there's no requirement to do so.
External Forces
I'm not going to make a prediction for the future, but the primary drivers for incident response in 2009 (and beyond) will continue to be external forces; specifically, legislative and regulatory compliance requirements. Why is that? Because they have to be. After all, most of us think that if someone is making a business out of storing and/or processing our sensitive (PII, PHI, PCI) data, then of course they'll do everything they can to protect and secure that data. I mean, why wouldn't they, right? After all, if a buddy wants you to hold $50 for him, or the ring he's going to present his bride at their wedding, then you're going to do everything you can to protect that data, right? For many of us, this is just what we think of as common sense, but that's sadly not the case with your sensitive data. Look here, or here. And things only start to change when some external forces come into play, and those forces are strong enough to act as the stimulus to cause that change...those external forces being legal (think CA SB-1386, etc.) or regulatory compliance (think HIPAA, Visa PCI, etc.) requirements.
Saturday, January 03, 2009
First Post of 2009
Just a couple of things for my first post of 2009...
It seems that RegRipper is catching on, if this post about Enhancing RegRipper is any indication. I have some comments on the post, and the author has responded.
Christina has updated the eEvidence site again, just before the New Year...as always, there are some very promising links...
What 2009 holds...
Not resolutions or predictions, but for 2009, I'd like to do more development on RegRipper, as well as integrate all of my tools into a timeline framework, extending the work of others (Brian Carrier w/ TSK, Michael Cloppert w/ ex-tip, etc.)
Work is progressing on WFA 2/e...I'm currently finishing up chapter 3, and once I get that turned in to my editor, I'll try to get some rewrites done, but I still have one chapter...Registry Analysis...still left to do and get in for review.
It seems that RegRipper is catching on, if this post about Enhancing RegRipper is any indication. I have some comments on the post, and the author has responded.
Christina has updated the eEvidence site again, just before the New Year...as always, there are some very promising links...
What 2009 holds...
Not resolutions or predictions, but for 2009, I'd like to do more development on RegRipper, as well as integrate all of my tools into a timeline framework, extending the work of others (Brian Carrier w/ TSK, Michael Cloppert w/ ex-tip, etc.)
Work is progressing on WFA 2/e...I'm currently finishing up chapter 3, and once I get that turned in to my editor, I'll try to get some rewrites done, but I still have one chapter...Registry Analysis...still left to do and get in for review.
Wednesday, December 24, 2008
Flippin' Sweet!!
I found out today that WFA 2/e is available on Amazon for pre-order! Publisher's info here.
Monday, December 22, 2008
Using RegRipper
Ever wonder how to use RegRipper for analysis? After all, the tool pulls data from Registry hive files, and while there is a considerable amount of data reduction, what do you do with the data you get?
Let's look at an example. Say that you've got an issue going on with some systems, and you (a) acquire an image of a system, (b) use FTK Imager to get copies of just the Registry hive files from a live system, or (c) connect to the system via F-Response...at that point, you run RegRipper, or just rip.exe with one of the plugins to extract information from the Services key in the System hive file. If you happen to see Ndisprot listed as a service, you may have found a Trojan.Flush.M infection.
*Note: Trojan.Flush.M is apparently also known as "DNSChanger", and this blog post refers to some excellent resources for checking your network for rogue DHCP servers, including MS's own dhcploc utility.
Also, RegRipper can be used to check for the existence of patches and updates, such as KB958644, which addresses the Server service vulnerability from MS08-067.
Check out the RegRipper.net forums for some new plugins uploaded by Don Weber.
How do you use RegRipper?
Let's look at an example. Say that you've got an issue going on with some systems, and you (a) acquire an image of a system, (b) use FTK Imager to get copies of just the Registry hive files from a live system, or (c) connect to the system via F-Response...at that point, you run RegRipper, or just rip.exe with one of the plugins to extract information from the Services key in the System hive file. If you happen to see Ndisprot listed as a service, you may have found a Trojan.Flush.M infection.
*Note: Trojan.Flush.M is apparently also known as "DNSChanger", and this blog post refers to some excellent resources for checking your network for rogue DHCP servers, including MS's own dhcploc utility.
Also, RegRipper can be used to check for the existence of patches and updates, such as KB958644, which addresses the Server service vulnerability from MS08-067.
Check out the RegRipper.net forums for some new plugins uploaded by Don Weber.
How do you use RegRipper?
Saturday, December 20, 2008
Some Good Reading...
I wanted to post some interesting items I've run across and read recently...
Brian Krebs wrote an excellent article that appeared on the cover of Popular Mechanics entitled "When Hackers Attack". Page 2 of the article discusses data trafficking, which is very timely as Brian has also blogged on that topic recently.
Brett Shavers has a PDF document up called Virtual Machine Forensic Analysis, which is another excellent read and full of valuable information whether you're analyzing a virtual machine for intrusion or compromise, or as part of a malware analysis process.
For a wider range of reading, Christina's updated the eEvidence site recently; she's always posted links to some very valuable articles, presentations, and other resources.
Brian Krebs wrote an excellent article that appeared on the cover of Popular Mechanics entitled "When Hackers Attack". Page 2 of the article discusses data trafficking, which is very timely as Brian has also blogged on that topic recently.
Brett Shavers has a PDF document up called Virtual Machine Forensic Analysis, which is another excellent read and full of valuable information whether you're analyzing a virtual machine for intrusion or compromise, or as part of a malware analysis process.
For a wider range of reading, Christina's updated the eEvidence site recently; she's always posted links to some very valuable articles, presentations, and other resources.
Perl Module Updated!
Just in time from Christmas, James MacFarlane has give us some Perly goodness! James has updated Parse::Win32Registry to version 0.41! The update appears to be to get key classnames, and is demonstrated in an additional script that James has provided as part of the distro.
James has done a fantastic job with this module, making so much of what I and others do possible with respect to forensic analysis. For example, just last night, a friend of mine sent me three RegRipper plugins that he's going to be posting on RegRipper.net. While I can't say that RegRipper would not have been possible without James' module, I can definitely say that it wouldn't be in the state its in now without it.
Thanks, James!
James has done a fantastic job with this module, making so much of what I and others do possible with respect to forensic analysis. For example, just last night, a friend of mine sent me three RegRipper plugins that he's going to be posting on RegRipper.net. While I can't say that RegRipper would not have been possible without James' module, I can definitely say that it wouldn't be in the state its in now without it.
Thanks, James!
Thursday, December 18, 2008
RegRipper
RegRipper made the SANS Forensics blog today in a post by John McCash about Windows viewers. Pretty cool stuff! John has deployed RegRipper (actually, rip) in a manner that I hadn't even considered when I wrote it...by launching rip as a viewer via EnCase. Very cool!
How're YOU using RegRipper? Have a plugin you'd like to share? Have a plugin you'd like to see? If you don't feel that your programming skills are up to the job, then all I've ever asked for is a concise description of what you're looking for, and a sample hive file. For stuff like the ShellBags keys or encrypted data, I'll need some formatting or decryption information.
Addendum: Don Weber posted three new RegRipper plugins to the RegRipper.net forums...
How're YOU using RegRipper? Have a plugin you'd like to share? Have a plugin you'd like to see? If you don't feel that your programming skills are up to the job, then all I've ever asked for is a concise description of what you're looking for, and a sample hive file. For stuff like the ShellBags keys or encrypted data, I'll need some formatting or decryption information.
Addendum: Don Weber posted three new RegRipper plugins to the RegRipper.net forums...
Less blogging, more writing
There's likely a noticeable slow-down in posts to this blog, and that will continue, as I'm working on the second edition of Windows Forensic Analysis right now.
2/e is expanding on the first edition by not only updating/adding information to the existing chapters, but also adding two additional chapters; Tying It All Together, as well as one that presents more freely available tools.
2/e should be available around May or June 2009, and thanks, but I already have a tech editor. ;-)
2/e is expanding on the first edition by not only updating/adding information to the existing chapters, but also adding two additional chapters; Tying It All Together, as well as one that presents more freely available tools.
2/e should be available around May or June 2009, and thanks, but I already have a tech editor. ;-)
Saturday, December 06, 2008
Windows Hibernation files
Matthieu has made his Exploiting Windows Hibernation File presentation available...for anyone interested at all in Windows memory analysis, his presentation is well worth a look. Matthieu is the first person that I'm aware of to come up with a means of exploiting or taking advantage of the hibernation file as a viable source of data, and is a contributor to the Volatility framework. Other presentations and demos can be found here.
Issues with AV
I noticed Hogfly's been blogging lately about issues with AV, here and here. It's some good stuff, and I think bears repeating...AV is NOT a silver bullet, and I think most of us are really very well aware of that.
A while back, I commented about an issue presented by AV company write-ups providing incorrect information; in this case, identifying a Registry entry that was created not directly by the malware itself, but by the shell as a result of how the malware was launched on the system. Given the level of technical ability of many malware analysts, you'd think it would be an easy catch.
Well, I ran across this one at the MS Malware Protection Center Encyclopedia this morning - malware identified as Win32/Autorun.GR, and yet the write up (as of this morning) gives no indication of any sort of autorun capability, via a Registry setting or otherwise. Ag;ain, as of this morning (6 Dec), the description simply states that the malware writes itself to the root of all available drives; however, there's no description or discussion whatsoever of why this malware is referred to as "autorun". Yeah, yeah, I know that the Technical Details state that additional info is pending analysis, but if you're gonna call it "autorun", shouldn't there be a reason for that? After all, if the files are just written to the root of the drive without any other means of initiation, wouldn't that then be something like "Win32/Usersgottaclickme.GR"??
On the other hand, VirusList has a good write up on AutoRun.ah which pretty clearly states where the autorun capability comes from. At least from this write up, you can pretty clearly see the steps you need to take to prevent this malware from affecting your infrastructure.
The more information you can get, the better prepared you can be to address the threat. I know that on the surface, to many, the issue of viruses and malware seems pretty pedestrian, but to be honest, there are a number of organizations out there that get pretty badly hung up by viruses (not even worms) and other similar issues.
A while back, I commented about an issue presented by AV company write-ups providing incorrect information; in this case, identifying a Registry entry that was created not directly by the malware itself, but by the shell as a result of how the malware was launched on the system. Given the level of technical ability of many malware analysts, you'd think it would be an easy catch.
Well, I ran across this one at the MS Malware Protection Center Encyclopedia this morning - malware identified as Win32/Autorun.GR, and yet the write up (as of this morning) gives no indication of any sort of autorun capability, via a Registry setting or otherwise. Ag;ain, as of this morning (6 Dec), the description simply states that the malware writes itself to the root of all available drives; however, there's no description or discussion whatsoever of why this malware is referred to as "autorun". Yeah, yeah, I know that the Technical Details state that additional info is pending analysis, but if you're gonna call it "autorun", shouldn't there be a reason for that? After all, if the files are just written to the root of the drive without any other means of initiation, wouldn't that then be something like "Win32/Usersgottaclickme.GR"??
On the other hand, VirusList has a good write up on AutoRun.ah which pretty clearly states where the autorun capability comes from. At least from this write up, you can pretty clearly see the steps you need to take to prevent this malware from affecting your infrastructure.
The more information you can get, the better prepared you can be to address the threat. I know that on the surface, to many, the issue of viruses and malware seems pretty pedestrian, but to be honest, there are a number of organizations out there that get pretty badly hung up by viruses (not even worms) and other similar issues.
Friday, December 05, 2008
Honor Thy Settings
Some of us have been working with the Sality virus lately, which reportedly propagates by writing an autorun.inf file and an executable file to the root of all volumes or drives found on the infected system. If the user workstation maps to a file share, for example, the virus process writes the files to the volume, and anyone else that then connects to that share also gets infected. The same has been shown to be true for removable storage, such as USB thumb or flash drives.So when working with analysts and customers, most of us tend to recommend disabling autorun capability all together, or perhaps for specific drives. Usually this is good advice, but only if it works. MS recently published this KB article which basically states that previous advice didn't work, and you need to install an update AND set another Registry value (ie, HonorAutorunSetting) for the functionality that you set to actually work.
Is this really such an important issue? Well, given stuff like this, and this...perhaps. Update your systems, and recommend that your friends and customers do the same. Even Symantec has picked this up.
Sunday, November 30, 2008
Changing the Face of IR
Major corporations handle our sensitive data...referred to as PII, PHI, PCI. Sometimes, they don't do such a great job of securing and protecting that data. The Dept of Veterans Affairs. TJX. World Bank. IMF. The list goes on. Data breaches happen...there's no question about that. If they didn't, guys and gals like me would be out of jobs.
Historically, the stimulus for change with respect to infosec (particularly with respect to IR) has been external to organizations. An attack or major breach stimulates some change, but its not long lived...once the panic wears off, executive management fails to see ROI from the resources that were suddenly (re: knee-jerk reaction) invested. According to Richard Bejtlich and others, there is no ROI from security...not directly anyway.
Legislation and regulation...with consequences...has a more lasting effect. Visa's PCI defines "compliance", which while not being what most of would consider "security", is at least a step in right direction. There are other regulatory/oversight bodies that provide their own guidelines...NCUA, HIPAA, etc. Section 748.2 of the NCUA Regulations provides guidance on "response programs". The PCI DSS (paragraph 12.9) provides compliance standards for an incident response plan.
Every organization with employees has a payroll process. Why? Well, without it, employees wouldn't get paid, and we all know that the CEO has to get paid, right? And oh, yeah...if you don't pay your employees, they don't come to work...you know where this one is heading. Many organizations have disaster recovery and business continuity plans, backup systems, etc. But why do some organizations not have computer security incident response plans, even when some regulatory body tells them that they need to have one?
Regulatory body definitions of "sensitive data" aside, what about corporations that loose intellectual property (IP)? Did you read this 12 Nov article in USAToday (additional commentary on the story at TaoSecurity)? Many organizations subsist primarily on their IP...remember Ira Winkler's Corporate Espionage?
The Verizon Business Security group put together some interesting statistics in their 2008 Data Breach Investigations Report; for example:
83% of attacks were not "highly difficult" (re: low-hanging fruit)
85% of attacks were opportunistic (re: "hey, look...someone left their keys in their car...")
87% of attacks could have been avoided with reasonable security controls
66% of breaches involved data the victim did not know was on the system
Perhaps one of the most interesting and revealing statistics was that reportedly 75% of breaches were not discovered by the victim. What this means is that data from within those organizations network infrastructure was compromised and exposed, and the breached organization had no idea until someone told them.
So, if its not enough that some regulatory oversight body requires you to have an incident response plan, how about the inevitability of an incident occurring? What's it gonna take for organizations to plan for an incident occurring, rather than reacting (poorly) after one has occurred? Oddly enough, any change in this regard with have nothing whatsoever to do with the victim "doing the right thing", and has everything to do with legislation and regulatory oversight.
Historically, the stimulus for change with respect to infosec (particularly with respect to IR) has been external to organizations. An attack or major breach stimulates some change, but its not long lived...once the panic wears off, executive management fails to see ROI from the resources that were suddenly (re: knee-jerk reaction) invested. According to Richard Bejtlich and others, there is no ROI from security...not directly anyway.
Legislation and regulation...with consequences...has a more lasting effect. Visa's PCI defines "compliance", which while not being what most of would consider "security", is at least a step in right direction. There are other regulatory/oversight bodies that provide their own guidelines...NCUA, HIPAA, etc. Section 748.2 of the NCUA Regulations provides guidance on "response programs". The PCI DSS (paragraph 12.9) provides compliance standards for an incident response plan.
Every organization with employees has a payroll process. Why? Well, without it, employees wouldn't get paid, and we all know that the CEO has to get paid, right? And oh, yeah...if you don't pay your employees, they don't come to work...you know where this one is heading. Many organizations have disaster recovery and business continuity plans, backup systems, etc. But why do some organizations not have computer security incident response plans, even when some regulatory body tells them that they need to have one?
Regulatory body definitions of "sensitive data" aside, what about corporations that loose intellectual property (IP)? Did you read this 12 Nov article in USAToday (additional commentary on the story at TaoSecurity)? Many organizations subsist primarily on their IP...remember Ira Winkler's Corporate Espionage?
The Verizon Business Security group put together some interesting statistics in their 2008 Data Breach Investigations Report; for example:
83% of attacks were not "highly difficult" (re: low-hanging fruit)
85% of attacks were opportunistic (re: "hey, look...someone left their keys in their car...")
87% of attacks could have been avoided with reasonable security controls
66% of breaches involved data the victim did not know was on the system
Perhaps one of the most interesting and revealing statistics was that reportedly 75% of breaches were not discovered by the victim. What this means is that data from within those organizations network infrastructure was compromised and exposed, and the breached organization had no idea until someone told them.
So, if its not enough that some regulatory oversight body requires you to have an incident response plan, how about the inevitability of an incident occurring? What's it gonna take for organizations to plan for an incident occurring, rather than reacting (poorly) after one has occurred? Oddly enough, any change in this regard with have nothing whatsoever to do with the victim "doing the right thing", and has everything to do with legislation and regulatory oversight.
Monday, November 24, 2008
IR Preparedness
As a responder, I often hear two reasons for folks calling for help after a breach has occurred (aside from the rather obvious one, that is) - the caller either wants to be sure that they're performing "due diligence", or they're interested in bringing in a disinterested third party to have a look at things.
Every now and then when I get a chance to sit back and reflect, something strikes me. Most often those things were right there in front of me all along, and I just never noticed them. Things like these reasons that people give me.
Take for example the reason of "due diligence". It occurs to me that if someone were really interested in performing due diligence, they would've called me before the incident occurred, to ensure that they were prepared to handle an incident. Closing the barn door and shutting the stall doors after the horse has left is not "due diligence".
What about the "disinterested third party"? If you call a consulting company to come help you contain and recover from an incident, the fact that you're paying them obviates the "disinterested" part of the description, doesn't it?
Many times, folks at an organization looking for assistance after an incident has been detected will say that they want an outside firm to handle the examination in case the issue ends up going to court. But what's the real difference between the victim organization performing the investigation and an outside firm doing so? The outside firm most often has a documented process, or at the very least documents what they did in their report.
The primary reason that consulting companies are called when an incident occurs is that the organization was simply unprepared for an incident. Regardless of legislative or regulatory requirements, they're simply unprepared.
This is not to say that when an incident occurs, you should not call someone for assistance. Rather, I'm reiterating my response from the SANS Forensic Summit panel when Rob Lee asked the panel members about response time to a call...my response was that the best time to call someone for help is before an incident occurs. At the very least, you can protect your organization by demonstrating due diligence.
Costs of not being prepared
Fines - legislative/regulatory oversight often comes with some kind of fine
Notification - writing and mailing letters is going to cost time and money
Charges - 20,000 Visa credit card numbers are exposed...who's going to pay for the cost of reissuing all of those credit cards? You get three guesses, and none of the answers are "Visa" or "the card holder". And two of your guesses don't count.
Suits - Civil suits have been brought against organizations as a result of a breach; just defending yourself is expensive
Something very important to remember about regulatory requirements is that in many cases, unless you're able to definitively identify the data that was exposed, you may have to notify on ALL data that could potentially have been exposed. So, if the database containing 6 million records was compromised, and you were not prepared for an incident, and you think that only 23,000 records were exposed...but you don't know for sure...guess how many people you're going to have to notify? You get three guesses, and the first two don't count.
Benefits of Incident Preparedness
Compliance - with legislative and regulatory requirements
Lower overall cost - the upfront cost of doing nothing is...nothing; in the long run, however, costs mount.
Confidence - from your Board of Directors and the consumer (b/c you're demonstrating "due diligence")
As long as we use IT assets to conduct business, and as long a people are part of the process, there will always be a need for incident response. Incidents are always going to occur, without question. The difference today (and tomorrow) is if you're going to be prepared for an incident...or not.
Every now and then when I get a chance to sit back and reflect, something strikes me. Most often those things were right there in front of me all along, and I just never noticed them. Things like these reasons that people give me.
Take for example the reason of "due diligence". It occurs to me that if someone were really interested in performing due diligence, they would've called me before the incident occurred, to ensure that they were prepared to handle an incident. Closing the barn door and shutting the stall doors after the horse has left is not "due diligence".
What about the "disinterested third party"? If you call a consulting company to come help you contain and recover from an incident, the fact that you're paying them obviates the "disinterested" part of the description, doesn't it?
Many times, folks at an organization looking for assistance after an incident has been detected will say that they want an outside firm to handle the examination in case the issue ends up going to court. But what's the real difference between the victim organization performing the investigation and an outside firm doing so? The outside firm most often has a documented process, or at the very least documents what they did in their report.
The primary reason that consulting companies are called when an incident occurs is that the organization was simply unprepared for an incident. Regardless of legislative or regulatory requirements, they're simply unprepared.
This is not to say that when an incident occurs, you should not call someone for assistance. Rather, I'm reiterating my response from the SANS Forensic Summit panel when Rob Lee asked the panel members about response time to a call...my response was that the best time to call someone for help is before an incident occurs. At the very least, you can protect your organization by demonstrating due diligence.
Costs of not being prepared
Fines - legislative/regulatory oversight often comes with some kind of fine
Notification - writing and mailing letters is going to cost time and money
Charges - 20,000 Visa credit card numbers are exposed...who's going to pay for the cost of reissuing all of those credit cards? You get three guesses, and none of the answers are "Visa" or "the card holder". And two of your guesses don't count.
Suits - Civil suits have been brought against organizations as a result of a breach; just defending yourself is expensive
Something very important to remember about regulatory requirements is that in many cases, unless you're able to definitively identify the data that was exposed, you may have to notify on ALL data that could potentially have been exposed. So, if the database containing 6 million records was compromised, and you were not prepared for an incident, and you think that only 23,000 records were exposed...but you don't know for sure...guess how many people you're going to have to notify? You get three guesses, and the first two don't count.
Benefits of Incident Preparedness
Compliance - with legislative and regulatory requirements
Lower overall cost - the upfront cost of doing nothing is...nothing; in the long run, however, costs mount.
Confidence - from your Board of Directors and the consumer (b/c you're demonstrating "due diligence")
As long as we use IT assets to conduct business, and as long a people are part of the process, there will always be a need for incident response. Incidents are always going to occur, without question. The difference today (and tomorrow) is if you're going to be prepared for an incident...or not.
Thursday, November 20, 2008
Yet another way to use RegRipper
The other day, John McCash sent me an email that said the following (posted with permission):
I figured out how to make Encase switch the current working directory for the viewer and like it. The command line "/c cd /d D:\regripper&rip -r [file] -f all&pause", using "C:\WINDOWS\system32\cmd.exe" as the application path, works just dandy in the file viewer configuration.
What John's done is launch rip.exe as an EnCase file viewer. Now, I'm not sure why you'd want to use "D:\regripper&rip", and to be honest, I usually don't use file viewers in EnCase, but hey, John, if that works for you, more power to ya! Git 'er done! ;-)
I figured out how to make Encase switch the current working directory for the viewer and like it. The command line "/c cd /d D:\regripper&rip -r [file] -f all&pause", using "C:\WINDOWS\system32\cmd.exe" as the application path, works just dandy in the file viewer configuration.
What John's done is launch rip.exe as an EnCase file viewer. Now, I'm not sure why you'd want to use "D:\regripper&rip", and to be honest, I usually don't use file viewers in EnCase, but hey, John, if that works for you, more power to ya! Git 'er done! ;-)
Saturday, November 15, 2008
New Code Posted
I posted JT's deleted.zip code to the RegRipper site this morning...go to Downloads, click on RegRipper, and you'll see the zipped archive listed there. The forums are down at the moment so I'll post the simplest usage her...simply unzip the archive into a directory and use the command line:
C:\tools>deleted.pl
It's that easy.
Addendum: No, this is NOT a RegRipper plugin...this is JT's code which is completely separate from RegRipper.
C:\tools>deleted.pl
It's that easy.
Addendum: No, this is NOT a RegRipper plugin...this is JT's code which is completely separate from RegRipper.
Thursday, November 13, 2008
Rootkit Detection For Free
During an engagement not long ago, the customer's IT staff had collected bits of the suspect network traffic, and then using the source IP address from the capture, located the system in question and ran "netstat -ano" on the system to prove that the traffic really did originate from that system. Task Manager and tasklist.exe also showed the process with the PID seen in the netstat output.
What does this have to do with rootkits? Well, for one...it proves that they didn't have one! I can't tell you the number of times someone's said to me, "I didn't see anything suspicious, so it must be a rootkit." Yeah, and if I turn my face toward the monitor and close my eyes, and don't see any unusual processes (or anything else for that matter), does that mean that there must be a rootkit on the system?
Well, all I can say is that the simplicity of that finding made it all the more awesome...
What does this have to do with rootkits? Well, for one...it proves that they didn't have one! I can't tell you the number of times someone's said to me, "I didn't see anything suspicious, so it must be a rootkit." Yeah, and if I turn my face toward the monitor and close my eyes, and don't see any unusual processes (or anything else for that matter), does that mean that there must be a rootkit on the system?
Well, all I can say is that the simplicity of that finding made it all the more awesome...
Wednesday, November 12, 2008
More Deleted Keys Goodness!
I was performing some analysis recently, and ran across some real analysis goodness.First off, I was using my usual tools to parse and analyze Windows Event Logs, and was getting a warning that some of the logs were corrupted. First, the auditpol RegRipper plugin made it clear what was being audited and logged on the system I was analyzing, and then the evtrpt tool was providing me with statistics about the total number of event records, frequency of event IDs and sources, and the date range of all event records. All of this information can give an analyst considerable insight into the content of the Event Logs before I even open them. At that point, I used a modified version of evt2xls to parse the Event Logs into Excel spreadsheet format, and then performed my analysis. Note: EventID.net is an excellent resource to have handy when doing this sort of analysis, and well worth the annual subscription fee.
So, in the Security Event Log on one system, I saw that a user account had been used to create, modify (i.e., add that account to the Local Adminstrators group), and then delete that user account. Of course, the account had been deleted, but I found no other indications that the account had even existed (user profile, etc.), not even in the SAM Registry hive file. So I pulled out JT's code and ran it against the hive file, and presto! There was the deleted key, extracted from unallocated space within the hive file, and I two source of time data with which I could correlate the events.
In another Security Event Log, from another system, I could see where a user account was accessing the Service Control Manager on a system repeatedly, starting and stopping the PSExeSVC service. However, the System hive file from that host showed no indications of the service...until I ran JT's code on it! Again, I had timestamped data from the Event Log that I could then correlate with the LastWrite time from the deleted Registry key.
I have to say that JT did a great job with her code, which she put together as part of her master's thesis from the University of Liverpool. At her request, I will be posting her code to RegRipper.net, and including it in and along with the second edition of Windows Forensic Analysis.
While we're on the subject of the Registry, a good friend of mine contacted me last week with an issue. Apparently, he was working on an examination in which a key factor of the case was determining if and when the user had uninstalled Firefox. According to him, "...install and uninstall dates of programs are of great interest. This will also show destruction of evidence and add additional charges to cases. It also increases sentences sometime by 2x." To help him out, I wrote a plugin that would parse the default browser information from the Registry, but then I compiled the (as-yet-unreleased, still-private, not-even-in-beta) ripxp code, which he used, said that it worked like a champ!
All in all, this is very cool, truly awesome stuff! While this sort of thing doesn't solve every problem, it does add an entirely new capability to the analyst's toolkit, providing answers to new (and in some cases, as yet unasked) questions!
Friday, October 31, 2008
Random Updates
I've been on the road a bit lately, and as such don't really have much info for a single post, but I have a couple of small tidbits that fit nicely when mashed into a single post...
I caught Hogfly's Beware the Key post...in it, he points to this KB article about correcting the "disable Autorun" capability in the Registry. By default, removable storage devices do not (and should not) have autorun capabilities enabled, but preventative measures pushed out via GPOs if necessary are a good thing. Why? Check out this article from India (here from Wired) about an iPod being used to steal data. The usbstor2 plugin for RegRipper was designed just for this type of incident; to help you consolidate data from multiple systems in one place for correlation and analysis. In an infrastructure with dispersed systems, F-Response Enterprise Edition would be extremely useful...I mean, "da bomb-shizzle".
If you do any incident response work at all, you should probably take a look at Didier Stevens' pdf-parser.py Python code. He made this code available from his blog post on analyzing a malicious PDF file. This can be used to narrow down the attack vector for an intrusion or malware on the system.
I've posted about free tools before (here, as well), and one that I wanted to add was a free, open-source AV scanner called MoonAV. If you're looking for other free tools, I'd suggest staying up on the NirSoft Blog, just like Claus. There are a number of very, very useful freeware utilities at NirSoft and more coming soon.
With respect to open-source AV, there are some other interesting, older links over at the OpenAntiVirus project page, as well.
Christine updated the e-Evidence site today! This is the closest thing to a monthly digital forensics e-zine available! Be sure to bookmark this site and check it out regularly.
I caught Hogfly's Beware the Key post...in it, he points to this KB article about correcting the "disable Autorun" capability in the Registry. By default, removable storage devices do not (and should not) have autorun capabilities enabled, but preventative measures pushed out via GPOs if necessary are a good thing. Why? Check out this article from India (here from Wired) about an iPod being used to steal data. The usbstor2 plugin for RegRipper was designed just for this type of incident; to help you consolidate data from multiple systems in one place for correlation and analysis. In an infrastructure with dispersed systems, F-Response Enterprise Edition would be extremely useful...I mean, "da bomb-shizzle".
If you do any incident response work at all, you should probably take a look at Didier Stevens' pdf-parser.py Python code. He made this code available from his blog post on analyzing a malicious PDF file. This can be used to narrow down the attack vector for an intrusion or malware on the system.
I've posted about free tools before (here, as well), and one that I wanted to add was a free, open-source AV scanner called MoonAV. If you're looking for other free tools, I'd suggest staying up on the NirSoft Blog, just like Claus. There are a number of very, very useful freeware utilities at NirSoft and more coming soon.
With respect to open-source AV, there are some other interesting, older links over at the OpenAntiVirus project page, as well.
Christine updated the e-Evidence site today! This is the closest thing to a monthly digital forensics e-zine available! Be sure to bookmark this site and check it out regularly.
Thursday, October 23, 2008
Bridging the Gap
I work for a large corporation that includes a vulnerability research organization. This organization is responsible for discovering vulnerabilities to operating systems, applications, etc. When they discover a vulnerability and develop a successful exploit, that information goes into the protection mechanisms produced by another part of the company, which are monitored by yet another part of the company. What this ultimately means is that attacks using those techniques are monitored or stopped before the systems themselves are compromised.
So I always think its cool when someone from a monitoring organization reveals some information about an attack that they've seen, such as this post from Symantec. I think its interesting to see this sort of thing, not only to see what an attack "looks like", but also to see if my analysis process includes the ability to find this sort of thing. As an analyst, I've been able to determine that yes, your system was compromised, Mrs. Jones, but when it comes down to it, how would I go about determining how it was compromised? There are a number of browser-borne attacks out there that are possible...how do you narrow down which one was used (if the initial compromise was via the browser?)?
In this particular case, the exploit involves overwriting a file opened by the MS Help and Support Center, so a quick way to check to see if this was the case is to use the following command (either on a live system, or on a system mounted with SmartMount):
C:\>dir /tw windows\pchealth\helpctr\system\sysinfo
Also, point #4 in the blog post states that the MS Help and Support Center Viewer handles "hcp://" links... to see the file association, check the Registry (in the following key) to see that:
HKEY_CLASSES_ROOT\HCP\shell\open\command
You should see something like this in the "(Default)" value:
%SystemRoot%\PCHEALTH\HELPCTR\Binaries\HelpCtr.exe -FromHCP -url "%1"
What posts like this allow us to do is to bridge the gap between vulnerability and exploit, and incident response and forensic analysis.
Another such example can be seen at the MS Malware Protection Center, particularly with this post about Win32\Rustock. Looking at the write-up, you're probably wondering how you'd go about using this information...the malware comes in three components, all encrypted, packed with ApLib, and oh, yeah...its polymorphic. Nice! However, as Jesse pointed out in his rootkit paradox paper, these things usually have a persistence mechanism, and in this case, a driver is installed. Even if it's not given the same name, RegRipper can be used to parse through the System hive file using the "services2" plugin, listing the installed services and device drivers, sorted by the key LastWrite times. If you don't want to acquire an image of the system, you can extract the System hive from a running system using FTK Imager, or show how cool you are by using F-Response.
One interesting piece that I pulled out of the write-up was that early versions of the malware apparently "...used alternative streams to store the installer...", but this technique was dropped. What they're referring to here is NTFS alternate data streams. Leave it to the folks at MS to use "polymorphic terminology" (MS has referred to these as "multiple", "alternate", and "alternative", as well as simply called them "data streams") to describe something so simple.
So I always think its cool when someone from a monitoring organization reveals some information about an attack that they've seen, such as this post from Symantec. I think its interesting to see this sort of thing, not only to see what an attack "looks like", but also to see if my analysis process includes the ability to find this sort of thing. As an analyst, I've been able to determine that yes, your system was compromised, Mrs. Jones, but when it comes down to it, how would I go about determining how it was compromised? There are a number of browser-borne attacks out there that are possible...how do you narrow down which one was used (if the initial compromise was via the browser?)?
In this particular case, the exploit involves overwriting a file opened by the MS Help and Support Center, so a quick way to check to see if this was the case is to use the following command (either on a live system, or on a system mounted with SmartMount):
C:\>dir /tw windows\pchealth\helpctr\system\sysinfo
Also, point #4 in the blog post states that the MS Help and Support Center Viewer handles "hcp://" links... to see the file association, check the Registry (in the following key) to see that:
HKEY_CLASSES_ROOT\HCP\shell\open\command
You should see something like this in the "(Default)" value:
%SystemRoot%\PCHEALTH\HELPCTR\Binaries\HelpCtr.exe -FromHCP -url "%1"
What posts like this allow us to do is to bridge the gap between vulnerability and exploit, and incident response and forensic analysis.
Another such example can be seen at the MS Malware Protection Center, particularly with this post about Win32\Rustock. Looking at the write-up, you're probably wondering how you'd go about using this information...the malware comes in three components, all encrypted, packed with ApLib, and oh, yeah...its polymorphic. Nice! However, as Jesse pointed out in his rootkit paradox paper, these things usually have a persistence mechanism, and in this case, a driver is installed. Even if it's not given the same name, RegRipper can be used to parse through the System hive file using the "services2" plugin, listing the installed services and device drivers, sorted by the key LastWrite times. If you don't want to acquire an image of the system, you can extract the System hive from a running system using FTK Imager, or show how cool you are by using F-Response.
One interesting piece that I pulled out of the write-up was that early versions of the malware apparently "...used alternative streams to store the installer...", but this technique was dropped. What they're referring to here is NTFS alternate data streams. Leave it to the folks at MS to use "polymorphic terminology" (MS has referred to these as "multiple", "alternate", and "alternative", as well as simply called them "data streams") to describe something so simple.
Wednesday, October 22, 2008
What do you need as a responder?
Many times when working with customers or talking with folks who interface with incident responders (or are incident responders), the topic of what information is pertinent to a responder comes up. When receiving calls from customers, many times the people who make the call and interface with the consultants are not themselves responders (or in some cases, even technical people), and instead represent their company from a business or legal/compliance perspective. This can often lead to misunderstandings due to differing perspectives, which ultimately leads to a lack of (accurate) information. However, this isn't restricted only to non-technical people...sometimes having the sysadmins on the call can lead to the same sort of thing, which is, again, largely due to perspective.
So...what do responders need to know when you call, or what information do your responders need access to?
Well, the first thing that an incident responder is going to need to know is your goals, or what you hope to achieve from the response activities.
In an ideal world, there are four basic sources of technical data that responders will be looking to...network traffic captures, network device log data (ie, firewalls, routers w/ ACLs, etc.), and host-based volatile (memory) and non-volatile (system image) data. There may be instances when all of this information is available, and there may be times when portions of this data is available...however, in many cases, for those unprepared for an incident, very little if any of this is available to a responder. The amount of information available to the responder is going to play a direct role in how completely the responder is going to be able to help you achieve your goals.
I once received a call from someone who needed help with a laptop. Apparently, the laptop had been infected with malware, and the immediate response was to take the laptop off of the network, wipe the hard drive, and install an updated version of the operating system. The caller wanted to know if I could tell them what the malware was, and what (if any) data had been taken. Seriously.
Some questions you're likely to be asked when you call someone to perform incident response include (but are not limited to):
- What type of incident are you experiencing? How would you characterize the incident?
- Do any of the affected systems contain "sensitive data" (per PCI, HIPAA, etc.)?
- How many systems are involved? What are their status? What are their hard drive types, configurations, and capacities (SAN/NAS, RAID 5 with a total of 100GB, mirrored, single 1TB drive, boot-from-SAN)?
- What actions have you taken already (and be honest...running an AV scan and deleting files isn't "nothing")?
- What data have you already collected, if any?
- Do you have a logical network diagram, particularly of the affected systems?
Lots of questions...do you have the answers?
So...what do responders need to know when you call, or what information do your responders need access to?
Well, the first thing that an incident responder is going to need to know is your goals, or what you hope to achieve from the response activities.
In an ideal world, there are four basic sources of technical data that responders will be looking to...network traffic captures, network device log data (ie, firewalls, routers w/ ACLs, etc.), and host-based volatile (memory) and non-volatile (system image) data. There may be instances when all of this information is available, and there may be times when portions of this data is available...however, in many cases, for those unprepared for an incident, very little if any of this is available to a responder. The amount of information available to the responder is going to play a direct role in how completely the responder is going to be able to help you achieve your goals.
I once received a call from someone who needed help with a laptop. Apparently, the laptop had been infected with malware, and the immediate response was to take the laptop off of the network, wipe the hard drive, and install an updated version of the operating system. The caller wanted to know if I could tell them what the malware was, and what (if any) data had been taken. Seriously.
Some questions you're likely to be asked when you call someone to perform incident response include (but are not limited to):
- What type of incident are you experiencing? How would you characterize the incident?
- Do any of the affected systems contain "sensitive data" (per PCI, HIPAA, etc.)?
- How many systems are involved? What are their status? What are their hard drive types, configurations, and capacities (SAN/NAS, RAID 5 with a total of 100GB, mirrored, single 1TB drive, boot-from-SAN)?
- What actions have you taken already (and be honest...running an AV scan and deleting files isn't "nothing")?
- What data have you already collected, if any?
- Do you have a logical network diagram, particularly of the affected systems?
Lots of questions...do you have the answers?
Tuesday, October 21, 2008
New Tools
Thought I'd take a page from Claus's book and update everyone as to some new tools that are available...
First, over on the Volatility Tumbleblog, there's mention of two new Volatility plugins that Jesse Kornblum developed for use with Volatility. Also on the same blog is a link to a tool to search memory dumps for GMail artifacts. Both look like exceptional utilities.
Speaking of Claus, be sure to check out the updated browser analysis tools over at NirSoft. Claus is also the one who pointed out that AutoRuns has been updated. Thanks! AutoRuns a great tool to use in IR, and to keep up to date on autostart locations.
Brian Carrier updated the TSK tools to v3.0, which includes the Windows versions of the tools. I've updated my own regtime.pl script to produce output similar to that of fls, so that the output of the script can be appended to the output of fls, and parsed with mactime to produce a timeline of file (and now Registry) activity on a system. At this time, only the path and mtime fields are populated for Registry keys, as the LastWrite time is analogous to the last modification times for files. With the currently available tools, deleted keys can be added to the list. I'll need to update the plugins to have RegRipper and rip produce the same output, which would be more targeted (and perhaps more valuable) than dumping all of the keys.
First, over on the Volatility Tumbleblog, there's mention of two new Volatility plugins that Jesse Kornblum developed for use with Volatility. Also on the same blog is a link to a tool to search memory dumps for GMail artifacts. Both look like exceptional utilities.
Speaking of Claus, be sure to check out the updated browser analysis tools over at NirSoft. Claus is also the one who pointed out that AutoRuns has been updated. Thanks! AutoRuns a great tool to use in IR, and to keep up to date on autostart locations.
Brian Carrier updated the TSK tools to v3.0, which includes the Windows versions of the tools. I've updated my own regtime.pl script to produce output similar to that of fls, so that the output of the script can be appended to the output of fls, and parsed with mactime to produce a timeline of file (and now Registry) activity on a system. At this time, only the path and mtime fields are populated for Registry keys, as the LastWrite time is analogous to the last modification times for files. With the currently available tools, deleted keys can be added to the list. I'll need to update the plugins to have RegRipper and rip produce the same output, which would be more targeted (and perhaps more valuable) than dumping all of the keys.
Monday, October 20, 2008
'Zines
For a while now, I've been asking others about what they thought about a forensics/IR magazine...a 'zine (print or electronic) dedicated to IR/CF topics. Most of the responses I've received have been mixed...some good, not many disagreements, but also not a great deal of interest in providing content. Okay, okay...maybe that was too much to ask, but I just have to wonder if there's any interest at all.
Usually the first thing folks say is that the subject is too niche...but have you been to the bookstores lately? There are multiple magazines on tattoos and skin art, antique doll collecting...you name it. If a lot of these subjects/topics aren't "niche", I don't know what topics would be.
Other 'zines that cater to the techie-nerd crowd include Hackin9, Make, (IN)Secure, and Linux Sysadmin Magazine. Even a recent issue of Linux Pro Magazine had a couple of articles aimed at incident response...while not overly technical or "forensic-y", they were useful and an interesting read. Most such articles seem to be aimed at system administrators, with the goal of introducing them to the topic, rather than immediately taking a deep dive into the subject matter.
Content - A 'zine such as this could have all sorts of great content, if some of the emails and blogs I've seen have been any indication. There are folks out there with lots of great ideas. Of course, the "usual suspects" would be included...hardware/software reviews, maybe even book reviews, etc. Sections or articles could be specific to Linux, AS/400, Windows, MacOSX, cellphones/PDAs, etc. The stuff that goes into a 'zine like this could be limitless...challenges, reader emails, ads for conferences and products, new tools or techniques, new versions of software, etc.
Audience - who would this type of media be aimed at? State, local, and federal law enforcement, college (grad/undergrad) students in computer forensics tracks, corporate responders, consultants, even hobbyists. Pretty much anyone who does or is interested in this kind of work, regardless of from which perspective (host- or network-based).
I have no idea what it takes to start something like this from the ground up...and I'm not even going to assume that it's something I can do myself. I would be very interested in contributing...heck, anyway to get CPE points, right?...and trying to get others to contribute, as well. Right now, there is the Digital Investigation Journal, and I would like to be part of attempting to make this a more hands-on journal, and less academic in nature. I have no experience planning something like this, and besides, like most of you, I already have a day job. What I would be interested in doing is perhaps assisting someone who already has the infrastructure available, and working with others to plan out an agenda or content list a year out. One way to go about this might be to email the editor-in-chief of DIJ, expressing an interest in either creating content for the journal, or simply send in your thoughts. Also, I've asked Monika of the Hackin9 staff if this is something that they'd be interested in producing...if you like the idea, and are willing to subscribe or even contribute (dude...CPE points!!!), email her and tell her so!
Usually the first thing folks say is that the subject is too niche...but have you been to the bookstores lately? There are multiple magazines on tattoos and skin art, antique doll collecting...you name it. If a lot of these subjects/topics aren't "niche", I don't know what topics would be.
Other 'zines that cater to the techie-nerd crowd include Hackin9, Make, (IN)Secure, and Linux Sysadmin Magazine. Even a recent issue of Linux Pro Magazine had a couple of articles aimed at incident response...while not overly technical or "forensic-y", they were useful and an interesting read. Most such articles seem to be aimed at system administrators, with the goal of introducing them to the topic, rather than immediately taking a deep dive into the subject matter.
Content - A 'zine such as this could have all sorts of great content, if some of the emails and blogs I've seen have been any indication. There are folks out there with lots of great ideas. Of course, the "usual suspects" would be included...hardware/software reviews, maybe even book reviews, etc. Sections or articles could be specific to Linux, AS/400, Windows, MacOSX, cellphones/PDAs, etc. The stuff that goes into a 'zine like this could be limitless...challenges, reader emails, ads for conferences and products, new tools or techniques, new versions of software, etc.
Audience - who would this type of media be aimed at? State, local, and federal law enforcement, college (grad/undergrad) students in computer forensics tracks, corporate responders, consultants, even hobbyists. Pretty much anyone who does or is interested in this kind of work, regardless of from which perspective (host- or network-based).
I have no idea what it takes to start something like this from the ground up...and I'm not even going to assume that it's something I can do myself. I would be very interested in contributing...heck, anyway to get CPE points, right?...and trying to get others to contribute, as well. Right now, there is the Digital Investigation Journal, and I would like to be part of attempting to make this a more hands-on journal, and less academic in nature. I have no experience planning something like this, and besides, like most of you, I already have a day job. What I would be interested in doing is perhaps assisting someone who already has the infrastructure available, and working with others to plan out an agenda or content list a year out. One way to go about this might be to email the editor-in-chief of DIJ, expressing an interest in either creating content for the journal, or simply send in your thoughts. Also, I've asked Monika of the Hackin9 staff if this is something that they'd be interested in producing...if you like the idea, and are willing to subscribe or even contribute (dude...CPE points!!!), email her and tell her so!
Saturday, October 18, 2008
Summit Takeaways
I recently received an email from the organizers of the SANS Forensic Summit and was asked to provide my biggest takeaways from the summit, and I wanted to post what I came up with, to see if others are seeing the same sorts of things...so, here's what I provided:I would say that the key take-away for me is that speed is essential, but should not be sacrificed for accuracy. Incident responders need to respond quickly in order to identify, classify, and as appropriate, contain an incident. In part, this puts the onus on the organizations...even if they have consultants on retainer, it will still take time for them to arrive, and then they are slowed down even further having to get up to speed and learn the environment. Consultants can assist an organization in developing a tier 1 response, training them in triage, diagnosis, preview, containment, etc., even across an enterprise. I would also say that tools such as F-Response are paramount to this sort of activity, as well. Once the initial training is complete, the consultants can respond as tier 2 or 3 responders, assisting as necessary, but knowing that the necessary data has been collected.
It's clear that state (via PII notification laws) and federal legislation, as well as regulatory oversight (PCI, HIPAA, etc.), play a huge role in incident response. In fact, these are the primary drivers to IR at this point. Think about it...if a company was not required to notify someone when a breach of sensitive data occurred, would they?
To that end, there needs to be a much more immediate response...calling a consulting firm to come on-site to assist after the incident has occurred and been detected is a fantastic idea, but one of two things are going to happen; you're either going to continue "bleeding" data while you're waiting, or you're going to stomp all over the data and destroy the indicators (aka, "evidence") that those consultants will be looking for in order to answer the questions that need to be answered.
Okay, brief digression here...what questions will need to be answered? There are essentially three questions that need to be answered in the face of a breach of sensitive data...(a) was a system compromised, (b) did the system contain sensitive data, and (c) was that sensitive data exposed or compromised as a result of the breach? In order to determine (c), in most cases, you need to minimize "temporal proximity" (thanks, AAron, for that very Star Trek-y term!!)...that is, you need to detect the breach and collect data as close to the time of the breach as possible.
Rather than fall victim to a breach and not get the answers you need (by "you", perhaps a more appropriate way of saying it would be "your legal counsel or compliance officer"), why not get someone in ahead of time, before an incident occurs, to work with you in setting up a response plan, and training your staff in a timely, accurate response?
I've said before that tools like F-Response and Volatility (the combination of the two being referred to as Voltage) have changed the face of incident response. Having these tools available to you allow you to quickly collect and analyze memory in order to triage and categorize incidents. Too many times I've been asked to come on-site only to find out that prior to the call, the customer had already turned systems off and taken them offline. These tools will help you collect more data than every before, reduce that "temporal proximity", and at the very least have data available for tier 2 incident responders to process and analyze.
Thoughts?
Wednesday, October 15, 2008
SANS Forensic Summit
The SANS Forensic Summit, a first-of-its-kind event for incident responders and forensic analysts, is over and I have to give a hearty and whole-hearted thanks to Rob Lee for chairing the event and bringing everyone...consultants, practitioners, and yes, even vendors...into such a unique forum. The combination panel and presentation format provided a great opportunity for attendees to interact with speakers in ways other than just listening to their presentations.Speaking of which, there were a number of exceptional presentations throughout the two days. Rob talked about using TSK's fls and ils to generate file system timelines, which led me to think that it wouldn't be too great a stretch to add the same sort of capability to RegRipper, and have the Registry data included in the timeline information. The guys from Verizon gave a great presentation on their incident statistics, and the Mandiant presentation illustrated some interesting artifacts from a real-world examination.
One prevalent theme throughout the summit was that there was a lot of folks "calling the baby ugly". As humorous as that may sound, that was the euphemism for being up-front and letting folks know, yes, we have a problem. At least one of the issues identified that both Richard Bejtlich and I (and others) seemed to agree on was that the need to protect data is no longer the driver for incident response...if it ever truly was. Currently, legislation (state notification laws) and regulatory oversight (PCI, HIPAA, etc.) are the drivers for incident response.
Also, a common thread from the consultants to the admins in the audience seemed to be, help us help you. At one point during a panel, Rob Lee asked something along the lines of, how soon should someone who's been breached call for help, and my response was "before it happens." Seriously. Get someone on-site before you
All in all, it was a great event, very beneficial to attendees and speakers alike. Rob did a great job pulling together talent such as Richard Bejtlich of GE and TaoSecurity fame, AAron Walters, Mike Poor and Tom Liston of InGuardians, Lance Mueller, Eoghan Casey, Bret Padres and Ovie Carroll, as well as Kris Harms, Wendi Rafferty and Ken Bradley from Mandiant, and Monty McDougal. Jennifer Kolde was there representing the FBI, as was Matt Shannon...F-Response is and was a huge hit. I was talking with a couple of folks who attended the summit and when the topic of F-Response came up, you could see the light come on in their eyes as they realized the potential that could be realized through a product like this.
It was also great to be able to talk with folks like Jeff Caplan, and (me being really bad with names) Doug and the guy from Ford.
One of the big take-aways that I got from the summit is the fact that folks like the speakers (consultants, in most cases) and attendees (admins, etc.) face a lot of the same problems with respect to incident response...namely, how to preview and triage systems, and how to do so in an enterprise environment.
I'm hoping to be invited to and be able to attend the next SANS Forensic Summit, in July 2009!
See what others thought:
AAron
Matt from F-Response
Tuesday, October 07, 2008
RegRipper Plugin Generator
Jason Koppe, whom I met at DFRWS (Jason, Cory and I "helped" close out the tab at the reception at the Wharf Rat on Monday evening...you're welcome, Brian! ;-) ) has written a RegRipper plugin generator! Check it out!Basically, what Jason has done is come up with a good overall plan to encapsulate my vision for the plugins themselves. I've found it difficult to really come up with a discernible pattern, due to the variations in the plugins...all start at a root key, and then some look for subkeys, some for specific values, some for all values, etc. Look at the UserAssist key plugin (no, seriously...open it up in an editor)...not only are the values extracted, but they need to be ROT-13 "decrypted". The USBStor2 plugin parses and correlates information from multiple keys.
Regardless of the eccentricities of my brain and perspective, Jason's done a great job of putting together a basic RegRipper plugin generator. While there are a number of dependencies to the GTk+ UI code that James used for regview.pl, it looks like Jason has made yet another excellent argument for installing them!
Great job, Jason!
Question: Besides PlainSight, where else is RegRipper being used?
Monday, October 06, 2008
New Registry Analysis Tools
As I mentioned earlier, James Macfarlane has released an update to his Parse::Win32Registry Perl module. In order to install the module, I simply downloaded the .tar.gz file, extracted everything, and copied the contents of the lib directory in the tarball to my C:\Perl\site\lib directory. Yep, that's it.
James have been nice enough to include a number of useful utilities to demonstrate the new capabilities of his modules...some of those new utilities are:
- regstats.pl - gives you statistics about a file, such as the number of keys and values, with an option to show the number of different value types
- regtimeline.pl - prints a timeline of all Registry key LastWrite times
- regexport.pl - exports the Registry hive file (or part of it) as a .reg file
One of the most interesting tools James included with his updates is regscan.pl, which parses through a Registry hive file, identifying different cells. However, instead of following the various links between cells, regscan.pl simply parses through the binary hive file one cell at a time. Running the script produces some interesting output:
0x38cd48 1 nk $$$PROTO.HIV\ControlSet003\Control\Nls\MUILanguage\RCV2\
umaxu40.dll [2004-08-23T21:24:25Z]
0x38cda8 1 vk 0 (REG_BINARY) = 00 00 28 0a 01 00 05 00
0x38cdc8 1 ..
0x38cdd8 1 vk 1 (REG_BINARY) = ab c4 e9 4c d8 fd a5 7c de 59 ff 05 93 9e 87 ba 02
0a e6 17 27 02 f9 a3 42 27 95 a0 61 0e 66 fd
Pretty cool, eh? Probably not...doesn't look very useful, does it? Well, see that "1" following the offset? That tells you whether the key or value is "in use"; that is, is it in allocated or unallocated space within the hive file? Sound interesting? Check it out...running the following command:
C:\Perl>regscan.pl d:\cases\system | find "0 nk"
...showed me a list of all of the Registry keys found to NOT be in use in the hive file! Basically, what this script and command line are showing me are a list of deleted keys in the hive file. Here's an excerpt of the output:
0x1ef020 0 nk (Invalid Parent Key)\04 [2004-08-18T00:39:36Z]
0x1f0020 0 nk (Invalid Parent Key)\Security [2004-08-18T00:32:16Z]
0x1f2020 0 nk $$$PROTO.HIV\ControlSet001\Enum\Root\LEGACY_DCOMLAUNCH
\0000\Services\SCardDrv [2004-08-23T21:34:10Z]
Notice that the first two keys don't have their full paths traced all the way back to the root key, but the last one does.
Pretty neat stuff, eh? I'm considering including the use of regscan.pl in my SANS Forensic Summit presentation demos, but I'm not sure if the usefulness of this type of information will really be apparent...what do you think?
James have been nice enough to include a number of useful utilities to demonstrate the new capabilities of his modules...some of those new utilities are:
- regstats.pl - gives you statistics about a file, such as the number of keys and values, with an option to show the number of different value types
- regtimeline.pl - prints a timeline of all Registry key LastWrite times
- regexport.pl - exports the Registry hive file (or part of it) as a .reg file
One of the most interesting tools James included with his updates is regscan.pl, which parses through a Registry hive file, identifying different cells. However, instead of following the various links between cells, regscan.pl simply parses through the binary hive file one cell at a time. Running the script produces some interesting output:
0x38cd48 1 nk $$$PROTO.HIV\ControlSet003\Control\Nls\MUILanguage\RCV2\
umaxu40.dll [2004-08-23T21:24:25Z]
0x38cda8 1 vk 0 (REG_BINARY) = 00 00 28 0a 01 00 05 00
0x38cdc8 1 ..
0x38cdd8 1 vk 1 (REG_BINARY) = ab c4 e9 4c d8 fd a5 7c de 59 ff 05 93 9e 87 ba 02
0a e6 17 27 02 f9 a3 42 27 95 a0 61 0e 66 fd
Pretty cool, eh? Probably not...doesn't look very useful, does it? Well, see that "1" following the offset? That tells you whether the key or value is "in use"; that is, is it in allocated or unallocated space within the hive file? Sound interesting? Check it out...running the following command:
C:\Perl>regscan.pl d:\cases\system | find "0 nk"
...showed me a list of all of the Registry keys found to NOT be in use in the hive file! Basically, what this script and command line are showing me are a list of deleted keys in the hive file. Here's an excerpt of the output:
0x1ef020 0 nk (Invalid Parent Key)\04 [2004-08-18T00:39:36Z]
0x1f0020 0 nk (Invalid Parent Key)\Security [2004-08-18T00:32:16Z]
0x1f2020 0 nk $$$PROTO.HIV\ControlSet001\Enum\Root\LEGACY_DCOMLAUNCH
\0000\Services\SCardDrv [2004-08-23T21:34:10Z]
Notice that the first two keys don't have their full paths traced all the way back to the root key, but the last one does.
Pretty neat stuff, eh? I'm considering including the use of regscan.pl in my SANS Forensic Summit presentation demos, but I'm not sure if the usefulness of this type of information will really be apparent...what do you think?
Bluetooth in the Registry
Does anyone out there have Registry hive files available from a system that they've used (or know has been used) to complete Bluetooth pairings?
I'd like to see about writing some RegRipper plugins to assist with the analysis of situations is which this is important.
If someone wants to loan me a laptop and some Bluetooth devices, so that I can do the testing and analysis myself, I will happily return the equipment when I'm done with it (yeah, I know....that didn't work with the USB stuff, or when folks wanted info on Firewire devices, either - hopefully my luck will change).
I'd like to see about writing some RegRipper plugins to assist with the analysis of situations is which this is important.
If someone wants to loan me a laptop and some Bluetooth devices, so that I can do the testing and analysis myself, I will happily return the equipment when I'm done with it (yeah, I know....that didn't work with the USB stuff, or when folks wanted info on Firewire devices, either - hopefully my luck will change).
Saturday, October 04, 2008
Hackin9 Registry Analysis Article
I received word this past week that an article I had written on Registry Analysis would be appearing in an upcoming issue of Hackin9 magazine. I wrote this article a bit ago, and it covers some basics, and includes an image/picture from an older version of RegRipper, but I hope that they'll ask me back, and I'll be able to write something a bit more up-to-date and get it out in print sooner.
SANS Forensic Summit
As the SANS Forensic Summit draws nigh, I've been preparing the demos for my presentation, Secrets of Registry Analysis Revealed. In addition to this presentation, I'll will also be participating in some panels. I've seen the current program, and there's even a panel on volatile data, which I think is very topical and very much needed. Also, Richard Bejtlich will be giving the keynote speech on the second day.Part of my presentation will include demos (yes, Rob told me I can't just talk the whole time...) of RegRipper and rip.exe (CLI version of RegRipper), as well as a new tool I call ripXP. Before I say anything else about this, I have to say that ripXP was an idea that Rob had several months ago...he told me something like, "hey, wouldn't it be cool if you wrote a tool like RegRipper, only it would also run the plugin against the hive files in the XP Restore Points?" So, in my copious amounts of free time (HTML really needs a sarcasm or smart-@$$
Okay, so what IS ripXP? RipXP is similar to rip.exe, in that it is a CLI tool and that it uses the same plugins as RegRipper and rip.exe. You give ripXP (as command line arguments) the hive file, the directory where the Restore Points reside (more on that later), and a plugin to run. Once you have all this, ripXP will then:
-> Access the hive file and guess what kind (SAM, System, NTUSER.DAT, Software, or Security) hive file it is (if it's an NTUSER.DAT file, it will attempt to retrieve the user's SID
-> Compare the type of hive file to the hive file that the plugin was written for; that is, if you pass it a System hive file, it won't let you run a plugin meant for an NTUSER.DAT file (just like rip.exe, ripXP includes the "-l" option so you can list all available plugins)
-> Run the plugin against the hive file you selected
-> Access the System Restore RP directories, and run the plugin against the appropriate hive
Oh, yeah...when ripXP accesses an RP directory, it also displays the Description, Type, and Creation Date of the Restore Point.
Okay, so besides being totally, AWESOMELY, AMAZINGLY cool...so what? Well, for the demos, I'm using Lance Mueller's practical images, so the number of RP directories is limited. However, in a real examination, a tool like this would allow you to see a historical progression of data. I've used only a couple of the plugins in my testing thus far, such as userassist, acmru, and a couple of others. But look at the MountedDevices key, or any of the MRU listings in the NTUSER.DAT file...this would allow you to see a historical progression over time of how the data changed.
Also, consider a Restore Point created one day, and then the following day, some data within that key was deleted by the user. Those historical artifacts would still exist in the hive files in the Restore Points, and would not only be accessible, but would also be visible sequentially.
Finally, like rip.exe, ripXP can be deployed within a batch file, and you could even create/use a Perl script to create that batch file, based on a standard methodology. Oh, yeah...the RP directories. So, you have an image...raw dd, split raw dd, EWF, whatever. What I did was open the image file in FTK Imager and export the RP directories to another location; in my case, D:\test\XP1. Then, because I wanted to use them easily and repeatedly, I burned them to CD, so I now access them as E:\XP1\RP1, RP2, RP3, etc. What I need to do is test them for use with SmartMount, and other tools like it. Yes, this will make the command line a bit longer, but it should work just fine. (Addendum: Testing using a mounted image is complete and extremely successful!)
Anyway, this will be one of my demos. If you're going to be at the Summit, be sure to stop by when we talk about Registry analysis.
Subscribe to:
Posts (Atom)