I've released lsproc.exe to the WindowsIR site on SourceForge. This is a small tool that parses through a dd.exe-style dump of physical memory (RAM) from a Windows 2000 system, locating EPROCESS blocks. The program prints out some information about each process, as shown here (an excerpt from the output of lsproc.exe, run against the first DFRWS 2005 Memory Challenge dump file):
Type PPID PID Name Offset FLink BLink
---- ---- --- ---- ------ ----- -----
Proc 228 672 WinMgmt.exe 0x0017dd60 0xff1bab80 0xff22f820
Proc 820 324 helix.exe 0x00306020 0xff0e4e00 0xff16e460
Proc 0 0 Idle 0x0046d160 0x00000000 0x00000000
Proc 600 668 UMGR32.EXE 0x0095f020 0xff1916e0 0xff191ce0
Proc 324 1112 cmd2k.exe 0x00dcc020 0xff0dae00 0xff0e4e00
Proc 668 784 dfrws2005.exe(x)0x00e1fb60 0x00000000 0x00000000
Proc 156 176 winlogon.exe 0x01045d60 0xff29d120 0xfcc69520
Proc 156 176 winlogon.exe 0x01048140 0xff29f520 0xfcc6c3a0
Proc 144 164 winlogon.exe 0x0104ca00 0xff2ae0c0 0xfcc7abe0
Proc 156 180 csrss.exe 0x01286480 0xfca28e00 0xfcc99360
Proc 144 168 csrss.exe 0x01297b40 0xfca2faa0 0xfcca50c0
Proc 8 156 smss.exe 0x012b62c0 0xfcc69520 0xfce00d00
Proc 0 8 System 0x0141dc60 0xfcc99360 0x8046b980
Proc 668 784 dfrws2005.exe(x)0x016a9b60 0x00000000 0x00000000
Proc 1112 1152dd.exe(x) 0x019d1980 0x00000000 0x00000000
Sorry about any issues with formatting...however, I have included the complete output from the first dump in the zipped archive provided at SourceForge.
Notice that some of the process names are appended with "(x)". This indicates that the process has exited; this also accounts for why the FLink and BLink values are 0x00 in those cases.
Lsproc.exe works by opening the dump file in binary mode, and searching through that file one DWORD (a DWORD is 4 bytes) at a time. On Windows 2000, the EPROCESS block (as well as the ETHREAD structure) has a specific signature, so by locating that signature and then performing certain follow-on checks, we can locate these structures. Again, lsproc.exe doesn't retrieve *all* of the data about the process...we're leaving that for other tools.
This will be the first of several tools for retrieving information from these dumps. The follow-on tools will make use of the information displayed in the output of lsproc.exe. I wanted to separate the process of searching for processes from the process of gathering process details, as the search can take a while. Once the offset to an EPROCESS block is located, dumping the process environment, memory pages, and image are relatively straightforward.
As with previous tools, this one is (and the others to come) were created in Perl. The approach I've taken with these tools is to try to make them platform independant, meaning that even though the physical memory dump needs to be retrieved from a Windows 2000 system, the tools themselves don't need to be run on Windows. In fact, they can be run on Linux or even a Mac G5...so the analyst is not restricted to a specific analysis platform.
Friday, April 07, 2006
Thursday, April 06, 2006
WindowsIR SourceForge site
Okay, based on a question the Bret posed in the CyberSpeak interview, I've set up a SourceForge site for my tools. Thinking about it, this is probably a better idea than using the Windows-ir.com site.
Right now, all I've got posted to the site is the RAMDump GUI I wrote, which is a wrapper around George M. Garner's version of dd.exe. The basic idea is to allow someone to capture/dump \\.\PhysicalMemory from a Windows 2000/XP system, with less knowledge. The GUI will tell you how much physical memory is on the system, and which drives (and type of drive...fixed, removeable, network) are available, and once the dump process is started, will give you a status. It's pretty simple and straightforward, and the source is provided in case you want to modify the command line that is launched, or the messages, or whatever.
If you don't have Perl2Exe to create a standalone executable from the Perl script, look at installing Perl (if you haven't already) and the PAR module ("ppm install PAR" under Activestate) and using that to create the standalone EXEs.
Over time, I'll be adding the FSP and FRU tools, the tools I've created for processing dumps of physical memory, and other supporting tools for the FSP/FRU. This will include analysis/correlation tools for processing the data collected by the FRU/FSP.
Right now, all I've got posted to the site is the RAMDump GUI I wrote, which is a wrapper around George M. Garner's version of dd.exe. The basic idea is to allow someone to capture/dump \\.\PhysicalMemory from a Windows 2000/XP system, with less knowledge. The GUI will tell you how much physical memory is on the system, and which drives (and type of drive...fixed, removeable, network) are available, and once the dump process is started, will give you a status. It's pretty simple and straightforward, and the source is provided in case you want to modify the command line that is launched, or the messages, or whatever.
If you don't have Perl2Exe to create a standalone executable from the Perl script, look at installing Perl (if you haven't already) and the PAR module ("ppm install PAR" under Activestate) and using that to create the standalone EXEs.
Over time, I'll be adding the FSP and FRU tools, the tools I've created for processing dumps of physical memory, and other supporting tools for the FSP/FRU. This will include analysis/correlation tools for processing the data collected by the FRU/FSP.
Saturday, April 01, 2006
Tools
Okay, let's get this blog back on track, shall we?
I recently had an opportunity to use the FSP in an engagement, and to be honest, it worked very well. I was pretty happy with how things worked, but I did find somethings that I want to improve upon.
In a general sense, here's how the engagement went...I plugged my laptop into the network and set up the FSP server component, listening on port 7070 (the default). After calling the MSSP SOC for the client to let them know that they'd see some traffic on this port and that we were responsible for it, I would walk to the server and put the FRU CD into the CD-ROM tray. I was working with a sysadmin, and he'd terminal into the server and launch the FRU command line...which I'd typed into a Notepad window, so that all he had to do was cut-n-paste it into the command prompt. Very quick, very smooth. Nothing was written to the hard drive, and things like the .NET framework weren't required to be on any of the systems.
So...I did mention some improvements. Well, it's been suggested (yes, Ovie, I did hear you) that I set up a site on SourceForge for the FSP and various other tools. So, I've set up an account and I'm waiting to hear back if they'll accept my submission for a site. Once I do get a site, I'll start posting the various tools I've put together. This includes the FSP, as well as the supporting tools, and others, like the Perl modules I've posted to CPAN.
I also need to start working on the analysis suite of tools, one of them being to correlate information collected by the FRU and sent to the FSP into a nice HTML format. That, and I need to put together a user guide. I keep thinking that the FSP has appeared on the CERT VTE and is included in Helix, but there's nothing in the way of a comprehensive user guide.
Oh, and one more thing...I've been working on a GUI for folks to use for launching dd.exe. A friend asked me to put this together, and I've just about got it done...I just have some minor adjustments to make, then I'll fully document the code and post it. The idea is to make it easy for folks who need to do so to dump the contents of physical memory by identifying various drives (fixed, removable, network, etc.) to write to, etc.
I recently had an opportunity to use the FSP in an engagement, and to be honest, it worked very well. I was pretty happy with how things worked, but I did find somethings that I want to improve upon.
In a general sense, here's how the engagement went...I plugged my laptop into the network and set up the FSP server component, listening on port 7070 (the default). After calling the MSSP SOC for the client to let them know that they'd see some traffic on this port and that we were responsible for it, I would walk to the server and put the FRU CD into the CD-ROM tray. I was working with a sysadmin, and he'd terminal into the server and launch the FRU command line...which I'd typed into a Notepad window, so that all he had to do was cut-n-paste it into the command prompt. Very quick, very smooth. Nothing was written to the hard drive, and things like the .NET framework weren't required to be on any of the systems.
So...I did mention some improvements. Well, it's been suggested (yes, Ovie, I did hear you) that I set up a site on SourceForge for the FSP and various other tools. So, I've set up an account and I'm waiting to hear back if they'll accept my submission for a site. Once I do get a site, I'll start posting the various tools I've put together. This includes the FSP, as well as the supporting tools, and others, like the Perl modules I've posted to CPAN.
I also need to start working on the analysis suite of tools, one of them being to correlate information collected by the FRU and sent to the FSP into a nice HTML format. That, and I need to put together a user guide. I keep thinking that the FSP has appeared on the CERT VTE and is included in Helix, but there's nothing in the way of a comprehensive user guide.
Oh, and one more thing...I've been working on a GUI for folks to use for launching dd.exe. A friend asked me to put this together, and I've just about got it done...I just have some minor adjustments to make, then I'll fully document the code and post it. The idea is to make it easy for folks who need to do so to dump the contents of physical memory by identifying various drives (fixed, removable, network, etc.) to write to, etc.
...a couple of things, gents...
I just wanted to post a couple of thoughts and comments really quick...
First off, on Thu, I was interviewed by Ovie and Bret, the authors of the CyberSpeak podcasts. I'd heard about these podcasts before, but hadn't listened to them. Then a friend of mine heard that Ovie and Bret had mentioned my blog in their March 11 podcast, when they'd mentioned physical memory analysis. I've since listened to several of the podcasts (ok, all but one...) and they are pretty interesting. I don't own an iPod, because when I run, I don't feel comfortable cutting myself off from my surroundings like that. What I like to do is download the podcasts to my desktop and listen to them...that way I can have them on while I'm working, and easily pause them when I get up to do something else.
On a completely separate note, I received the numbers for my book from June through Dec 2005. The book seems to be doing okay, though not spectacular...like I've said before, it's not setting the world on fire. I initially thought that was holding me back from getting the proposal for my next book approved, but it has turned out that the real issue has been reorgs at the publisher and reviewers simply being too busy.
So...kind of anti-climatic for a 200th post, eh?
First off, on Thu, I was interviewed by Ovie and Bret, the authors of the CyberSpeak podcasts. I'd heard about these podcasts before, but hadn't listened to them. Then a friend of mine heard that Ovie and Bret had mentioned my blog in their March 11 podcast, when they'd mentioned physical memory analysis. I've since listened to several of the podcasts (ok, all but one...) and they are pretty interesting. I don't own an iPod, because when I run, I don't feel comfortable cutting myself off from my surroundings like that. What I like to do is download the podcasts to my desktop and listen to them...that way I can have them on while I'm working, and easily pause them when I get up to do something else.
On a completely separate note, I received the numbers for my book from June through Dec 2005. The book seems to be doing okay, though not spectacular...like I've said before, it's not setting the world on fire. I initially thought that was holding me back from getting the proposal for my next book approved, but it has turned out that the real issue has been reorgs at the publisher and reviewers simply being too busy.
So...kind of anti-climatic for a 200th post, eh?
Thursday, March 16, 2006
Windows Physical Memory Analysis, pt II
I've been taking a look at what's out there with regards to analyzing physical memory (RAM) dumps from Windows systems, and correlating what's available. Most of this is in my previous post on the subject, so what I'd like to do now it present some of what I've got so far. I've taken the work that Andreas Schuster (ie, ptfinder.pl) and Joe Stewart (ie, pmodump.pl from the TRUMAN project) have done, done some research on structures such as the PEB, PEB_LDR_DATA, and RTL_USER_PROCESS_PARAMETERS, and taken it a step further, albiet a small one.
Here's what I've got...the Perl code I've got right now parses through the memory dump (I'm using the dump from the DFRWS 2005 Memory Challenge as my initial test case) looking for EPROCESS blocks. Note that this is specific to Windows 2000, as we already know that's what the platform is/was, and so far, I haven't gotten around to working out how to determine the base OS from nothing more than a memory dump file. From there, the code retrieves data from the dump file, parsing structures and handling translations between virtual addresses (and pointers) to physical offsets within the dump file itself. Some of the information that gets pulled for each process includes the FLINK/BLINK values (pointers to previous/next EPROCESS block in the doubly-linked list), creation time (exit time, if applicable), whether exit has been called or not, and the location of the Process Environment Block.
Here's an example:
Possible EPROCESS block located at offset 0x6601460
Process Name : metasploit.exe
PID : 600
Parent PID : 240
FLINK : 0x0
BLINK : 0x0
SubSystem : 4.0
Exit Status : 0
Create Time : Sun Jun 5 00:55:08 2005
Exit Time : Sun Jun 5 00:55:08 2005
Exit Called : 1
PEB : 0x7ffdf000
DTB : 0x01a6d000
PEB Offset : 0x00000000
Notice that for this process named "metasploit.exe", the FLINK/BLINK values are zero'd out, and exit has been called. The offset to the PEB (ie, the physical offset within the dump file) has been calculated to be 0, based on the PEB and DirectoryPageTable values retrieved from the EPROCESS block.
Now, if the process was active at the time that the memory dump was made, the Perl code I wrote will parse the RTL_USER_PROCESS_PARAMETERS structure and retrieve information such as the current directory path, DLL path, command line, window title, and desktop name (I'll add parsing of additional information, such as flag values, once I locate information on the format of these structures). Here's an example:
Possible EPROCESS block located at offset 0x6352d60
Process Name : cmd2k.exe
PID : 1132
Parent PID : 324
FLINK : 0xff1190c0
BLINK : 0xff1440c0
SubSystem : 4.0
Exit Status : 259
Create Time : Sun Jun 5 14:10:52 2005
Exit Called : 0
PEB : 0x7ffdf000
DTB : 0x058dd000
PEB Offset : 0x01862000
Mutant = 0xffffffff
Base Addr = 0x00000000
PEB_LDR_DATA = 0x00131e90 (0x03293e90)
Params = 0x00020000 (0x04126000)
Current Directory Path = E:\Shells\
DllPath = E:\Shells;.;C:\WINNT\System32;C:\WINNT\system;C:\WINNT;
C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem
ImagePathName = E:\Shells\cmd2k.exe
Command Line = "E:\Shells\cmd2k.exe" /D /T:80 /F:ON /K cmdenv.bat
Window Title = E:\Shells\cmd2k.exe
Desktop Name = WinSta0\Default
From this information, we can see where the process was initiated from, as well as the command line used to launch the process. I'd sure like to see what's in cmdenv.bat!
Oh, and there's more! I was running through the output of the script and found that nc.exe was running when the dump was made...here's the image path and command line for the nc.exe process (PID = 1096):
ImagePathName = c:\winnt\system32\nc.exe
Command Line = "c:\winnt\system32\nc.exe" -L -p 3000 -t -e cmd.exe
Not only did I find a process called dd.exe that had exited, but I also found one that was still running (yeah, I know...it's the one that created the memory dump!). The image path and command line for that process are (note: I cleaned it up a little to make it easier to read):
ImagePathName = E:\Acquisition\FAU\dd.exe
Command Line = ..\Acquisition\FAU\dd.exe if=\\.\PhysicalMemory
of=F:\intrusion2005\physicalmemory.dd conv=noerror
--md5sum --verifymd5 --md5out=F:\intrusion2005\physicalmemory.dd.md5 --log=F:\intrusion2005\audit.log
So...so far, so good. The Perl code for this is a little too messy to release right now, but I will post it once I clean it up a bit and document it a bit better. I need to add dumping of the module list, and a couple of other functions to the script, as well as parsing for other structures.
Addendum 26 Mar: I've continued working on the code, and moved to a little side project. I've copied the subroutines from the original code and targetted individual EPROCESS blocks...searching the RAM dump for each EPROCESS block was just too slow for some simple testing and coding.
So, anyway...I'm pulling more from the EPROCESS block and PEB. For example, I've been able to pull the Environment variables (if they exist) from the process...the stuff you see when you type "Set" into the command prompt, as well as dumping the loading modules. From the first DFRWS 2005 Memory Challenge memory dump, the cmd2k.exe process uses the following modules:
E:\Shells\cmd2k.exe
C:\WINNT\System32\ntdll.dll
C:\WINNT\system32\KERNEL32.dll
C:\WINNT\system32\USER32.dll
C:\WINNT\system32\GDI32.DLL
C:\WINNT\system32\ADVAPI32.dll
C:\WINNT\system32\RPCRT4.DLL
C:\WINNT\system32\MSVCRT.dll
The Environment contains such things as LOGONSERVER and COMPUTERNAME. Cool stuff.
What I'm up to now is parsing through the handle table, starting with the ObjectTable value from within the EPROCESS block. If anyone wants to throw some pointers my way, I'd appreciate it! ;-)
Addendum 31 Mar: I wanted to get this one in late...if I wait until tomorrow, everyone will think it's a prank! With some help from Andreas, I've been able to extract the handle tables from a process, using the ObjectTable value. Andreas was kind enough to point to me, among other things, that I wasn't translating one of the virtual addresses I was receiving to a physical address.
So, what I've been getting for the cmd2k.exe process looks like this:
Object Header at 0xfcd79010 (0x01396010)
Type Name : File
Type = 5
Size = 112
Name = \Shells
Object Header at 0xfca255c0 (0x010425c0)
Type Name : WindowStation
Object Header at 0xfca255c0 (0x010425c0)
Type Name : WindowStation
Object Header at 0xff29e9e0 (0x052099e0)
Type Name : Desktop
This is what I've been able to extract from the dump. I have to keep reminding myself that the system that the physical memory was dumped from had 128MB of RAM, so some of the virtual addresses will be to pages that have been swapped out of physical memory to the pagefile. I'll be sure to add this to the documentation of the code, and show where that aspect of an address is calculated.
Here's some more eye-candy...the UMGR32.exe process has these two handles:
Object Header at 0xff1bc010 (0x01a8d010)
Type Name : File
Type = 5
Size = 112
Name = \Endpoint
Object Header at 0xff1cf7b0 (0x006827b0)
Type Name : File
Type = 5
Size = 112
Name = \WINNT\system32\Perflib_Perfdata_29c.dat
The nc.exe process also points to a file handle named "\Endpoint".
Now, to get the pages of the memory used by each process...
Here's what I've got...the Perl code I've got right now parses through the memory dump (I'm using the dump from the DFRWS 2005 Memory Challenge as my initial test case) looking for EPROCESS blocks. Note that this is specific to Windows 2000, as we already know that's what the platform is/was, and so far, I haven't gotten around to working out how to determine the base OS from nothing more than a memory dump file. From there, the code retrieves data from the dump file, parsing structures and handling translations between virtual addresses (and pointers) to physical offsets within the dump file itself. Some of the information that gets pulled for each process includes the FLINK/BLINK values (pointers to previous/next EPROCESS block in the doubly-linked list), creation time (exit time, if applicable), whether exit has been called or not, and the location of the Process Environment Block.
Here's an example:
Possible EPROCESS block located at offset 0x6601460
Process Name : metasploit.exe
PID : 600
Parent PID : 240
FLINK : 0x0
BLINK : 0x0
SubSystem : 4.0
Exit Status : 0
Create Time : Sun Jun 5 00:55:08 2005
Exit Time : Sun Jun 5 00:55:08 2005
Exit Called : 1
PEB : 0x7ffdf000
DTB : 0x01a6d000
PEB Offset : 0x00000000
Notice that for this process named "metasploit.exe", the FLINK/BLINK values are zero'd out, and exit has been called. The offset to the PEB (ie, the physical offset within the dump file) has been calculated to be 0, based on the PEB and DirectoryPageTable values retrieved from the EPROCESS block.
Now, if the process was active at the time that the memory dump was made, the Perl code I wrote will parse the RTL_USER_PROCESS_PARAMETERS structure and retrieve information such as the current directory path, DLL path, command line, window title, and desktop name (I'll add parsing of additional information, such as flag values, once I locate information on the format of these structures). Here's an example:
Possible EPROCESS block located at offset 0x6352d60
Process Name : cmd2k.exe
PID : 1132
Parent PID : 324
FLINK : 0xff1190c0
BLINK : 0xff1440c0
SubSystem : 4.0
Exit Status : 259
Create Time : Sun Jun 5 14:10:52 2005
Exit Called : 0
PEB : 0x7ffdf000
DTB : 0x058dd000
PEB Offset : 0x01862000
Mutant = 0xffffffff
Base Addr = 0x00000000
PEB_LDR_DATA = 0x00131e90 (0x03293e90)
Params = 0x00020000 (0x04126000)
Current Directory Path = E:\Shells\
DllPath = E:\Shells;.;C:\WINNT\System32;C:\WINNT\system;C:\WINNT;
C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem
ImagePathName = E:\Shells\cmd2k.exe
Command Line = "E:\Shells\cmd2k.exe" /D /T:80 /F:ON /K cmdenv.bat
Window Title = E:\Shells\cmd2k.exe
Desktop Name = WinSta0\Default
From this information, we can see where the process was initiated from, as well as the command line used to launch the process. I'd sure like to see what's in cmdenv.bat!
Oh, and there's more! I was running through the output of the script and found that nc.exe was running when the dump was made...here's the image path and command line for the nc.exe process (PID = 1096):
ImagePathName = c:\winnt\system32\nc.exe
Command Line = "c:\winnt\system32\nc.exe" -L -p 3000 -t -e cmd.exe
Not only did I find a process called dd.exe that had exited, but I also found one that was still running (yeah, I know...it's the one that created the memory dump!). The image path and command line for that process are (note: I cleaned it up a little to make it easier to read):
ImagePathName = E:\Acquisition\FAU\dd.exe
Command Line = ..\Acquisition\FAU\dd.exe if=\\.\PhysicalMemory
of=F:\intrusion2005\physicalmemory.dd conv=noerror
--md5sum --verifymd5 --md5out=F:\intrusion2005\physicalmemory.dd.md5 --log=F:\intrusion2005\audit.log
So...so far, so good. The Perl code for this is a little too messy to release right now, but I will post it once I clean it up a bit and document it a bit better. I need to add dumping of the module list, and a couple of other functions to the script, as well as parsing for other structures.
Addendum 26 Mar: I've continued working on the code, and moved to a little side project. I've copied the subroutines from the original code and targetted individual EPROCESS blocks...searching the RAM dump for each EPROCESS block was just too slow for some simple testing and coding.
So, anyway...I'm pulling more from the EPROCESS block and PEB. For example, I've been able to pull the Environment variables (if they exist) from the process...the stuff you see when you type "Set" into the command prompt, as well as dumping the loading modules. From the first DFRWS 2005 Memory Challenge memory dump, the cmd2k.exe process uses the following modules:
E:\Shells\cmd2k.exe
C:\WINNT\System32\ntdll.dll
C:\WINNT\system32\KERNEL32.dll
C:\WINNT\system32\USER32.dll
C:\WINNT\system32\GDI32.DLL
C:\WINNT\system32\ADVAPI32.dll
C:\WINNT\system32\RPCRT4.DLL
C:\WINNT\system32\MSVCRT.dll
The Environment contains such things as LOGONSERVER and COMPUTERNAME. Cool stuff.
What I'm up to now is parsing through the handle table, starting with the ObjectTable value from within the EPROCESS block. If anyone wants to throw some pointers my way, I'd appreciate it! ;-)
Addendum 31 Mar: I wanted to get this one in late...if I wait until tomorrow, everyone will think it's a prank! With some help from Andreas, I've been able to extract the handle tables from a process, using the ObjectTable value. Andreas was kind enough to point to me, among other things, that I wasn't translating one of the virtual addresses I was receiving to a physical address.
So, what I've been getting for the cmd2k.exe process looks like this:
Object Header at 0xfcd79010 (0x01396010)
Type Name : File
Type = 5
Size = 112
Name = \Shells
Object Header at 0xfca255c0 (0x010425c0)
Type Name : WindowStation
Object Header at 0xfca255c0 (0x010425c0)
Type Name : WindowStation
Object Header at 0xff29e9e0 (0x052099e0)
Type Name : Desktop
This is what I've been able to extract from the dump. I have to keep reminding myself that the system that the physical memory was dumped from had 128MB of RAM, so some of the virtual addresses will be to pages that have been swapped out of physical memory to the pagefile. I'll be sure to add this to the documentation of the code, and show where that aspect of an address is calculated.
Here's some more eye-candy...the UMGR32.exe process has these two handles:
Object Header at 0xff1bc010 (0x01a8d010)
Type Name : File
Type = 5
Size = 112
Name = \Endpoint
Object Header at 0xff1cf7b0 (0x006827b0)
Type Name : File
Type = 5
Size = 112
Name = \WINNT\system32\Perflib_Perfdata_29c.dat
The nc.exe process also points to a file handle named "\Endpoint".
Now, to get the pages of the memory used by each process...
Saturday, March 04, 2006
Windows Physical Memory Analysis
I'll be writing more on this particular subject as time goes on, but I wanted to post something right away. I've noticed over the past couple of weeks that Andreas Schuster has been doing some work with debuggers, etc., to document some of the structures found in physical memory for various versions of Windows, from Win2000 SP4 through Vista (he's noted that most of the structures change between versions and even between Service Packs). Well, I took a look the other day and noticed that he'd posted something called PTFinder, which as it just so happens is a Perl script that parses a dump of physical memory (this version works for dumps of physical memory from Win2000 SP4 systems).
So, I took a look at what he was doing, and exchanged some emails, and expressed my desire to assist with what he's doing. As it turns out, the DFRWS 2005 Memory Challenge provides a great set of test files (2, actually) for testing any tools you're writing to parse a memory dump generated using dd.exe.
I started working on something of my own, using the exercise as a learning process so that I can not only be smarter on this stuff, but to also assist Andreas with what he's doing. I've got the output of the Memory Challenge submissions to check my work against, and so far, things are working pretty well. Here's an excerpt of the output from my version of the script:
Possible EPROCESS block located at offset 0x3e35ae0
Process Name : Explorer.Exe
PID : 820
Parent PID : 800
Exit Status : 259
Create Time : Sun Jun 5 00:33:53 2005
Exit Called : 0
Possible EPROCESS block located at offset 0x40b4660
Process Name : PcfMgr.exe
PID : 1048
Parent PID : 820
Exit Status : 259
Create Time : Sun Jun 5 00:34:01 2005
Exit Called : 0
Possible EPROCESS block located at offset 0x414dd60
Process Name : dd.exe
PID : 284
Parent PID : 1112
Exit Status : 259
Create Time : Sun Jun 5 14:53:42 2005
Exit Called : 0
Pretty cool, eh? One thing to point out is that processes (specifically, EPROCESS blocks) are maintained in a doubly-linked list. One way to walk through the process blocks is to find one and follow the links...but you can miss things this way. Andreas' approach, and the one I've chosen to follow, is to start at the beginning of the dump file and start looking for process blocks.
There's a lot of work that still needs to be done. Last week, a LEO I know attending the Southeast CyberCrime Summit sent me a message from his Blackberry, asking me if I'd come up with a way to run a tool to dump the contents of physical memory to a thumb drive or some other removable storage platform. In the past, I've talked to folks (particularly LEOs) about why they collect the contents of physical memory, and most have told me that they do so in order to run 'strings' against it to see if they can find leads (not evidence) such as passwords, IP or email addresses, IM screennames, etc. The DFRWS 2005 Memory Challenge didn't result in any publicly available tools but research has continued (like I said, I'll be posting more on this later, and recognizing others who've done research along these lines, particularly Mariusz Burdach and his presentation at BlackHat Federal 2006).
Addendum 7 Mar 2006: Like I said, I wanted to post some more information on this subject, describing what has already gone on, and then hopefully where we need to go with this research.
Last year, I became aware of a paper by Mariusz Burdach that described how to analyze the contents of physical memory that was collected using dd/dd.exe. Being interested primarily in how to do this on Windows, I was a little disappointed that the paper focused on Linux. This sort of thing has been discussed in other areas, the most formal being the DFRWS 2005 Memory Challenge. There has been discussion of this subject in other forums, such as Rootkit.com and Windows Forensic Analysis (Yahoo! Group).
The results of the DFRWS Memory Challenge included two winning responses, one by Chris Betz, and the other by George M. Garner, Jr. and Robert-Jan Mora. Both of these approaches are very involved, and produced some interesting results. The down-side of this work is that neither of the tools mentioned in both winning submissions is publicly available. Andreas Schuster released ptfinder.pl, a Perl script that parses through a dump of Windows physical memory searching for the different structures. Andreas recently posted on the difference between tools like ptfinder.pl and the "list-walkers" produced by Betz and Garner/Mora.
Addendum 9 Mar: Yesterday I became aware of some work by Joe Stewart over at LURHQ.com...specifically, the TRUMAN Project, described as the "reusable unknown malware analysis net". Part of the project is a Perl script called pmodump.pl, "a Perl-based tool to reconstruct the virtual memory space of a process from a PhysicalMemory dump". The description goes on to say that "with this tool it is possible to circumvent most packers to perform strings analysis on the dumped malware". Very cool, and a great idea.
Pmodump.pl operates a bit differently from the other methods presented so far. The script locates potential Page Directory blocks and then does a translation between "logical" or virtual addresses and physical offsets within the dump file, using the default value for the pointer to the Process Environment Block (PEB) for pre-WinXP systems. The output of the script is very comprehensive, including such things as PE headers for executables loaded into memory (check out the File::ReadPE module to see how to parse this info), module lists, etc.
What this shows is that there have been several different, disparate approaches to this issue, different authors taking different approaches, as their needs and skill sets have been different. This looks like a great opportunity to bring all of these efforts together into a single project.
Another thing I'd like to see is information regarding other kernel structures that can be found within memory. I've got the MS Debugging Tools installed on my system, so all I'm really missing at this point is the correct names of the structures. Does anyone have any pointers?
Addendum 11 Mar: More great reading posted...Andreas has posted a blog entry on translating virtual addresses located in memory dumps to physical offsets within the dump file. Great stuff!
Addendum 14 Mar: I got a call late last night, just before CSI:Miami started (note to self: unplug phone when any version of CSI starts...)...evidently this blog entry had been mentioned in the 11 Mar Cyberspeak podcast! If you look at the main page, you'll see that many a famous name in the community has been interviewed by these guys...I haven't made it a habit of listening to these podcasts, but that's about to change. For the record, though, guys, it's "windowsir", not "windows", "s", "i", "r".
So, I took a look at what he was doing, and exchanged some emails, and expressed my desire to assist with what he's doing. As it turns out, the DFRWS 2005 Memory Challenge provides a great set of test files (2, actually) for testing any tools you're writing to parse a memory dump generated using dd.exe.
I started working on something of my own, using the exercise as a learning process so that I can not only be smarter on this stuff, but to also assist Andreas with what he's doing. I've got the output of the Memory Challenge submissions to check my work against, and so far, things are working pretty well. Here's an excerpt of the output from my version of the script:
Possible EPROCESS block located at offset 0x3e35ae0
Process Name : Explorer.Exe
PID : 820
Parent PID : 800
Exit Status : 259
Create Time : Sun Jun 5 00:33:53 2005
Exit Called : 0
Possible EPROCESS block located at offset 0x40b4660
Process Name : PcfMgr.exe
PID : 1048
Parent PID : 820
Exit Status : 259
Create Time : Sun Jun 5 00:34:01 2005
Exit Called : 0
Possible EPROCESS block located at offset 0x414dd60
Process Name : dd.exe
PID : 284
Parent PID : 1112
Exit Status : 259
Create Time : Sun Jun 5 14:53:42 2005
Exit Called : 0
Pretty cool, eh? One thing to point out is that processes (specifically, EPROCESS blocks) are maintained in a doubly-linked list. One way to walk through the process blocks is to find one and follow the links...but you can miss things this way. Andreas' approach, and the one I've chosen to follow, is to start at the beginning of the dump file and start looking for process blocks.
There's a lot of work that still needs to be done. Last week, a LEO I know attending the Southeast CyberCrime Summit sent me a message from his Blackberry, asking me if I'd come up with a way to run a tool to dump the contents of physical memory to a thumb drive or some other removable storage platform. In the past, I've talked to folks (particularly LEOs) about why they collect the contents of physical memory, and most have told me that they do so in order to run 'strings' against it to see if they can find leads (not evidence) such as passwords, IP or email addresses, IM screennames, etc. The DFRWS 2005 Memory Challenge didn't result in any publicly available tools but research has continued (like I said, I'll be posting more on this later, and recognizing others who've done research along these lines, particularly Mariusz Burdach and his presentation at BlackHat Federal 2006).
Addendum 7 Mar 2006: Like I said, I wanted to post some more information on this subject, describing what has already gone on, and then hopefully where we need to go with this research.
Last year, I became aware of a paper by Mariusz Burdach that described how to analyze the contents of physical memory that was collected using dd/dd.exe. Being interested primarily in how to do this on Windows, I was a little disappointed that the paper focused on Linux. This sort of thing has been discussed in other areas, the most formal being the DFRWS 2005 Memory Challenge. There has been discussion of this subject in other forums, such as Rootkit.com and Windows Forensic Analysis (Yahoo! Group).
The results of the DFRWS Memory Challenge included two winning responses, one by Chris Betz, and the other by George M. Garner, Jr. and Robert-Jan Mora. Both of these approaches are very involved, and produced some interesting results. The down-side of this work is that neither of the tools mentioned in both winning submissions is publicly available. Andreas Schuster released ptfinder.pl, a Perl script that parses through a dump of Windows physical memory searching for the different structures. Andreas recently posted on the difference between tools like ptfinder.pl and the "list-walkers" produced by Betz and Garner/Mora.
Addendum 9 Mar: Yesterday I became aware of some work by Joe Stewart over at LURHQ.com...specifically, the TRUMAN Project, described as the "reusable unknown malware analysis net". Part of the project is a Perl script called pmodump.pl, "a Perl-based tool to reconstruct the virtual memory space of a process from a PhysicalMemory dump". The description goes on to say that "with this tool it is possible to circumvent most packers to perform strings analysis on the dumped malware". Very cool, and a great idea.
Pmodump.pl operates a bit differently from the other methods presented so far. The script locates potential Page Directory blocks and then does a translation between "logical" or virtual addresses and physical offsets within the dump file, using the default value for the pointer to the Process Environment Block (PEB) for pre-WinXP systems. The output of the script is very comprehensive, including such things as PE headers for executables loaded into memory (check out the File::ReadPE module to see how to parse this info), module lists, etc.
What this shows is that there have been several different, disparate approaches to this issue, different authors taking different approaches, as their needs and skill sets have been different. This looks like a great opportunity to bring all of these efforts together into a single project.
Another thing I'd like to see is information regarding other kernel structures that can be found within memory. I've got the MS Debugging Tools installed on my system, so all I'm really missing at this point is the correct names of the structures. Does anyone have any pointers?
Addendum 11 Mar: More great reading posted...Andreas has posted a blog entry on translating virtual addresses located in memory dumps to physical offsets within the dump file. Great stuff!
Addendum 14 Mar: I got a call late last night, just before CSI:Miami started (note to self: unplug phone when any version of CSI starts...)...evidently this blog entry had been mentioned in the 11 Mar Cyberspeak podcast! If you look at the main page, you'll see that many a famous name in the community has been interviewed by these guys...I haven't made it a habit of listening to these podcasts, but that's about to change. For the record, though, guys, it's "windowsir", not "windows", "s", "i", "r".
Friday, March 03, 2006
ProScript posted
I've posted another ProScript to the Techpathways forum...this one consolidates the other two that I previously posted. It dumps user information by parsing the F and V structures from the user's Registry key in the SAM hive, and gets group information by parsing the C structure from the group's key in the SAM hive. Note: The version of the ProScript that I posted to the forum doesn't try to translate any of the FILETIME objects found in the F structure.
Here's an excerpt from output from the script (one of the ones that does attempt to translate FILETIME objects), with user information displayed. I have an image that I downloaded from the Internet (one of those online challenges) open:
Username : Mr. Evil
Acct Creation Date : Thu Aug 19 23:03:54 2004
RID : 1003
Logins : 15
Flags :
Password does not expire
Normal user account
I have to go back and take a look at that script again...I wonder why my translation subroutine thinks that if Mr. Evil logged in 15 times, that he doesn't have a last login date. Hhhmmm...that's easy enough to check, though...I'll just have ProDiscover dump the appropriate key value to a file, and I'll open that in a hex editor. Either way, it's really cool stuff, being able to pull this sort of thing from the Registry. Now, correlate that with (a) the contents of the ProfileList Registry key, and (b) the "Documents and Settings" directory contents, and you've got a pretty comprehensive look at who's been logging into the system.
Here's an excerpt of that the group information looks like:
Group : Administrators
Comment : Administrators have complete and unrestricted access to the computer/domain
--> Administrator
--> Mr. Evil
I had a good deal of help from two sources in particular, Andreas Schuster and Peter Nordahl. Andreas provided information about the C structure, and Peter's NT bootdisk source code laid out what the F and V structures "look like". Very helpful...thanks to you both.
Here's an excerpt from output from the script (one of the ones that does attempt to translate FILETIME objects), with user information displayed. I have an image that I downloaded from the Internet (one of those online challenges) open:
Username : Mr. Evil
Acct Creation Date : Thu Aug 19 23:03:54 2004
RID : 1003
Logins : 15
Flags :
Password does not expire
Normal user account
I have to go back and take a look at that script again...I wonder why my translation subroutine thinks that if Mr. Evil logged in 15 times, that he doesn't have a last login date. Hhhmmm...that's easy enough to check, though...I'll just have ProDiscover dump the appropriate key value to a file, and I'll open that in a hex editor. Either way, it's really cool stuff, being able to pull this sort of thing from the Registry. Now, correlate that with (a) the contents of the ProfileList Registry key, and (b) the "Documents and Settings" directory contents, and you've got a pretty comprehensive look at who's been logging into the system.
Here's an excerpt of that the group information looks like:
Group : Administrators
Comment : Administrators have complete and unrestricted access to the computer/domain
--> Administrator
--> Mr. Evil
I had a good deal of help from two sources in particular, Andreas Schuster and Peter Nordahl. Andreas provided information about the C structure, and Peter's NT bootdisk source code laid out what the F and V structures "look like". Very helpful...thanks to you both.
Tuesday, February 28, 2006
Perl module upload to CPAN
I've uploaded another module to my directory on CPAN...this one is called File::ReadEvt. This is another module that reads a binary file type from a Windows system without using the MS API. You'd use this module if you were performing analysis on a Linux system, or any other system that has Perl installed, or if the tools that use the MS API (ie, EventViewer, psloglist, etc.) report that the .evt file is corrupted in some way.
Another great use includes online parsing systems, where you'd upload a file to a web server, which would parse/analyze the file and display the results in a web page. Or you can use this module with a database that provides some sort of hints or descriptions of various event types, so that the information you read is easier to understand.
No, this module doesn't support parsing the Event Log message files (DLLs) for how the strings should be inserted into the message (ie, %1 %2 %3 etc.). Sorry, but this module does provide the information from the events that would let YOU do that.
Here's the output from a run of the evtstats.pl example script I included in the archive:
C:\Perl>evtstats.pl c:\testing\appevent.evt
Max Size of the Event Log file = 327680 bytes
Actual Size of the Event Log file = 524288 bytes
Total number of event records (header info) = 1138
Total number of event records (actual count) = 1086
Total number of event records (rec_nums) = 1086
Total number of event records (sources) = 1086
Total number of event records (types) = 1086
Total number of event records (IDs) = 1086
This script also collects information in Perl hashes that you can use for statistical analysis. Examples include numbers of each record number, source, event type, and event ID.
There's another example script (lsevt3.pl) that parses through the Event Log file and sends the event record information to STDOUT (redirect this to a file).
A brief word on the format of the Event Log file...
A "normal" Event Log file (such as those found in the system32\config directory) begins with a 48 byte header. The first DWORD (ie, 4 bytes) of the header (and the last, as well) contains the size of the header...in a hex editor, you'll see "30 00 00 00". The second DWORD is the magic number, or "4C 66 4C 65" (ie, "LeLf")...this being the "magic number" as it should be unique to the file. The header also contains information about where certain events are located, such as the oldest one, and the next one to be written, as well as the maximum size of the file and the retention time.
Once you've read the header, you're ready to start reading the event records. To read the records, all you have to do is parse through the file a DWORD at a time, and locate the magic number...then, back up a DWORD, get the total size of the record, and begin parsing. The event record header is 56 bytes in size and anything beyond that is where the data associated with the event is located within the .evt file.
Now, event records are not (I repeat NOT) contiguous. There can be gaps...huge ones. I've seen DrWatson entries that are over 100K in size. Once you finish reading the header or a particular record, it could be a while within the file before you come upon a full event record. I took a look at an example Event Log file the other day, and there was a partial DrWatson entry right after the header, and the first event record was located about 25K into the file.
This module is right there along with File::MSWord (parses an MSWord document without using the MS API), and File::ReadPE (parses the headers of a PE file...great for analysis or educational purposes).
If you don't see the module in the directory when you click on the link above, give it a bit...I just uploaded it and I don't know how long it takes CPAN to process submitted modules.
If you have any questions about the use of any of these modules, feel free to contact me. If you're contacting me about problems with a particular Event Log file, be prepared to send me the file...
Another great use includes online parsing systems, where you'd upload a file to a web server, which would parse/analyze the file and display the results in a web page. Or you can use this module with a database that provides some sort of hints or descriptions of various event types, so that the information you read is easier to understand.
No, this module doesn't support parsing the Event Log message files (DLLs) for how the strings should be inserted into the message (ie, %1 %2 %3 etc.). Sorry, but this module does provide the information from the events that would let YOU do that.
Here's the output from a run of the evtstats.pl example script I included in the archive:
C:\Perl>evtstats.pl c:\testing\appevent.evt
Max Size of the Event Log file = 327680 bytes
Actual Size of the Event Log file = 524288 bytes
Total number of event records (header info) = 1138
Total number of event records (actual count) = 1086
Total number of event records (rec_nums) = 1086
Total number of event records (sources) = 1086
Total number of event records (types) = 1086
Total number of event records (IDs) = 1086
This script also collects information in Perl hashes that you can use for statistical analysis. Examples include numbers of each record number, source, event type, and event ID.
There's another example script (lsevt3.pl) that parses through the Event Log file and sends the event record information to STDOUT (redirect this to a file).
A brief word on the format of the Event Log file...
A "normal" Event Log file (such as those found in the system32\config directory) begins with a 48 byte header. The first DWORD (ie, 4 bytes) of the header (and the last, as well) contains the size of the header...in a hex editor, you'll see "30 00 00 00". The second DWORD is the magic number, or "4C 66 4C 65" (ie, "LeLf")...this being the "magic number" as it should be unique to the file. The header also contains information about where certain events are located, such as the oldest one, and the next one to be written, as well as the maximum size of the file and the retention time.
Once you've read the header, you're ready to start reading the event records. To read the records, all you have to do is parse through the file a DWORD at a time, and locate the magic number...then, back up a DWORD, get the total size of the record, and begin parsing. The event record header is 56 bytes in size and anything beyond that is where the data associated with the event is located within the .evt file.
Now, event records are not (I repeat NOT) contiguous. There can be gaps...huge ones. I've seen DrWatson entries that are over 100K in size. Once you finish reading the header or a particular record, it could be a while within the file before you come upon a full event record. I took a look at an example Event Log file the other day, and there was a partial DrWatson entry right after the header, and the first event record was located about 25K into the file.
This module is right there along with File::MSWord (parses an MSWord document without using the MS API), and File::ReadPE (parses the headers of a PE file...great for analysis or educational purposes).
If you don't see the module in the directory when you click on the link above, give it a bit...I just uploaded it and I don't know how long it takes CPAN to process submitted modules.
If you have any questions about the use of any of these modules, feel free to contact me. If you're contacting me about problems with a particular Event Log file, be prepared to send me the file...
Tuesday, February 21, 2006
Quoted
Joab Jackson quote me in this article over on Government Computer News. File metadata has been an issue for a while, and this isn't anything new...except for the fact that it's still an issue. MSWord and PDF documents can both contain metadata, and most do. Do a little Google hacking and pull up MSWord documents based on domain (.mil) or content, and see what you can see.
The script mentioned in the article is now available as a Perl module.
The script mentioned in the article is now available as a Perl module.
In the news...
If you own a Windows system (home user, corporate or university admin, etc.), you will want to see Brian Krebs' latest article in the Washington Post Magazine. I read it this weekend...largely because people I know who aren't in the computer industry kept telling me, "dude...you've GOT to read this article!" They were right...it is an incredible article, well crafted and written, that gives the reader an insight into the issue of botnets, and a glimpse of one of the micro-economies created as a result of the Internet.
One thing is clear, too...breaking into computers is no longer just for kicks. There are economic/financial/profit motives now...things like adware and spyware, and identity theft are all reasons for someone to want to break into and gain control of your computer.
One thing is clear, too...breaking into computers is no longer just for kicks. There are economic/financial/profit motives now...things like adware and spyware, and identity theft are all reasons for someone to want to break into and gain control of your computer.
Friday, February 17, 2006
Determining group membership from an image
A while back, I received this question..."how do I figure out a user's group membership from an image?" Well, I didn't know off the top of my head, and decided that knowing would be useful, so I started digging around. After receiving some much-needed insight from a friend on one of the online forums I frequent, I was able to create a ProScript (Perl script) for use with ProDiscover. I posted the script to their online forum, along with one to enumerate users from an image...and that one is just the beginning, as it only retrieves the user's name from the V structure. There is still quite a bit of information embedded in the F and V structures.
In a nutshell, the way it works is this...within the HKLM\SAM\SAM\Domains\Builtin\Aliases key, there are several subkeys...00000220, etc. These keys have a value named "C", which is binary, and contains the name of the group, the comment describing the group, etc. The first 52 (13 DWORDS) bytes of this value is the header, and the last three DWORDs describe the offset to the listing of user SIDs, the length of the data, and how many users there are. One of the SIDs for the Administrators group will end with the RID of "1F4", which is 500 in decimal...the Administrator account.
Now, to map the user RID to a username, go to HKLM\SAM\SAM\Domains\Account\Users key, where you will find subkeys that look like 000001F4 and 00000E3B, etc. These are the user RIDs, and user info is maintained in the binary V and F values within the key. The offset to the username (ofsName) is stored in the DWORD located 0xC bytes into the binary V structure (the length of the username is maintained in the next DWORD, which starts at offset 0x10). The username itself is in Unicode format and is found at offset 0xCC + ofsName from the beginning of the structure.
So...pretty cool, eh? I got started down the path of looking to the Builtin\Aliases key by running one of the 'net' commands (to enumerate group membership) while also running RegMon, and then filtering on the process I wanted. From there, a little work with a hexeditor and a little help from a friend went a long way.
It's really no surprise that there's nothing in the above post that points to Microsoft as providing assistance of documentation...that information simply is not available. It's not the fault of the folks who have done their best to assist me (and others) over the years...they can't provide what doesn't exist. What I've had to do is go to Linux-based documentation, talk to others, experiment on my own, etc.
On a side note, sometimes when I'm working with or discussing something with someone, particularly things related to the forensic analysis of Windows systems, I'll ask them if they have any sort of documentation or reference. This isn't meant as an indictment of them...I'm not asking them to prove anything, though most of the times, the response I get seems to indicate that they were seriously offended by the question. No, I'm asking for that simply because sometimes I may be able to correlate information from some sort of documentation with something else I've been looking at, or some other little tidbit of information I mayhave. Whenever possible, I try to provide references and/or documentation for what I do as it not only gives everyone a common base to work from, but it also lets others see what I've been looking at, so that they don't have to relearn all that stuff on their own.
Thoughts?
In a nutshell, the way it works is this...within the HKLM\SAM\SAM\Domains\Builtin\Aliases key, there are several subkeys...00000220, etc. These keys have a value named "C", which is binary, and contains the name of the group, the comment describing the group, etc. The first 52 (13 DWORDS) bytes of this value is the header, and the last three DWORDs describe the offset to the listing of user SIDs, the length of the data, and how many users there are. One of the SIDs for the Administrators group will end with the RID of "1F4", which is 500 in decimal...the Administrator account.
Now, to map the user RID to a username, go to HKLM\SAM\SAM\Domains\Account\Users key, where you will find subkeys that look like 000001F4 and 00000E3B, etc. These are the user RIDs, and user info is maintained in the binary V and F values within the key. The offset to the username (ofsName) is stored in the DWORD located 0xC bytes into the binary V structure (the length of the username is maintained in the next DWORD, which starts at offset 0x10). The username itself is in Unicode format and is found at offset 0xCC + ofsName from the beginning of the structure.
So...pretty cool, eh? I got started down the path of looking to the Builtin\Aliases key by running one of the 'net' commands (to enumerate group membership) while also running RegMon, and then filtering on the process I wanted. From there, a little work with a hexeditor and a little help from a friend went a long way.
It's really no surprise that there's nothing in the above post that points to Microsoft as providing assistance of documentation...that information simply is not available. It's not the fault of the folks who have done their best to assist me (and others) over the years...they can't provide what doesn't exist. What I've had to do is go to Linux-based documentation, talk to others, experiment on my own, etc.
On a side note, sometimes when I'm working with or discussing something with someone, particularly things related to the forensic analysis of Windows systems, I'll ask them if they have any sort of documentation or reference. This isn't meant as an indictment of them...I'm not asking them to prove anything, though most of the times, the response I get seems to indicate that they were seriously offended by the question. No, I'm asking for that simply because sometimes I may be able to correlate information from some sort of documentation with something else I've been looking at, or some other little tidbit of information I mayhave. Whenever possible, I try to provide references and/or documentation for what I do as it not only gives everyone a common base to work from, but it also lets others see what I've been looking at, so that they don't have to relearn all that stuff on their own.
Thoughts?
Sunday, February 12, 2006
What do you do when...??
Sometimes you find yourself in one of those situations, where the customer calls you and wants to know:
So, what do you do? After all, if it wasn't important, the customer wouldn't have called you, right? What do you tell them?
- Who copied or modified a file, or
- Who created or modified a user account
So, what do you do? After all, if it wasn't important, the customer wouldn't have called you, right? What do you tell them?
What the...??
What is the weirdest/most interesting thing you've seen when performing an investigation of a Windows system?
I once was asked to look at a Win2K system with no auditing enabled, and a weak Admin password. The system was infested with spyware and malware...at least three Trojans were installed. I also found three additional Admin accounts...God, g0d and gawd. It looked to me as if one person had gotten in and created the first account (gee-oh-dee), then the second person got in and found the account he wanted to create already there, so he created his own variation...gee-zero-dee.
What about you?
I once was asked to look at a Win2K system with no auditing enabled, and a weak Admin password. The system was infested with spyware and malware...at least three Trojans were installed. I also found three additional Admin accounts...God, g0d and gawd. It looked to me as if one person had gotten in and created the first account (gee-oh-dee), then the second person got in and found the account he wanted to create already there, so he created his own variation...gee-zero-dee.
What about you?
Tuesday, February 07, 2006
The Forensic Server Project
Recently, I've received a couple of emails about the Forensic Server Project (aka, FSP), seen it written up in the Helix 1.7 Beginner's Manual, and even seen it demo'd on the CERT VTE.
For a listing of sites that mention the FSP, go here.
Anyway, the one thing in common amongst all of these sites seems to be that the FSP is simply misunderstood. I talked about the FSP in chapter 8 of my book, but soon after the book was published, I made some updates to the tools, and released them as standalone executables (I compiled the Perl scripts with Perl2Exe).
So...what is the FSP? The FSP is a client/server architecture for effective, sound incident response procedures. The FSP, along with the client application (the First Responder Utility), provides a framework for quick, efficient, and effective data collection during incident response activities. The FRU can be run from a CD or thumb drive, and communicates via TCP with the FSP server component in order to get data off of a system.
Think of it like this...have you seen where netcat is used to get data off of systems? Each command is typed in by hand, or run via a batch file, and the output is piped out over netcat to a waiting listener on another system. The responder has to log each command entered, and do a lot of documentation manually. On the server end, the investigator either ends up with one huge file he must parse, or he has to shutdown and restart the listener for each new command.
The FSP, on the other hand, handles all that for you. The server component takes care of logging, hash generation (and comparison, if files are copied), timestamping of the logs, etc.
The FSP is also very flexible. The FRU runs off of ini files, which tell the application what commands to run, which Registry keys/values to collect, etc. With all of the necessary tools copied to the CD, the investigator create and choose from a variety of ini files, based on location, operating system, installed applications, etc. The ini file can be loaded on the CD or thumb drive, or run from a floppy or even a mapped drive.
So, yes, the FSP does require a little bit extra work in set up, but in providing the standalone executables, I've made that process MUCH easier. The flexibility simply can't be beat...there's no waiting for updates, as the FSP framework allows the investigator to run whichever third party tools she chooses.
There is still some room for improvement, though. For example, incorporating the ability to select files to be copied directly into the FRU. Another thing is the analysis suite...pulling together tools to parse and analyze that data that's collected.
Which brings me to something else that's beneficial about the FSP...it's written in Perl. A lot of folks may look at this and think "Ugh!" Well, being written in Perl, it's also open source. Which means that you can run the server component on just about any platform the supports Perl, and write your own client apps. The currently available FRU is the client for Windows, but clients can be written for Linux, the Mac, etc. And because the framework is open, you're not restricted to using just Perl. Use Python, Ruby, shell scripts...whatever you're most comfortable with.
So I guess I just added a couple of things to my ToDo list...a user manual, and a developer's manual.
For a listing of sites that mention the FSP, go here.
Anyway, the one thing in common amongst all of these sites seems to be that the FSP is simply misunderstood. I talked about the FSP in chapter 8 of my book, but soon after the book was published, I made some updates to the tools, and released them as standalone executables (I compiled the Perl scripts with Perl2Exe).
So...what is the FSP? The FSP is a client/server architecture for effective, sound incident response procedures. The FSP, along with the client application (the First Responder Utility), provides a framework for quick, efficient, and effective data collection during incident response activities. The FRU can be run from a CD or thumb drive, and communicates via TCP with the FSP server component in order to get data off of a system.
Think of it like this...have you seen where netcat is used to get data off of systems? Each command is typed in by hand, or run via a batch file, and the output is piped out over netcat to a waiting listener on another system. The responder has to log each command entered, and do a lot of documentation manually. On the server end, the investigator either ends up with one huge file he must parse, or he has to shutdown and restart the listener for each new command.
The FSP, on the other hand, handles all that for you. The server component takes care of logging, hash generation (and comparison, if files are copied), timestamping of the logs, etc.
The FSP is also very flexible. The FRU runs off of ini files, which tell the application what commands to run, which Registry keys/values to collect, etc. With all of the necessary tools copied to the CD, the investigator create and choose from a variety of ini files, based on location, operating system, installed applications, etc. The ini file can be loaded on the CD or thumb drive, or run from a floppy or even a mapped drive.
So, yes, the FSP does require a little bit extra work in set up, but in providing the standalone executables, I've made that process MUCH easier. The flexibility simply can't be beat...there's no waiting for updates, as the FSP framework allows the investigator to run whichever third party tools she chooses.
There is still some room for improvement, though. For example, incorporating the ability to select files to be copied directly into the FRU. Another thing is the analysis suite...pulling together tools to parse and analyze that data that's collected.
Which brings me to something else that's beneficial about the FSP...it's written in Perl. A lot of folks may look at this and think "Ugh!" Well, being written in Perl, it's also open source. Which means that you can run the server component on just about any platform the supports Perl, and write your own client apps. The currently available FRU is the client for Windows, but clients can be written for Linux, the Mac, etc. And because the framework is open, you're not restricted to using just Perl. Use Python, Ruby, shell scripts...whatever you're most comfortable with.
So I guess I just added a couple of things to my ToDo list...a user manual, and a developer's manual.
Images to play with
From other forums, I've found example images that can be used to sharpen your skills in forensic analysis. For example, there are some images at the CRFeDS Project at NIST...I've downloaded the "Hacking Case" images. There are also Digital Forensics Tool Testing images that are available.
There are also some things to play with over at the HoneyNet Project SotM site. Not only are there binaries you can look at and log files you can examine, but SotMs 24 and 26 involve examining the image of a floppy.
On a slightly tangential note, VMWare has made their Server product a free download...from there, you can find a list of community-built virtual machines. These are primarily various flavors of Linux/*nix, but would offer some practice if you ran the VMs and performed live imaging (I do this with my Windows VMs, using ProDiscover).
Are there any other example images of Windows systems out there, available for download?
On a side note, has anyone used some of the popular tools (such as the FSP, or WFT, or any of the various batch files) for retrieving volatile data from live Windows systems, and posted the data for analysis?
There are also some things to play with over at the HoneyNet Project SotM site. Not only are there binaries you can look at and log files you can examine, but SotMs 24 and 26 involve examining the image of a floppy.
On a slightly tangential note, VMWare has made their Server product a free download...from there, you can find a list of community-built virtual machines. These are primarily various flavors of Linux/*nix, but would offer some practice if you ran the VMs and performed live imaging (I do this with my Windows VMs, using ProDiscover).
Are there any other example images of Windows systems out there, available for download?
On a side note, has anyone used some of the popular tools (such as the FSP, or WFT, or any of the various batch files) for retrieving volatile data from live Windows systems, and posted the data for analysis?
Registry research
Is anyone out there doing research into the Windows Registry, from a forensic perspective?
I know that there are viewers available to allow you to see what's in the raw Registry files, and that these viewers are available for a variety of platforms. That's not what I'm looking for.
I'm also aware of the lists of Registry keys that are available, particular the one from AccessData that seems to be pretty popular. While it is a good starting point, there really isn't enough information about the keys/values in the list, and what causes them to be created, modified, or deleted to be useful beyond a certain point.
What I'm asking here is this...is anyone doing research into the conditions that cause various keys/values to be added to, modified, or deleted from the Registry (this also applies to the LastWrite time associated with Registry keys)? This is extremely important in the area of Windows forensic analysis, as it adds context to what the investigator sees.
Some things are obvious (though they could be better documented) such as the TypedURLs key...values are added when the user types a URL into the Address bar of IE. Other things aren't so obvious, such as what causes the LastWrite time of the unique ID key for a USB removeable storage device to be updated?
Is there anyone out there doing this kind of research? At the least, I'd like to consolidate a list of links. Ideally, I'd like to see the efforts themselves consolidated and optimized.
I know that there are viewers available to allow you to see what's in the raw Registry files, and that these viewers are available for a variety of platforms. That's not what I'm looking for.
I'm also aware of the lists of Registry keys that are available, particular the one from AccessData that seems to be pretty popular. While it is a good starting point, there really isn't enough information about the keys/values in the list, and what causes them to be created, modified, or deleted to be useful beyond a certain point.
What I'm asking here is this...is anyone doing research into the conditions that cause various keys/values to be added to, modified, or deleted from the Registry (this also applies to the LastWrite time associated with Registry keys)? This is extremely important in the area of Windows forensic analysis, as it adds context to what the investigator sees.
Some things are obvious (though they could be better documented) such as the TypedURLs key...values are added when the user types a URL into the Address bar of IE. Other things aren't so obvious, such as what causes the LastWrite time of the unique ID key for a USB removeable storage device to be updated?
Is there anyone out there doing this kind of research? At the least, I'd like to consolidate a list of links. Ideally, I'd like to see the efforts themselves consolidated and optimized.
Sunday, January 29, 2006
The Evolution of Live Response
In my last post, I mentioned that the FRU and FSP had been demos as part of the CERT VTE. Very cool. If you've read this blog for any period of time, you'll know that I've been interested in live response and forensic analysis of Windows systems for a while. One thing that the VTE demo showed me is that I really have to write up a user guide or manual for using the FSP tools, and then add a GUI to them.
That being said, I've been purusing the usual blogs for write ups regarding the recent BlackHat Federal conference. When you can't attend, reading other's impressions is the next best thing to being there. Kevin Mandia's presentation caught my eye, so I downloaded it and read through it. One of the things mentioned in the presentation is a "Live Response" tool that should be released by Kevin's company, Red Cliff Consulting, in January. After some discussion in the presentation on how incidents are detected, things that need to be collected are mentioned on slide 55 (there are 90 slides, folks, but the presentation is well worth the wait). The next slide contains a list of tools that can be run - while I agree with the tools for the most part, there are a couple that I'm not sure I'd run, but that's all covered in my book.
Slide 66 shows an image of the Live Response tool...it looks very interesting, and I really wish I'd been able to make it to the conference. I really like what I see in the presentation, overall...Kevin evidently went over several things (at least, in the slides) that I've been thinking about for some time now, such as the fact that live response is evolving due to the notification laws, with California's SB1386 being one of the first. In essence, companies need to know if client data has been compromised in anyway.
Thoughts? Where do we go from here? Is live response viable, particularly on Windows systems?
That being said, I've been purusing the usual blogs for write ups regarding the recent BlackHat Federal conference. When you can't attend, reading other's impressions is the next best thing to being there. Kevin Mandia's presentation caught my eye, so I downloaded it and read through it. One of the things mentioned in the presentation is a "Live Response" tool that should be released by Kevin's company, Red Cliff Consulting, in January. After some discussion in the presentation on how incidents are detected, things that need to be collected are mentioned on slide 55 (there are 90 slides, folks, but the presentation is well worth the wait). The next slide contains a list of tools that can be run - while I agree with the tools for the most part, there are a couple that I'm not sure I'd run, but that's all covered in my book.
Slide 66 shows an image of the Live Response tool...it looks very interesting, and I really wish I'd been able to make it to the conference. I really like what I see in the presentation, overall...Kevin evidently went over several things (at least, in the slides) that I've been thinking about for some time now, such as the fact that live response is evolving due to the notification laws, with California's SB1386 being one of the first. In essence, companies need to know if client data has been compromised in anyway.
Thoughts? Where do we go from here? Is live response viable, particularly on Windows systems?
Thursday, January 26, 2006
In search of...
No, this isn't a flashback to that old Leonard Nimoy show...it's about training. I got an email last night (don't have permission yet to say from whom) that pointed me to CERT's Virtual Training Environment. It's an online classroom, of sorts, where you can go, select a class, and watch it.
So I checked it out this morning. I went to the "Welcome to VTE" page, and clicked on "Launch VTE". Within seconds, I was looking at a list of topics. I saw "Forensics and Incident Response" and dove right in!
Once the choices of "classes" appeared, I saw that I could choose from documents, demos, and labs. What you get when you run one of the demos is basically a movie. Someone has a screen capture utility running while they narrate what they're doing, and they walk through things. The first one I looked at was "Analyzing Log Files with Notepad". It was pretty basic, but also pretty straightforward and really easy to follow.
There were a lot of other demos available, not all for Windows...there are some for Linux, as well. What I found most interesting, though, is that there is a "Configuration and Setup of the FCU" demo (it's my FRU, just misspelled), and a "Configuration and Setup of the FSP" module!
There's quite a bit of info at this site. The "Forensics" topic includes demos on EnCase, Autopsy, the use of dd, etc. It's very informative...take a look when you get a chance.
So I checked it out this morning. I went to the "Welcome to VTE" page, and clicked on "Launch VTE". Within seconds, I was looking at a list of topics. I saw "Forensics and Incident Response" and dove right in!
Once the choices of "classes" appeared, I saw that I could choose from documents, demos, and labs. What you get when you run one of the demos is basically a movie. Someone has a screen capture utility running while they narrate what they're doing, and they walk through things. The first one I looked at was "Analyzing Log Files with Notepad". It was pretty basic, but also pretty straightforward and really easy to follow.
There were a lot of other demos available, not all for Windows...there are some for Linux, as well. What I found most interesting, though, is that there is a "Configuration and Setup of the FCU" demo (it's my FRU, just misspelled), and a "Configuration and Setup of the FSP" module!
There's quite a bit of info at this site. The "Forensics" topic includes demos on EnCase, Autopsy, the use of dd, etc. It's very informative...take a look when you get a chance.
Wednesday, January 25, 2006
Cool Magazines
Recently, with the demise of Phrack, I've run across a couple of very interesting online magazines, or e-zines.
From Richard Bejtlich's TaoSecurity blog, the Uniformed, and the CodeBreaker's Journal. I haven't really taken the time to dig into either of these, but on the surface, they look like promising technical e-zines.
I ran across CheckMate today...pretty interesting first issue. This e-zine specifically targets computer forensics and incident response, and looks as if it may be a pretty good read. I went through one of the first articles on examining a user's browsing activities, and it provided pretty thorough coverage of the topic. One of the things I like most about the article is that it gave the reader information on how to interpret what they saw, rather than just pointing the reader to tools.
Know of any others?
From Richard Bejtlich's TaoSecurity blog, the Uniformed, and the CodeBreaker's Journal. I haven't really taken the time to dig into either of these, but on the surface, they look like promising technical e-zines.
I ran across CheckMate today...pretty interesting first issue. This e-zine specifically targets computer forensics and incident response, and looks as if it may be a pretty good read. I went through one of the first articles on examining a user's browsing activities, and it provided pretty thorough coverage of the topic. One of the things I like most about the article is that it gave the reader information on how to interpret what they saw, rather than just pointing the reader to tools.
Know of any others?
Tuesday, January 24, 2006
"Ooops, I did it again..."
No, this isn't a post about what would be on my iPod if I had one...it's even better.
Recently, the NSA posted a document entitled, "Redacting with Confidence: How to Safely Publish Sanitized Reports Converted From Word to PDF". I downloaded the document, because, well...I like metadata. I decided to see what metadata is in the PDF itself, and found this:
Title -> Redacting with Confidence: How to Safely Publish Sanitized Reports Converted from Word to PDF
Author -> SNAC
CreationDate -> D:20060110111526Z
ModDate -> D:20060120090543-05'00'
Creator -> activePDF DocConverter
Keywords -> word, pdf, redaction, metadata
Producer -> 5D PDFLib
Subject -> I333-015R-2005
Very nice. I pulled this out of the document using the pdfmeta.pl script listed on page 254 of my book.
Recently, the NSA posted a document entitled, "Redacting with Confidence: How to Safely Publish Sanitized Reports Converted From Word to PDF". I downloaded the document, because, well...I like metadata. I decided to see what metadata is in the PDF itself, and found this:
Title -> Redacting with Confidence: How to Safely Publish Sanitized Reports Converted from Word to PDF
Author -> SNAC
CreationDate -> D:20060110111526Z
ModDate -> D:20060120090543-05'00'
Creator -> activePDF DocConverter
Keywords -> word, pdf, redaction, metadata
Producer -> 5D PDFLib
Subject -> I333-015R-2005
Very nice. I pulled this out of the document using the pdfmeta.pl script listed on page 254 of my book.
Thursday, January 12, 2006
The need for IR training
This ComputerWorld article caught my eye this morning...I've done vulnerability assessments before, and I fully agree with all of these mistakes. They do, in fact, occur.
Each of the mistakes has earned it's rightful place in precedence. I started doing vulnerability scanning, commercially, in 1997. This has always included much more than simply running a scanning tool, but what occurred then continues today...we'd deliver our report, and most customers would thank us...and that was it. In some very few cases, some of the issues would be fixed, but mostly due to infrastructure changes, upgrades, etc.
The big one that jumps out at me know, though is number 5 - "Being unprepared for the unknown". To me, this is an issue of being prepared for incidents. The real world has all sorts of incident response capability. I've been on plains with rescue dogs that go to Washington, DC, once a year for testing...they'd been involved in the 9/11 search and rescue, and their condition is being tracked for any signs of health issues. We see cops and firefighters on the news. Ever hear of "smoke jumpers"? Heck, even the military is an "incident response capability" in and of itself.
So look around your IT shop right now. What's your incident response capability? If you're reading this, it's probably you. Are you prepared? How do you recognize or receive notification that an incident has occurred? Is it based on known signatures?
Are you prepared for zero-day exploits?
And don't think for an instant that you can't be prepared for these. I know what some of you are saying, that by definition, one can't be prepared for a "zero-day", because it isn't known. Well, I'm hear to tell you...you're wrong. You're prepared if you know that not all malware processes appear in the Task Manager as "danger.exe" or "malware.exe". Do you know how to get more information about processes, about what's running on a system? Can you triage a system? Can you gather specific information from a system, so that you (or someone else) has a fairly complete snapshot of what's going on and can at least begin to figure out what's going on?
Here's another consideration...what do you watch at night? Are you a CSI fan? How about House? Watch a couple episodes of House and start thinking about how you'd perform a "differential diagnosis" of a system.
Looking at the ComputerWorld article one last time, I guess, in a way, my mind ties all of the mistakes back to training issues and misconceptions...chicken. Egg.
Each of the mistakes has earned it's rightful place in precedence. I started doing vulnerability scanning, commercially, in 1997. This has always included much more than simply running a scanning tool, but what occurred then continues today...we'd deliver our report, and most customers would thank us...and that was it. In some very few cases, some of the issues would be fixed, but mostly due to infrastructure changes, upgrades, etc.
The big one that jumps out at me know, though is number 5 - "Being unprepared for the unknown". To me, this is an issue of being prepared for incidents. The real world has all sorts of incident response capability. I've been on plains with rescue dogs that go to Washington, DC, once a year for testing...they'd been involved in the 9/11 search and rescue, and their condition is being tracked for any signs of health issues. We see cops and firefighters on the news. Ever hear of "smoke jumpers"? Heck, even the military is an "incident response capability" in and of itself.
So look around your IT shop right now. What's your incident response capability? If you're reading this, it's probably you. Are you prepared? How do you recognize or receive notification that an incident has occurred? Is it based on known signatures?
Are you prepared for zero-day exploits?
And don't think for an instant that you can't be prepared for these. I know what some of you are saying, that by definition, one can't be prepared for a "zero-day", because it isn't known. Well, I'm hear to tell you...you're wrong. You're prepared if you know that not all malware processes appear in the Task Manager as "danger.exe" or "malware.exe". Do you know how to get more information about processes, about what's running on a system? Can you triage a system? Can you gather specific information from a system, so that you (or someone else) has a fairly complete snapshot of what's going on and can at least begin to figure out what's going on?
Here's another consideration...what do you watch at night? Are you a CSI fan? How about House? Watch a couple episodes of House and start thinking about how you'd perform a "differential diagnosis" of a system.
Looking at the ComputerWorld article one last time, I guess, in a way, my mind ties all of the mistakes back to training issues and misconceptions...chicken. Egg.
Wednesday, January 11, 2006
What is "security"??
Good question. We each approach topics like this differently, based on our background, experiences, etc. This thread on Slashdot caught my eye this morning, as did Brian Kreb's latest blog entry on SecurityFix (careful folks, it's a long blog entry, but an excellent read nonetheless).
My background in security started with pen-tests, war-dialing, and vulnerability assessments. I've also done policy development, etc. I've had a hand in incident response and forensics, as well. This is very different from Bill Gate's background...so we view security differently. The Microsoft stance has been to support better security practices and there have been intiatives with regards to security...so in light of things like SoBig, CodeRed, Nimda, and the more recent WMF issues, can we say that Micrsofot has failed?
Before giving you my thoughts, let me tell you about something that happened to me back on '00. I was working at a now-defunct telecomm company, as part of the corporate security staff. There was a rogue group of guys who claimed that they had security responsibilities, but you could never really tie them down...they were like kids who were told to not to do something, but they did it anyway. So, at one point, one of the guys from the team comes over and tells me how his group had identified an issue and confiscated a system. When they confronted the employee (without the presence of or even notifying HR, BTW...), the employee denied any knowledge of the issue. So these guys hired an outside consulting firm to come in and do forensic analysis of the hard drive...and the tasking they gave was to locate any files specific to the SubSeven Trojan/backdoor. That's it.
So this guy tells me that he looked at the hard drive and found a hidden DOS partition. He told me that we shouldn't deal with this company b/c in his mind, they didn't know what they were doing.
We (my boss and I) sat down and talked to the forensic analyst from the company. He showed us the tasking, and their final report. The documents clearly stated that the sole tasking was to locate files associated with SubSeven, which the company did (and to be honest, pretty much anyone could have done at the time).
So the question is, did the company "fail" or perform poorly? The analyst said that he'd identified the hidden DOS partition, but that partition did not contain the files in question. Since it wasn't part of the tasking, and the company was never given any information regarding the overall case or issue, they provided what they were asked for.
Now, back to the issue with Microsoft. I think what this all boils down to is a matter of expectations. When someone high up the food chain within Microsoft gets up on stage, most of the security guys in the audience hear "blahblahblahsecurityblahblah". They then fill in the gaps surrounding "security" with their own expectations, and feel justified pointing out failures. But wait a second...had they listened to the speaker, they might have heard him (or her) set those expectations and define "success" in their own context.
So, on the one hand, you can look at what Microsoft has done to improve security with things like a firewall for XP, and IIS 6.x functionality that's "off" by default as successful steps toward better "security". But does the recent WMF exploit issue really show that Microsoft has failed overall? Perhaps not. Microsoft's stance seems to be, "yeah, we know that this issue has been around since Windows 3.0, but there haven't been any publicly available exploits until now, and we had higher priority things to work on." Can you get mad at them for that? Really? I mean, don't we do the exact some thing everyday? Don't we have limited resources (time, money, etc.) and make decisions about what's important to us? How do we then feel when someone comes back to us and says that we "failed", but their determination of success is different from our own?
Maybe the approach that needs to be taken is different. Maybe what needs to happen is that more of Microsoft's customers need to get together and say, "hey, this stuff you've done is all well and good, but you know, malware, worms and rootkits are really kicking our butts...can you help us out?" Maybe if enough customers said this, Horton would hear the Who (NOT Roger Daltry). After all, haven't customers gotten Microsoft to redefine "success" before? Didn't someone from Microsoft say back in the early '90s that the Internet would never become what it has, in fact, become today?
My background in security started with pen-tests, war-dialing, and vulnerability assessments. I've also done policy development, etc. I've had a hand in incident response and forensics, as well. This is very different from Bill Gate's background...so we view security differently. The Microsoft stance has been to support better security practices and there have been intiatives with regards to security...so in light of things like SoBig, CodeRed, Nimda, and the more recent WMF issues, can we say that Micrsofot has failed?
Before giving you my thoughts, let me tell you about something that happened to me back on '00. I was working at a now-defunct telecomm company, as part of the corporate security staff. There was a rogue group of guys who claimed that they had security responsibilities, but you could never really tie them down...they were like kids who were told to not to do something, but they did it anyway. So, at one point, one of the guys from the team comes over and tells me how his group had identified an issue and confiscated a system. When they confronted the employee (without the presence of or even notifying HR, BTW...), the employee denied any knowledge of the issue. So these guys hired an outside consulting firm to come in and do forensic analysis of the hard drive...and the tasking they gave was to locate any files specific to the SubSeven Trojan/backdoor. That's it.
So this guy tells me that he looked at the hard drive and found a hidden DOS partition. He told me that we shouldn't deal with this company b/c in his mind, they didn't know what they were doing.
We (my boss and I) sat down and talked to the forensic analyst from the company. He showed us the tasking, and their final report. The documents clearly stated that the sole tasking was to locate files associated with SubSeven, which the company did (and to be honest, pretty much anyone could have done at the time).
So the question is, did the company "fail" or perform poorly? The analyst said that he'd identified the hidden DOS partition, but that partition did not contain the files in question. Since it wasn't part of the tasking, and the company was never given any information regarding the overall case or issue, they provided what they were asked for.
Now, back to the issue with Microsoft. I think what this all boils down to is a matter of expectations. When someone high up the food chain within Microsoft gets up on stage, most of the security guys in the audience hear "blahblahblahsecurityblahblah". They then fill in the gaps surrounding "security" with their own expectations, and feel justified pointing out failures. But wait a second...had they listened to the speaker, they might have heard him (or her) set those expectations and define "success" in their own context.
So, on the one hand, you can look at what Microsoft has done to improve security with things like a firewall for XP, and IIS 6.x functionality that's "off" by default as successful steps toward better "security". But does the recent WMF exploit issue really show that Microsoft has failed overall? Perhaps not. Microsoft's stance seems to be, "yeah, we know that this issue has been around since Windows 3.0, but there haven't been any publicly available exploits until now, and we had higher priority things to work on." Can you get mad at them for that? Really? I mean, don't we do the exact some thing everyday? Don't we have limited resources (time, money, etc.) and make decisions about what's important to us? How do we then feel when someone comes back to us and says that we "failed", but their determination of success is different from our own?
Maybe the approach that needs to be taken is different. Maybe what needs to happen is that more of Microsoft's customers need to get together and say, "hey, this stuff you've done is all well and good, but you know, malware, worms and rootkits are really kicking our butts...can you help us out?" Maybe if enough customers said this, Horton would hear the Who (NOT Roger Daltry). After all, haven't customers gotten Microsoft to redefine "success" before? Didn't someone from Microsoft say back in the early '90s that the Internet would never become what it has, in fact, become today?
Thursday, January 05, 2006
How are you spending your security dollars?
I was reading some comments on another blog today, and one comment in particular caught my eye. A retired CIO lamented the fact that "millions of dollars" were spent providing security to Windows systems...but he put a Mac on the network and never had a problem. Yeah, you read it right..."millions", with an M.
Ugh. My dooty detector goes off, screaming like a banshee, whenever a C-level executive makes comments like that. No, I'm not going to break things down to a para-religious argument over who's OS is better. That's not where I'm going with this one. What I am leading to here is, this sounds like a training issue to me. It sounds like the knowledge level of the IT staff has...shall we say...room for improvement.
Now, I have no doubt that there are some really bright, very knowledgeable IT guys and gals out there, so if this doesn't apply to you, feel free to leave the room.
I was a security weenie at a company once, and the senior admin guy had a bunch of guys working for him. The senior admin guy went to his desktop support guy, a legitimate Dude Among Dudes, and told him, "we can't promote you to an administrator, like I promised, until you get your MCSE." I heard that and thought it was funny...not laughing funny, but "here, try this, it tastes like crap" funny...because none of the current IT administrator staff had an MCSE. Yep, you read that right..."none", with an N.
My point of all this is that this Dude, who'd helped me with virus eradication, was knowledgeable and had a good head on his shoulders (and still does). The admins who wouldn't let him play in their reindeer games, botched pretty much every incident they responded to, had no documentation and had no network diagram. They didn't even know where the egress points were...the ones that bypassed the firewall...even though they'd set them up.
Okay, getting back on track here...where was I? Oh, yeah...training. My thought is this...when it comes to securing any network, regardless of operating systems and applications, you need to start with documentation. If you don't have it, then getting it is going to be a very necessary exercise. This is a good place to start when identifying your risks. Why? Because you have to know what your risks are so that you can start mitigating them...right?
What I'm getting at here is that spending "millions of dollars" to secure Windows systems probably wasn't necessary. If you don't know what you're doing, then of course trying to secure a network is going to be expensive. I simply think that that kind of money would be better spent on things like hiring better qualified personnel, and training the ones you have.
Oh, one other thing...if you're reading this blog entry, then let me throw this out. There are training opportunities available from a variety of sources, at a variety of price points. But what would you say if you could get your entire staff (like, 12 - 20 people) training, with that training targetted to your needs (for your environment), for less than it takes to send 2 or 3 people away to some of the bigger training events? How about if that training led to follow-on training and services that continued to apply specifically to your needs? Would you be interested in something like this?
Ugh. My dooty detector goes off, screaming like a banshee, whenever a C-level executive makes comments like that. No, I'm not going to break things down to a para-religious argument over who's OS is better. That's not where I'm going with this one. What I am leading to here is, this sounds like a training issue to me. It sounds like the knowledge level of the IT staff has...shall we say...room for improvement.
Now, I have no doubt that there are some really bright, very knowledgeable IT guys and gals out there, so if this doesn't apply to you, feel free to leave the room.
I was a security weenie at a company once, and the senior admin guy had a bunch of guys working for him. The senior admin guy went to his desktop support guy, a legitimate Dude Among Dudes, and told him, "we can't promote you to an administrator, like I promised, until you get your MCSE." I heard that and thought it was funny...not laughing funny, but "here, try this, it tastes like crap" funny...because none of the current IT administrator staff had an MCSE. Yep, you read that right..."none", with an N.
My point of all this is that this Dude, who'd helped me with virus eradication, was knowledgeable and had a good head on his shoulders (and still does). The admins who wouldn't let him play in their reindeer games, botched pretty much every incident they responded to, had no documentation and had no network diagram. They didn't even know where the egress points were...the ones that bypassed the firewall...even though they'd set them up.
Okay, getting back on track here...where was I? Oh, yeah...training. My thought is this...when it comes to securing any network, regardless of operating systems and applications, you need to start with documentation. If you don't have it, then getting it is going to be a very necessary exercise. This is a good place to start when identifying your risks. Why? Because you have to know what your risks are so that you can start mitigating them...right?
What I'm getting at here is that spending "millions of dollars" to secure Windows systems probably wasn't necessary. If you don't know what you're doing, then of course trying to secure a network is going to be expensive. I simply think that that kind of money would be better spent on things like hiring better qualified personnel, and training the ones you have.
Oh, one other thing...if you're reading this blog entry, then let me throw this out. There are training opportunities available from a variety of sources, at a variety of price points. But what would you say if you could get your entire staff (like, 12 - 20 people) training, with that training targetted to your needs (for your environment), for less than it takes to send 2 or 3 people away to some of the bigger training events? How about if that training led to follow-on training and services that continued to apply specifically to your needs? Would you be interested in something like this?
New NIST document (draft)
I was reviewing the updated E-evidence.info site this morning, and one of the interesting things I came across was the draft NIST SP800-86, Guide to Computer and Network Data Analysis: Applying Forensic Techniques to Incident Response.
As I read through the document for the first time, it's clear that this is a great place to start. From my perspective, I'm glad to see a short, 2 paragraph discussion of NTFS alternate data streams on page 4-5 of the document. The author's did provide footnotes with links to URLs for more information. There's also a section on collecting volatile data from systems.
It's a good resource, that's for sure. Take a look when you get a chance.
As I read through the document for the first time, it's clear that this is a great place to start. From my perspective, I'm glad to see a short, 2 paragraph discussion of NTFS alternate data streams on page 4-5 of the document. The author's did provide footnotes with links to URLs for more information. There's also a section on collecting volatile data from systems.
It's a good resource, that's for sure. Take a look when you get a chance.
Tuesday, December 27, 2005
The Mystery of MUICache...solved??
Holy Registry keys, Batman!
Okay, I've been tossing this around for a while, and even put it on the back burner, but never completely forgot about it. The issue is this MUICache Registry key, or more specifically:
HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache
This is an issue, as a while back, I started noticing references to malware creating values beneath this key...specifically, Trojan-Alexmo and Adware-BlowSearch. The technical write ups simply stated that the keys were created, but gave no indication as to their use. Was this a new startup location that malware authors had discovered? What is the key used for? I did some searches, but found way too much information to wade through and digest. I posted questions, but didn't get responses.
So, I'm over on ForensicFocus today, and "Lance" (I'm assuming this is the Guidance Lance) says something about the MUICache key values that point executables having window names as their values. You know, when you open up the command prompt on XP, for example, it says "Command Prompt" as the title (Trivia Question: Does anyone remember how to change that title in a DOS batch file, so something other than "Command Prompt" appears??) of the window. Well, I opened up my RegEdit and took a look at the entries under the key. I took a close look at some of the values that pointed to executables, and tried opening some. I began to see that the information in the Registry wasn't what I was seeing as the window titles.
So then I fired up Perl, and ran a script that I use that retrieves file version information from executables (ie, EXE, DLL, etc.). Lo and behold, but there under the FileDescription value, was the string that I was looking at in the Registry!
So, what does this mean? Well, I started doing searches for "Muicache + filedescription" and I found this archived entry from the OldNewThing blog. From there, I found others...in particular, this one from the Sun Java forum.
From reading through these entries, my understanding of this issue is that the values that you see under the MUICache key are not placed there by the executable, but by the shell (ie, Explorer.exe). Therefore, when a technical description of malware states that the executable "creates an entry under the MUICache key", this isn't technically correct. In fact, what's happening is that the shell is creating the entry when the malware is run.
From the forensic analysis aspect of things, how does this help us? Well, it shows that an application was run on an XP (I don't have a Win2k system to test right now) system at some point, whether the executable is there or not. However, we don't know when the application was run, as there is no MRUList associated with the entries. One indicator may be a corresponding entry for the executable in the PreFetch directory.
Well, it would seem that the veil of secrecy on that particular issue has been pierced...at least, to a degree. There are still questions, such as, is there a limit on the number of entries in this key?
Also, there needs to be some testing done. For example, if someone gets a Trojan on a system, and gets the user to launch it somehow, one would think that an entry would appear beneath the key. However, if the attacker were able to get another executable on the system, and launch it via the Trojan (something as simple as a netcat listener would suffice for testing), would an entry be made for that second executable? It would stand to reason that malware that runs as a service wouldn't appear in this entry, because such applications are not tied usually tied to an interactive user's account.
Thoughts?
Addendum 30 Dec: In case it wasn't clear, one of the points to my entry is that at least on A/V vendor had done "analysis" of some of the new malware (linked) and found that one of the changes that occurred on the system was that values were added to the MUICache key. Googling for this kind of thing reveals "analyses" at other A/V sites that include equally vague information. However, it seems that this key is NOT, in fact, set by the malware in question but instead by the shell.
So, as an aside, whom do you trust when it comes to this kind of analysis?
Okay, I've been tossing this around for a while, and even put it on the back burner, but never completely forgot about it. The issue is this MUICache Registry key, or more specifically:
HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache
This is an issue, as a while back, I started noticing references to malware creating values beneath this key...specifically, Trojan-Alexmo and Adware-BlowSearch. The technical write ups simply stated that the keys were created, but gave no indication as to their use. Was this a new startup location that malware authors had discovered? What is the key used for? I did some searches, but found way too much information to wade through and digest. I posted questions, but didn't get responses.
So, I'm over on ForensicFocus today, and "Lance" (I'm assuming this is the Guidance Lance) says something about the MUICache key values that point executables having window names as their values. You know, when you open up the command prompt on XP, for example, it says "Command Prompt" as the title (Trivia Question: Does anyone remember how to change that title in a DOS batch file, so something other than "Command Prompt" appears??) of the window. Well, I opened up my RegEdit and took a look at the entries under the key. I took a close look at some of the values that pointed to executables, and tried opening some. I began to see that the information in the Registry wasn't what I was seeing as the window titles.
So then I fired up Perl, and ran a script that I use that retrieves file version information from executables (ie, EXE, DLL, etc.). Lo and behold, but there under the FileDescription value, was the string that I was looking at in the Registry!
So, what does this mean? Well, I started doing searches for "Muicache + filedescription" and I found this archived entry from the OldNewThing blog. From there, I found others...in particular, this one from the Sun Java forum.
From reading through these entries, my understanding of this issue is that the values that you see under the MUICache key are not placed there by the executable, but by the shell (ie, Explorer.exe). Therefore, when a technical description of malware states that the executable "creates an entry under the MUICache key", this isn't technically correct. In fact, what's happening is that the shell is creating the entry when the malware is run.
From the forensic analysis aspect of things, how does this help us? Well, it shows that an application was run on an XP (I don't have a Win2k system to test right now) system at some point, whether the executable is there or not. However, we don't know when the application was run, as there is no MRUList associated with the entries. One indicator may be a corresponding entry for the executable in the PreFetch directory.
Well, it would seem that the veil of secrecy on that particular issue has been pierced...at least, to a degree. There are still questions, such as, is there a limit on the number of entries in this key?
Also, there needs to be some testing done. For example, if someone gets a Trojan on a system, and gets the user to launch it somehow, one would think that an entry would appear beneath the key. However, if the attacker were able to get another executable on the system, and launch it via the Trojan (something as simple as a netcat listener would suffice for testing), would an entry be made for that second executable? It would stand to reason that malware that runs as a service wouldn't appear in this entry, because such applications are not tied usually tied to an interactive user's account.
Thoughts?
Addendum 30 Dec: In case it wasn't clear, one of the points to my entry is that at least on A/V vendor had done "analysis" of some of the new malware (linked) and found that one of the changes that occurred on the system was that values were added to the MUICache key. Googling for this kind of thing reveals "analyses" at other A/V sites that include equally vague information. However, it seems that this key is NOT, in fact, set by the malware in question but instead by the shell.
So, as an aside, whom do you trust when it comes to this kind of analysis?
Friday, December 23, 2005
Registry Reference
I've been working away on a Registry reference, basically, an Excel spreadsheet of Registry keys. The idea is to list them with some sort of categorization, listing each by key name/path, value (if applicable), a brief description, and then any references that may apply.
In the case of what I'm working on, most of the references so far are MS KB articles that describe the keys and/or values.
The descriptions are meant to provide information regarding how these keys/values are useful during forensic investigations. Many of them can also be useful during live response investigations, as well.
Work is coming along smoothly...oddly enough there isn't a great deal of this sort of information out there. I've been pointed to several resources, and in most cases they lead back to either my original spreadsheet, or stuff from AccessData.
In the case of what I'm working on, most of the references so far are MS KB articles that describe the keys and/or values.
The descriptions are meant to provide information regarding how these keys/values are useful during forensic investigations. Many of them can also be useful during live response investigations, as well.
Work is coming along smoothly...oddly enough there isn't a great deal of this sort of information out there. I've been pointed to several resources, and in most cases they lead back to either my original spreadsheet, or stuff from AccessData.
Thursday, December 22, 2005
The age of "Nintendo forensics"...
...is coming to a close. Or, rather, it needs to. Looking around, seeing what's going on in the community, and in particular, in the news, I have to think that the days of blindly imaging a system and then running searches for keywords or images are going to be a thing of the past soon.
Windows systems in particular hold a wealth of information. There are areas of systems that are largely unexplored by many forensic analysts, particularly on the law enforcement side of the house. Now, I know that this is in large part due to case loads, staffing, training, and simply time. However, more knowledgeable law enforcement officers (at all levels...local, state, and even federal) as well as more knowledgeable system administrators (and even CIOs) will serve to level the playing field between the good guys and the bad guys.
What am I talking about? I'm talking about the fact that Windows XP and 2003 are becoming more prevalent by the day, and soon Vista will be in production and on the streets. We (the forensic community) can no longer operate from an MS-DOS standpoint.
Don't get me wrong...data reduction through the use of searches, file hashes, etc., is still extremely useful. However, a search for an ASCII string may turn up very little when searching the Windows Registry. One needs to understand the format of the Registry (even on the binary level) and how the Registry is structured. The same holds true with other file formats...OLE/compound documents (MS Word being the most prevalent example), PE files, Event Log files, INFO2 files, and even shortcuts. Yes, there are tools that can be run to pull information from the files but does the person running the tool understand what's happening "under the hood"?
Now, some of you are going to say, "Hey, I don't need to know how to locate and program the computer systems in my car in order to drive a car.", and I'd say, "You're right." However, what I'm talking about is pulling more comprehensive information from an image of a Windows system, and building a better case. In the face of more sophisticated malware, the expanding use of rootkits, and the increase of publicized anti-forensic techniques, I'm beginning to see how a greater level of knowledge is necessary.
Windows systems in particular hold a wealth of information. There are areas of systems that are largely unexplored by many forensic analysts, particularly on the law enforcement side of the house. Now, I know that this is in large part due to case loads, staffing, training, and simply time. However, more knowledgeable law enforcement officers (at all levels...local, state, and even federal) as well as more knowledgeable system administrators (and even CIOs) will serve to level the playing field between the good guys and the bad guys.
What am I talking about? I'm talking about the fact that Windows XP and 2003 are becoming more prevalent by the day, and soon Vista will be in production and on the streets. We (the forensic community) can no longer operate from an MS-DOS standpoint.
Don't get me wrong...data reduction through the use of searches, file hashes, etc., is still extremely useful. However, a search for an ASCII string may turn up very little when searching the Windows Registry. One needs to understand the format of the Registry (even on the binary level) and how the Registry is structured. The same holds true with other file formats...OLE/compound documents (MS Word being the most prevalent example), PE files, Event Log files, INFO2 files, and even shortcuts. Yes, there are tools that can be run to pull information from the files but does the person running the tool understand what's happening "under the hood"?
Now, some of you are going to say, "Hey, I don't need to know how to locate and program the computer systems in my car in order to drive a car.", and I'd say, "You're right." However, what I'm talking about is pulling more comprehensive information from an image of a Windows system, and building a better case. In the face of more sophisticated malware, the expanding use of rootkits, and the increase of publicized anti-forensic techniques, I'm beginning to see how a greater level of knowledge is necessary.
Visibility?
Posts have been sporadic, and not nearly as frequent as before...I know. That'll change.
For now, though, I've got a question for the readers...one that you can really help me with. Just about every month, I run across someone (usually online) who says, "I wish I knew more about this...". In the past, it was things like NTFS alternate data streams. More recently, it's been USB device artifacts in the Registry. The thing is, regardless of the topic, I will do a simple Google search and turn up some pretty good resources (if it's stuff I've done, I cheat a little and just send them the link).
So, my question is this...how do you make things more visible? Take information as an example. You write an article about something that may be very useful to a group of people. You get the article published in a magazine or journal that caters to that group of people. However, not everyone in that group gets the journal.
Things I've tried include presenting at conferences (and in the case of my book, giving away free copies after the presentation), writing articles, posting to online forums, talking to people, etc. Now, I'm not saying that that's all that can be done, or that I've done any of those things enough. What I am asking is, what are some things that I can do to market stuff I've done...not just books, but code and any other information that I develop/produce.
Thanks...thoughts and especially solutions are appreciated.
For now, though, I've got a question for the readers...one that you can really help me with. Just about every month, I run across someone (usually online) who says, "I wish I knew more about this...". In the past, it was things like NTFS alternate data streams. More recently, it's been USB device artifacts in the Registry. The thing is, regardless of the topic, I will do a simple Google search and turn up some pretty good resources (if it's stuff I've done, I cheat a little and just send them the link).
So, my question is this...how do you make things more visible? Take information as an example. You write an article about something that may be very useful to a group of people. You get the article published in a magazine or journal that caters to that group of people. However, not everyone in that group gets the journal.
Things I've tried include presenting at conferences (and in the case of my book, giving away free copies after the presentation), writing articles, posting to online forums, talking to people, etc. Now, I'm not saying that that's all that can be done, or that I've done any of those things enough. What I am asking is, what are some things that I can do to market stuff I've done...not just books, but code and any other information that I develop/produce.
Thanks...thoughts and especially solutions are appreciated.
Thursday, December 01, 2005
Registry Reference
One thing I've really noticed over the years is that while some information is available out there on some Registry keys and values, there really isn't much that is useful/credible and geared toward forensic analysis. So I've been considering starting up a reference resource...well, I brought the subject up on a couple of lists, mostly looking for input, and the overwhelming response was, "Great! Let me know what I can do to help."
I haven't really settled on a format, per se, outside of basic elements, such as key/value path, data type of the value(s), a description or explanation of the key/value and what conditions lead to the creation/modification of the key/value, credible references, and the name of the submitter. One thought I had was to list everything in HTML, making it easily portable. Another thought was to use a database of some sort, because in doing so, scripts can be written to search the database, or extract information into text, HTML, XML, etc....whatever format suits the user.
Again, the goal is to provide credible, referenced information about Registry keys, as Registry analysis is something that simply hasn't been explored up to this point...at least, not in any great depth.
If you've got any thoughts on this, let me know. And yes, I am aware of the paper AccessData put out...thanks.
I haven't really settled on a format, per se, outside of basic elements, such as key/value path, data type of the value(s), a description or explanation of the key/value and what conditions lead to the creation/modification of the key/value, credible references, and the name of the submitter. One thought I had was to list everything in HTML, making it easily portable. Another thought was to use a database of some sort, because in doing so, scripts can be written to search the database, or extract information into text, HTML, XML, etc....whatever format suits the user.
Again, the goal is to provide credible, referenced information about Registry keys, as Registry analysis is something that simply hasn't been explored up to this point...at least, not in any great depth.
If you've got any thoughts on this, let me know. And yes, I am aware of the paper AccessData put out...thanks.
Tuesday, November 01, 2005
Finding a rootkit
Mark Russinovich over on SysInternals.com posted a blog entry yesterday about how he located a rootkit that was installed after he purchased a CD.
One has to raise the "HUH??!?!" flag (those are the three letters I chose, but I'm sure that there are other blog posts out there on this subject that will be brought to you by the letters "W", "T", and "F"...) on this one.
The SANS Internet Storm Center picked it up, as well. So did F-Secure, and they have their own technical description here.
So...imagine if you will...not only are you looking over your shoulder with regards to the bad guys and malcode, but now you have to be careful of the legitimate guys, as well. Sony is legitimate, right? What happens if a worm comes out that doesn't have its own rootkit payload (there was a worm for AIM recently that did), but instead looks for the presence of a commercial DRM rootkit, and hides itself that way? What will that worm be called? "W32.SonyPiggyback"?
Face it folks...do a search on SARC for "rootkit" and see how many entries you find over last year. Ouch!
Addendum 3 Nov: I generally try to stay on-track in this space, my blog...keeping on topic with regards to forensic analysis of Windows systems. However, I have to say that Wired really has it wrong. Specifically, "But in our view, the hacker and virus threat is something of a red herring...". Red herring? How so? The article goes on to say, "Sony may even have committed a crime under the U.S. Computer Fraud and Abuse Act...".
Wow. The EULA doesn't specifically state that its installing a rootkit, but given the knee-jerk reactions of most folks, is anyone really surprised? After all, it was just last February that Microsoft hit the stage of the RSA Conference, full of sound and fury over rootkits, but signifying nothing. So they bring something that's been around for a while to the forefront of attention...and because Microsoft said it, the media jumps all over it. And guess what? There are even courses you can take in writing rootkits. So...someone in Sony is trying to figure out how to protect their "property", and look what they stumble across.
Should Sony be faulted for what they did...perhaps. Should they be faulted more so than other companies (a company is a business, remember...a real-world construct designed to make money) who've taken "extreme" measures that end up making self-righteous folks indignant?
I'm not making a call on that. What I am concerned about is the number of folks out there who've installed this stuff, and suddenly there are a whole bunch of other files on the system with the same prefix (in this case, "$sys$"). I'm concerned about the first worm that does a check for the Sony stuff...why download your own stealth technology when there's already a perfectly good one on the system.
Okay, enough of that. Brian Krebs picked up on this and blogged...if you have a few minutes, scroll through some of the responses. Maybe you'll feel moved to leave a comment...
One has to raise the "HUH??!?!" flag (those are the three letters I chose, but I'm sure that there are other blog posts out there on this subject that will be brought to you by the letters "W", "T", and "F"...) on this one.
The SANS Internet Storm Center picked it up, as well. So did F-Secure, and they have their own technical description here.
So...imagine if you will...not only are you looking over your shoulder with regards to the bad guys and malcode, but now you have to be careful of the legitimate guys, as well. Sony is legitimate, right? What happens if a worm comes out that doesn't have its own rootkit payload (there was a worm for AIM recently that did), but instead looks for the presence of a commercial DRM rootkit, and hides itself that way? What will that worm be called? "W32.SonyPiggyback"?
Face it folks...do a search on SARC for "rootkit" and see how many entries you find over last year. Ouch!
Addendum 3 Nov: I generally try to stay on-track in this space, my blog...keeping on topic with regards to forensic analysis of Windows systems. However, I have to say that Wired really has it wrong. Specifically, "But in our view, the hacker and virus threat is something of a red herring...". Red herring? How so? The article goes on to say, "Sony may even have committed a crime under the U.S. Computer Fraud and Abuse Act...".
Wow. The EULA doesn't specifically state that its installing a rootkit, but given the knee-jerk reactions of most folks, is anyone really surprised? After all, it was just last February that Microsoft hit the stage of the RSA Conference, full of sound and fury over rootkits, but signifying nothing. So they bring something that's been around for a while to the forefront of attention...and because Microsoft said it, the media jumps all over it. And guess what? There are even courses you can take in writing rootkits. So...someone in Sony is trying to figure out how to protect their "property", and look what they stumble across.
Should Sony be faulted for what they did...perhaps. Should they be faulted more so than other companies (a company is a business, remember...a real-world construct designed to make money) who've taken "extreme" measures that end up making self-righteous folks indignant?
I'm not making a call on that. What I am concerned about is the number of folks out there who've installed this stuff, and suddenly there are a whole bunch of other files on the system with the same prefix (in this case, "$sys$"). I'm concerned about the first worm that does a check for the Sony stuff...why download your own stealth technology when there's already a perfectly good one on the system.
Okay, enough of that. Brian Krebs picked up on this and blogged...if you have a few minutes, scroll through some of the responses. Maybe you'll feel moved to leave a comment...
Wednesday, October 26, 2005
Peeking inside Word documents
I was chatting with someone yesterday who asked me where I found the files I used to test the Word Metadata Dumper, and I simply said, "Google."
Yep, that's right...I just Googled for Word documents from the .mil domain, as well as the .gov domain. Wanna know how to search Google for all sorts of other goodies? Check out Johnny Long's web site, or grab a copy of his book on "Google hacking".
Want to get a little up-close-and-personal with someone else, maybe even someone else you don't know? Remember the "Extreme File Sharing" post from Security Fix? I'd tried it and found some of the very same things...files left behind by malware with keylogger capability, etc.
Yep, that's right...I just Googled for Word documents from the .mil domain, as well as the .gov domain. Wanna know how to search Google for all sorts of other goodies? Check out Johnny Long's web site, or grab a copy of his book on "Google hacking".
Want to get a little up-close-and-personal with someone else, maybe even someone else you don't know? Remember the "Extreme File Sharing" post from Security Fix? I'd tried it and found some of the very same things...files left behind by malware with keylogger capability, etc.
Tuesday, October 25, 2005
Sleuthkit on Windows
Hey, guess what I did last night!! I installed Sleuthkit and Autopsy on Windows XP!
For you Linux and *BSD gurus who felt a nauseating disturbance in the Force...it wasn't that burrito you had...it was me!
Okay, okay...it wasn't just me...I had help.
When I'm working with things on my home systems and looking at forensic analysis, I like to use ProDiscover to grab a dd image of a VMWare session, my thumb drive, etc. As it turns out, I had a 5GB image of an XP Pro system, so I copied that over to the evidence locker and fired up Autopsy. I didn't run completely through many of the things that I could have done, because it would take some time to do so...but as far as the things I did try, they worked great.
Don't have an image of your own to play with? Well, the instructions for installing Sleuthkit and Autopsy on Windows also has instructions for how to image a floppy drive...so, you can entertain and amaze your friends by recovering deleted files! Or, you can go to the Digitial Forensics Tool Testing site and grab an image or two to work with.
My hat's off to Brian Carrier, for having created these tools.
For you Linux and *BSD gurus who felt a nauseating disturbance in the Force...it wasn't that burrito you had...it was me!
Okay, okay...it wasn't just me...I had help.
When I'm working with things on my home systems and looking at forensic analysis, I like to use ProDiscover to grab a dd image of a VMWare session, my thumb drive, etc. As it turns out, I had a 5GB image of an XP Pro system, so I copied that over to the evidence locker and fired up Autopsy. I didn't run completely through many of the things that I could have done, because it would take some time to do so...but as far as the things I did try, they worked great.
Don't have an image of your own to play with? Well, the instructions for installing Sleuthkit and Autopsy on Windows also has instructions for how to image a floppy drive...so, you can entertain and amaze your friends by recovering deleted files! Or, you can go to the Digitial Forensics Tool Testing site and grab an image or two to work with.
My hat's off to Brian Carrier, for having created these tools.
Monday, October 24, 2005
Perl for Forensics
Perl is freely available, and Perl scripts are essentially open source. Perl is used by forensics products such as The Sleuthkit and ProDiscover. Perl is used in the Metasploit framework. Perl is great for automating repetitive tasks, parsing files...and it's free. Perl runs on Windows, most Unices, the Mac, and a plethora of other platforms.
O'Reilly has a ton of books on Perl...from how to program to how to use Perl for a variety of tasks.
So my question is, how useful would a book on using Perl for forensics be to you? Say, a reference tome that discusses:
O'Reilly has a ton of books on Perl...from how to program to how to use Perl for a variety of tasks.
So my question is, how useful would a book on using Perl for forensics be to you? Say, a reference tome that discusses:
- Collecting live/volatile data using Perl
- Correlating data from multiple sources using Perl
- Analyzing data, or presenting data for analysis
- Analyzing file formats (retrieving metadata, etc.)
Obviously, a book like this should include copies of all code used or mentioned in the book. As ProDiscover uses Perl as it's scripting language, a book such as this should also include a variety of "ProScripts". The book should also include not only the files analyzed in the book, but additional example files that the reader can explore and practice on...perhaps even an image of drive to examine.
Is this a book you'd be interested in? If so, what would you like to see? What topics do you think should be covered? How would you envision such a book, particularly as something that you'd pick up off of a shelf at a bookstore and decide to purchase? What do you see as the market for such a book?
Saturday, October 22, 2005
VMWare Playa
As a user of VMWare, I received an email the other day that mentioned a new, free product called the VMWare Player. This is a free product that allows you to play a single VMWare virtual machine on Windows or Linux (rpm and tar versions available for Linux). Very cool. Want to share tools, and other stuff that you may not have been able to share before? Want to try out Windows or Linux, but didn't want to shell out the almost $200 for VMWare Workstation?
VMWare also provides some pre-built virtual machines for you to download. What good is a player if you don't have something to play? One is a browser appliance, which you can use for safer web surfing.
This was also picked up by TaoSecurity, along with some comments from readers of that blog, and a link to a chart showing differences in functionality between the Player and other VMWare products.
VMWare also provides some pre-built virtual machines for you to download. What good is a player if you don't have something to play? One is a browser appliance, which you can use for safer web surfing.
This was also picked up by TaoSecurity, along with some comments from readers of that blog, and a link to a chart showing differences in functionality between the Player and other VMWare products.
Word metadata code posted
All,
I've posted the code that I mentioned in my previous post on Word metadata. This code produces the output seen in the blog entry.
The code is commented, including how to obtain the necessary modules if you're using ActiveState Perl. The PPM commands look like this:
ppm install OLE-Storage
ppm install Startup
ppm install Unicode-Map
Give the code a shot, and let me know what you think. As I said in my earlier post, I'm working on producing a standalone EXE via Perl2Exe, for Windows users.
I've posted the code that I mentioned in my previous post on Word metadata. This code produces the output seen in the blog entry.
The code is commented, including how to obtain the necessary modules if you're using ActiveState Perl. The PPM commands look like this:
ppm install OLE-Storage
ppm install Startup
ppm install Unicode-Map
Give the code a shot, and let me know what you think. As I said in my earlier post, I'm working on producing a standalone EXE via Perl2Exe, for Windows users.
Sunday, October 16, 2005
Yet, even more on Word metadata
While awaiting information on the binary format of shortcut (LNK) files, I decided to try to learn more about structured storage and metadata in Word documents. The best example I've seen of that describes some of the metadata in Word documents is available at the Computerbytesman site, and addresses an issue that Tony Blair's government had a while back. While I was researching my book, Richard Smith was kind enough to share his code for retrieving the last 10 author's for within the Word document with me. Since that time, I've thought about taking another look at the sort of metadata that one can retrieve from within a Word document.
I included a Perl script for retrieving Word metadata with my book. The code is on the CD that accompanies the book, in the code directory for chapter 3. The script is called "meta.pl" and uses the Win32::OLE module to create an instance of Word, and use the API to retrieve metadata. Well, as I've seen with the work that I did on reading Event Log files, the API doesn't always get everything. Also, I've been looking for something a little more platform-independant.
Thanks to Richard Smith, I dug into the OLE::Storage module a bit, and found exactly what I was looking for. First, a quick caveat...the POD for this module, as well as some of the supporting modules, is a bit out of date. However, by using some of the accompanying examples (such as ldat, written by Martin Schwartz, copyright '96-'97) and simply trying some things out, I was able to figure things out. So the script uses that module, and a couple of others...but only after it opens the file in binary mode to retrieve other information from the file.
Okay, on to the output. I started with the Blair document from the Computerbytesman site, and got the same information (I didn't include the VBA Macro information, though). I downloaded a couple of arbitrary Word documents from the Web, via Google, and found some interesting info:
--------------------
Statistics
--------------------
File = d:\cd\wd\04_007.doc
Size = 322560 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)
Document has picture(s).
Document was created on Windows.
Magic Created : MS Word 97
Magic Revised : MS Word 97
--------------------
Last Author(s) Info
--------------------
1 : Susan and Shawn Sutherland :
2 : Susan and Shawn Sutherland :
3 : Susan and Shawn Sutherland :
4 : Susan and Shawn Sutherland :
5 : picketb :
6 : padilld :
7 : ONR :
8 : John T. McCain :
9 : horvats :
10 : arbaizd :
--------------------
Summary Information
--------------------
Title : I
Subject :
Authress : PICKETB
LastAuth : arbaizd
RevNum : 2
AppName : Microsoft Word 10.0
Created : 08.12.2003, 16:11:00
Last Saved : 08.12.2003, 16:11:00
Last Printed : 08.12.2003, 16:11:00
--------------------
Document Summary Information
--------------------
Organization : Office of Naval Research
Pretty cool, eh? Again, I found this document on the web. From my previous post, I asked some folks to send me documents written on the Mac platform, and I received a couple. Here's what the output looks like:
--------------------
Statistics
--------------------
File = d:\cd\wd\ex1.doc
Size = 21504 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)
Document was created on a Mac.
File was last saved on a Mac.
Magic Created : Word 98 Mac
Magic Revised : Word 98 Mac
--------------------
Last Author(s) Info
--------------------
1 :
--------------------
Summary Information
--------------------
Title : The quick brown fox jumps over the lazy dog
Subject :
Authress : name
LastAuth : name
RevNum : 1
AppName : Microsoft Word 10.1
Created : 12.10.2005, 02:51:00
Last Saved : 12.10.2005, 02:58:00
Last Printed :
--------------------
Document Summary Information
--------------------
Organization :
Okay, I made a couple of obvious changes, but the point is that there is information within the binary contents of the file information block (FIB) that tells you the platform that a document was created on...for example, if it was created on a Mac, or on a Windows platform. Pretty cool, eh?
So...what do you think? I'll be posting the script soon, along with a couple of other scripts...for example, I'm going to include one that I used for troubleshooting, which simply writes all of the structured storage streams to files on the system. After all, MS describes structured storage as "a file system within a file", so wouldn't you like to see the contents of each of those files? I'm not entirely sure of the usefulness of this with regards to forensic analysis, but someone might find it useful.
An offshoot of all this involves the MergeStreams application (here's something I found at UTulsa) that I've used in some of my presentations. This application allows you to merge an Excel spreadsheet into a Word document, resulting in a much larger, but otherwise unchanged Word doc. However, if you change the resulting file's extension to ".xls", and double-click on it, you'll see the entire, unmodified contents of the spreadsheet. This is due to the streams being merged, and handled by the appropriate application (no, this is not steganography!!). Whenever I've presented on this, I've been asked how this sort of thing can be detected, and up until now, the only solutions I've been able to come up with have include the use of 'strings' and 'find'. With this module, however, you can dump the names of the streams from an OLE document, and if you see a stream named "Workbook" inside a Word document, you can be pretty sure that you've got an embedded document. This is a more accurate method than using 'strings'.
I'll be releasing the scripts soon...there are a couple of things I need to clean up, and I'm having a small issue with the compiled EXE version of the main script (above) that I'm trying to clear up.
I included a Perl script for retrieving Word metadata with my book. The code is on the CD that accompanies the book, in the code directory for chapter 3. The script is called "meta.pl" and uses the Win32::OLE module to create an instance of Word, and use the API to retrieve metadata. Well, as I've seen with the work that I did on reading Event Log files, the API doesn't always get everything. Also, I've been looking for something a little more platform-independant.
Thanks to Richard Smith, I dug into the OLE::Storage module a bit, and found exactly what I was looking for. First, a quick caveat...the POD for this module, as well as some of the supporting modules, is a bit out of date. However, by using some of the accompanying examples (such as ldat, written by Martin Schwartz, copyright '96-'97) and simply trying some things out, I was able to figure things out. So the script uses that module, and a couple of others...but only after it opens the file in binary mode to retrieve other information from the file.
Okay, on to the output. I started with the Blair document from the Computerbytesman site, and got the same information (I didn't include the VBA Macro information, though). I downloaded a couple of arbitrary Word documents from the Web, via Google, and found some interesting info:
--------------------
Statistics
--------------------
File = d:\cd\wd\04_007.doc
Size = 322560 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)
Document has picture(s).
Document was created on Windows.
Magic Created : MS Word 97
Magic Revised : MS Word 97
--------------------
Last Author(s) Info
--------------------
1 : Susan and Shawn Sutherland :
2 : Susan and Shawn Sutherland :
3 : Susan and Shawn Sutherland :
4 : Susan and Shawn Sutherland :
5 : picketb :
6 : padilld :
7 : ONR :
8 : John T. McCain :
9 : horvats :
10 : arbaizd :
--------------------
Summary Information
--------------------
Title : I
Subject :
Authress : PICKETB
LastAuth : arbaizd
RevNum : 2
AppName : Microsoft Word 10.0
Created : 08.12.2003, 16:11:00
Last Saved : 08.12.2003, 16:11:00
Last Printed : 08.12.2003, 16:11:00
--------------------
Document Summary Information
--------------------
Organization : Office of Naval Research
Pretty cool, eh? Again, I found this document on the web. From my previous post, I asked some folks to send me documents written on the Mac platform, and I received a couple. Here's what the output looks like:
--------------------
Statistics
--------------------
File = d:\cd\wd\ex1.doc
Size = 21504 bytes
Magic = 0xa5ec (Word 8.0)
Version = 193
LangID = English (US)
Document was created on a Mac.
File was last saved on a Mac.
Magic Created : Word 98 Mac
Magic Revised : Word 98 Mac
--------------------
Last Author(s) Info
--------------------
1 :
--------------------
Summary Information
--------------------
Title : The quick brown fox jumps over the lazy dog
Subject :
Authress : name
LastAuth : name
RevNum : 1
AppName : Microsoft Word 10.1
Created : 12.10.2005, 02:51:00
Last Saved : 12.10.2005, 02:58:00
Last Printed :
--------------------
Document Summary Information
--------------------
Organization :
Okay, I made a couple of obvious changes, but the point is that there is information within the binary contents of the file information block (FIB) that tells you the platform that a document was created on...for example, if it was created on a Mac, or on a Windows platform. Pretty cool, eh?
So...what do you think? I'll be posting the script soon, along with a couple of other scripts...for example, I'm going to include one that I used for troubleshooting, which simply writes all of the structured storage streams to files on the system. After all, MS describes structured storage as "a file system within a file", so wouldn't you like to see the contents of each of those files? I'm not entirely sure of the usefulness of this with regards to forensic analysis, but someone might find it useful.
An offshoot of all this involves the MergeStreams application (here's something I found at UTulsa) that I've used in some of my presentations. This application allows you to merge an Excel spreadsheet into a Word document, resulting in a much larger, but otherwise unchanged Word doc. However, if you change the resulting file's extension to ".xls", and double-click on it, you'll see the entire, unmodified contents of the spreadsheet. This is due to the streams being merged, and handled by the appropriate application (no, this is not steganography!!). Whenever I've presented on this, I've been asked how this sort of thing can be detected, and up until now, the only solutions I've been able to come up with have include the use of 'strings' and 'find'. With this module, however, you can dump the names of the streams from an OLE document, and if you see a stream named "Workbook" inside a Word document, you can be pretty sure that you've got an embedded document. This is a more accurate method than using 'strings'.
I'll be releasing the scripts soon...there are a couple of things I need to clean up, and I'm having a small issue with the compiled EXE version of the main script (above) that I'm trying to clear up.
Subscribe to:
Posts (Atom)