Would I be remiss if I were to NOT discuss future trends in computer forensics?
Every now and then you see the curious posting questions about future trends and challenges in the computer forensics field, and invariably, the responses include something do to with the increase in the density of storage media. For example, information was recently leaked from Seagate regarding 750GB drives. But is this really a "future trend"?
Think about it. Not long ago, those tasked with performing computer forensics were facing 100 or 200 MB drives...yes, "megabyte", with an M. Even today, larger capacity with smaller form facter is just something we deal with. So...if this is something we've been dealing with from the beginning, does it really constitute a "future trend"?
Rather than sitting back and being driven by the course of events, IMHO, forensic analysts need to be the driving force in the future trends within the community. Specifically, there needs to be a greater level of education. I know that this is very easy for me to say, sitting here at oh-dark thirty, blogging away. However, I sincerely believe that this is the case. Let me provide some background and perhaps illuminate what I'm referring to...
Computer systems are becoming ever-more sophisticated. The bad guys are, too. Things that used to be done for fun are now being done for profit, or revenge. The face of computer crime itself is changing. While computer forensic analysis techniques are changing, they aren't being updated at anywhere near the same rate as the techniques used by those who end up becoming the focus of an investigation. There are still many folks out there, tasked with performing computer forensics, who firmly believe (through their initial training) that a computer forensics investigation begins with unplugging the affected system, securing it, and imaging the hard drive.
But what happens when you do this? Think of the massive amounts of data that are lost when power is removed from a system. Think of fraud or sexual harassment investigation, in which data was stored on the clipboard. Think about the malware that only exists in memory. Personally, I'm reminded of a case from 2000 in which someone else determined that the SubSeven Trojan was on a system via a file search...after power had been removed from the system. Sure, the MAC times on the files would give the investigator some information, but no one could say for sure if (a) the backdoor was running when the system was unplugged, or (b) if a bad guy were connected to the backdoor, or (c) if the "suspect" was using connecting to another infected system somewhere on our corporate network.
One of the main techniques still in use today by forensic examiners is the keyword search. Don't get me wrong...there's nothing wrong with this technique...in fact, it's proven to be quite useful. However, it should be a tool, not the tool, in the investigator's toolbox. Keyword searches across file systems and sectors can be fruitful, but not everything is stored on a system in ASCII or Unicode. Take a look at the Windows Registry...many important pieces of information are stored in binary format, or via Rot-13 "encryption". Both of these will cause simple keyword searches to fail.
Another thing to think about is disk encryption software. Unplug the power and what are you left with? Okay, now think about it this way...if you acquired the system live, what would you be left with?
Lets get right to the point...perhaps there really is no "future trend" in computer forensics, but rather, we're going to simply be revisiting the same old trends that we've faced in the past. IMHO, I don't see increased storage density as a new issue...it's something we've had to deal with for a while. HOW we deal with it is what's going to change the face of forensic computing...greater education and training will drive forensic investigators to include live response techniques (live acquisition, volatile data collection and analysis, etc) in their "bag of tricks", AND allow them to be able to testify about these techniques and data in court.
One final note...there are those who say that they would never perform a live investigation until there's case law and court decisions supporting the use of these techniques. Okay...we're back to the chicken or the egg argument. My response is to say that rather than waiting for the courts to make a change, the investigators need to start moving in that direction first, getting training and knowledge to not only perform live response but to also be able to present and explain that information in court. After all, many of us are already performing live response investigations, as well as Registry analysis, as a matter of course.
Thoughts?
Saturday, April 29, 2006
Thursday, April 20, 2006
New ProScripts
The user forums at TechPathways were recently revamped and updated (WRT functionality). In the process, previous threads were lost. I've added a couple of ProScripts that you may find helpful...
One of the scripts parses through the Registry (the script makes the assumption that there is only one Windows image in the project, and only one Registry) and pulls out user SIDs. From there, it goes through the HKEY_USERS hive and parses out the UserAssist keys...you know, the ones with the values that are ROT-13 "encrypted". If possible, the script also pulls out timestamps from the value data. Here's an example of the output when I ran the script against the hacking case image:
UEME_RUNPATH:C:\Program Files\Cain\Cain.exe --> Fri Aug 27 15:33:02 2004
UEME_RUNPATH:C:\Program Files\Whois\whois.exe --> Thu Aug 26 15:13:57 2004
UEME_RUNPATH:C:\WINDOWS\System32\telnet.exe --> Thu Aug 26 15:05:15 2004
UEME_RUNPATH:C:\Program Files\Network Stumbler\NetStumbler.exe --> Fri Aug 27 15:12:35 2004
UEME_RUNCPL:"C:\WINDOWS\System32\appwiz.cpl",Add or Remove Programs --> Fri Aug 27 15:14:44 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\WinPcap_3_01_a.exe --> Fri Aug 27 15:15:08 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\ethereal-setup-0.10.6.exe --> Fri Aug 27 15:28:36 2004
UEME_RUNPATH:C:\Program Files\Ethereal\ethereal.exe --> Fri Aug 27 15:34:54 2004
So why is this important? Well, for one, it ties activity such as running executables to a specific user. This info is pulled right out of the NTUSER.DAT file, and is visible in ProDiscover under the HKEY_USERS hive.
This information can be correlated to the contents of the Prefetch directory (on XP systems, which perform application prefetching by default). I wrote a ProScript that would run through the Prefetch directory and list the .pf files. For each one, it retrieves and displays the last run timestamp and run count from the contents of the file. See the following excerpt from the output of the ProScript:
Name : CAIN.EXE-23D61279.pf
Last Run : Fri Aug 27 15:33:03 2004
Run Count : 2
Name : NETSTUMBLER.EXE-0BFEE568.pf
Last Run : Fri Aug 27 15:12:35 2004
Run Count : 1
Name : TELNET.EXE-24182D40.pf
Last Run : Thu Aug 26 15:05:15 2004
Run Count : 1
Name : WINPCAP_3_01_A.EXE-1E3EDEDC.pf
Last Run : Fri Aug 27 15:15:08 2004
Run Count : 1
Notice how the "Last Run" times from the .pf file correlate with the same time from the UserAssist key? So now, if we find an interesting .pf file in the Prefetch directory, we have a way to correlate it and tie it to a particular user. Of course, we can also use the Security Event Log for further correlation...if it is configured to audit logins.
Note that the Prefetch ProScript requires ProDiscover 4.642 (which should now be available) or greater. This is due to updates in one of the APIs.
Yet another ProScript copies the Event Log files out of the Windows\system32\config directory so you can use File::ReadEVT to pull out the data, collect statistics, etc. And I reposted the ProScript that parses V and F values out of the SAM file to determine user information and group membership.
One of the scripts parses through the Registry (the script makes the assumption that there is only one Windows image in the project, and only one Registry) and pulls out user SIDs. From there, it goes through the HKEY_USERS hive and parses out the UserAssist keys...you know, the ones with the values that are ROT-13 "encrypted". If possible, the script also pulls out timestamps from the value data. Here's an example of the output when I ran the script against the hacking case image:
UEME_RUNPATH:C:\Program Files\Cain\Cain.exe --> Fri Aug 27 15:33:02 2004
UEME_RUNPATH:C:\Program Files\Whois\whois.exe --> Thu Aug 26 15:13:57 2004
UEME_RUNPATH:C:\WINDOWS\System32\telnet.exe --> Thu Aug 26 15:05:15 2004
UEME_RUNPATH:C:\Program Files\Network Stumbler\NetStumbler.exe --> Fri Aug 27 15:12:35 2004
UEME_RUNCPL:"C:\WINDOWS\System32\appwiz.cpl",Add or Remove Programs --> Fri Aug 27 15:14:44 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\WinPcap_3_01_a.exe --> Fri Aug 27 15:15:08 2004
UEME_RUNPATH:C:\Documents and Settings\Mr. Evil\Desktop\ethereal-setup-0.10.6.exe --> Fri Aug 27 15:28:36 2004
UEME_RUNPATH:C:\Program Files\Ethereal\ethereal.exe --> Fri Aug 27 15:34:54 2004
So why is this important? Well, for one, it ties activity such as running executables to a specific user. This info is pulled right out of the NTUSER.DAT file, and is visible in ProDiscover under the HKEY_USERS hive.
This information can be correlated to the contents of the Prefetch directory (on XP systems, which perform application prefetching by default). I wrote a ProScript that would run through the Prefetch directory and list the .pf files. For each one, it retrieves and displays the last run timestamp and run count from the contents of the file. See the following excerpt from the output of the ProScript:
Name : CAIN.EXE-23D61279.pf
Last Run : Fri Aug 27 15:33:03 2004
Run Count : 2
Name : NETSTUMBLER.EXE-0BFEE568.pf
Last Run : Fri Aug 27 15:12:35 2004
Run Count : 1
Name : TELNET.EXE-24182D40.pf
Last Run : Thu Aug 26 15:05:15 2004
Run Count : 1
Name : WINPCAP_3_01_A.EXE-1E3EDEDC.pf
Last Run : Fri Aug 27 15:15:08 2004
Run Count : 1
Notice how the "Last Run" times from the .pf file correlate with the same time from the UserAssist key? So now, if we find an interesting .pf file in the Prefetch directory, we have a way to correlate it and tie it to a particular user. Of course, we can also use the Security Event Log for further correlation...if it is configured to audit logins.
Note that the Prefetch ProScript requires ProDiscover 4.642 (which should now be available) or greater. This is due to updates in one of the APIs.
Yet another ProScript copies the Event Log files out of the Windows\system32\config directory so you can use File::ReadEVT to pull out the data, collect statistics, etc. And I reposted the ProScript that parses V and F values out of the SAM file to determine user information and group membership.
Saturday, April 15, 2006
Reassembling an image file from a memory dump
Andreas Schuster posted a tutorial on his blog for reassembling the executable image of a process from a dump of physical memory a bit ago. As I've already got Perl code for parsing PE headers, why not automate the process?
So far, I've completed the first step in reassembling the image...parsing the PE headers. To do this, locate the PEB for the process (from the information located in the EPROCESS block...use lsproc and then lspd from my SourceForge site to get the necessary information) and from there, get the value for the ImageBaseAddress (a DWORD located at offset 0x08 within the PEB). Convert that virtual address to a physical offset within the dump file (done by the code) and, if the physical offset is "present", read in the 4K page located at that address. Now, the PE header isn't usually 4K (4096 bytes) in size, so most of the page will be zeros. However, we can parse out the information we need. For example, I ran some tests using the process named "nc.exe"...
The initial information looked good:
DOS header located.
e_lfanew = 128 (0x00000080)
NT Header = 0x4550
The "DOS Header" is "MZ", and the value for e_lfanew is something that we're going to use for several calculations. The NT Header is valid, as it translates to "PE". Next, we read the Image File Header and find that there are 4 sections, and the image has the following characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
From the Image Optional Header, we get:
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00004c00
Notice the value for the entry point address. This will be important later, particularly when we perform detailed analysis of the image file itself. Tools such as PeID use entry point analysis to determine things such as packers and encryption used on obfuscated binaries (mostly malware). If you know what you're doing, you can get a lot of information by determining not only the location of the entry point, but also the contents (first 100 bytes or so) of the entry point.
Moving on, we pull out the Image Data Directories:
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x00000000 0x00000000
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x00000000 0x00000000
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x00012000 0x0000003c
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x000121a0 0x00000164
We see from this that the only data directories are the Import (Name) Table and the Import Address Table (IAT). Once we reassemble the image, we will be able to use this information to determine which DLLs the image accesses, and which functions from those DLLs it imports.
Finally, we look at the Image Section Headers:
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00009770 0x00001000 0x00000400 0x00009800 0x60000020
.data 0x00005244 0x0000c000 0x0000a200 0x00003e00 0xc0000040
.idata 0x0000075c 0x00012000 0x0000e000 0x00000800 0xc0000040
.rdata 0x00000417 0x0000b000 0x00009c00 0x00000600 0x40000040
Remember, from the Image File Header, we found that there were 4 sections. Now we have more detailed information about those sections.
Using the code I have now, I took a look at the same process that Andreas used in his tutorial...dd.exe, PID 284. I extracted the same information he listed, down to the section headers. Now, to begin automatically reassembling the image, we simply need to follow the advice given by Andreas; specifically, given the information we've extracted from the PE header, go back into the physical dump file, extract those pages and reassemble them in order. The test will then be not only to view the complete PE header information, Import Table and resources of the file using something like File::ReadPE (or use tools such as pedump or PEView), but to also actually launch the image.
So far, I've completed the first step in reassembling the image...parsing the PE headers. To do this, locate the PEB for the process (from the information located in the EPROCESS block...use lsproc and then lspd from my SourceForge site to get the necessary information) and from there, get the value for the ImageBaseAddress (a DWORD located at offset 0x08 within the PEB). Convert that virtual address to a physical offset within the dump file (done by the code) and, if the physical offset is "present", read in the 4K page located at that address. Now, the PE header isn't usually 4K (4096 bytes) in size, so most of the page will be zeros. However, we can parse out the information we need. For example, I ran some tests using the process named "nc.exe"...
The initial information looked good:
DOS header located.
e_lfanew = 128 (0x00000080)
NT Header = 0x4550
The "DOS Header" is "MZ", and the value for e_lfanew is something that we're going to use for several calculations. The NT Header is valid, as it translates to "PE". Next, we read the Image File Header and find that there are 4 sections, and the image has the following characteristics:
IMAGE_FILE_EXECUTABLE_IMAGE
IMAGE_FILE_LOCAL_SYMS_STRIPPED
IMAGE_FILE_RELOCS_STRIPPED
IMAGE_FILE_LINE_NUMS_STRIPPED
IMAGE_FILE_32BIT_MACHINE
From the Image Optional Header, we get:
Opt Header Magic = 0x10b
Subsystem : IMAGE_SUBSYSTEM_WINDOWS_CUI
Entry Pt Addr : 0x00004c00
Notice the value for the entry point address. This will be important later, particularly when we perform detailed analysis of the image file itself. Tools such as PeID use entry point analysis to determine things such as packers and encryption used on obfuscated binaries (mostly malware). If you know what you're doing, you can get a lot of information by determining not only the location of the entry point, but also the contents (first 100 bytes or so) of the entry point.
Moving on, we pull out the Image Data Directories:
Data Directory RVA Size
-------------- --- ----
ResourceTable 0x00000000 0x00000000
DebugTable 0x00000000 0x00000000
BaseRelocTable 0x00000000 0x00000000
DelayImportDesc 0x00000000 0x00000000
TLSTable 0x00000000 0x00000000
GlobalPtrReg 0x00000000 0x00000000
ArchSpecific 0x00000000 0x00000000
CLIHeader 0x00000000 0x00000000
LoadConfigTable 0x00000000 0x00000000
ExceptionTable 0x00000000 0x00000000
ImportTable 0x00012000 0x0000003c
unused 0x00000000 0x00000000
BoundImportTable 0x00000000 0x00000000
ExportTable 0x00000000 0x00000000
CertificateTable 0x00000000 0x00000000
IAT 0x000121a0 0x00000164
We see from this that the only data directories are the Import (Name) Table and the Import Address Table (IAT). Once we reassemble the image, we will be able to use this information to determine which DLLs the image accesses, and which functions from those DLLs it imports.
Finally, we look at the Image Section Headers:
Name Virt Sz Virt Addr rData Ofs rData Sz Char
---- ------- --------- --------- -------- ----
.text 0x00009770 0x00001000 0x00000400 0x00009800 0x60000020
.data 0x00005244 0x0000c000 0x0000a200 0x00003e00 0xc0000040
.idata 0x0000075c 0x00012000 0x0000e000 0x00000800 0xc0000040
.rdata 0x00000417 0x0000b000 0x00009c00 0x00000600 0x40000040
Remember, from the Image File Header, we found that there were 4 sections. Now we have more detailed information about those sections.
Using the code I have now, I took a look at the same process that Andreas used in his tutorial...dd.exe, PID 284. I extracted the same information he listed, down to the section headers. Now, to begin automatically reassembling the image, we simply need to follow the advice given by Andreas; specifically, given the information we've extracted from the PE header, go back into the physical dump file, extract those pages and reassemble them in order. The test will then be not only to view the complete PE header information, Import Table and resources of the file using something like File::ReadPE (or use tools such as pedump or PEView), but to also actually launch the image.
Friday, April 14, 2006
Why Perl?
I haven't actually been asked this question yet, but I'm anticipating it...why Perl? Why am I using Perl for the RAM dump parsing tools, and not C, Java, or C#?
Well, first of all, Perl is pretty ubiquitous...it's everywhere. Perl is not only used for system administration, but for Web-based (CGI) interfaces, and a wide variety of other activities. Perl is used in security projects such as The SleuthKit, the MetaSploit Framework, and used extensively throughout my book and the Real Digital Forensics book.
Perl is great as a quick prototyping tool. Starting from scratch, or by using some code you've already got, you can put together a tool for performing a specific task, and run it quickly. If there are any errors (yes, I know I need to use "-w" more), you can quickly open the file up, locate the error and fix it. As Perl is an interpretted language, you don't have to rebuild/recompile the script...you can run it as soon as you make modifications and save them.
Perl is pretty easy to read...when compared to other languages. I like to comment my code, and will sometimes have more comments in a script than I have lines of code. Perl is also a great educational tool, as you can clearly walk through your script, and show were different things are done; open files, write to a file, access an API, close a file, etc.
One other thing I like about Perl is that because Perl is available on other (Mac, Linux, etc.) systems besides just Windows (yeah, imagine that!), with a little care (predominantly toward endianness) the script I write on Windows can be run on those other platforms. What this means is that a forensic analyst isn't restricted to performing analysis of a Windows system on a Windows system. So, if you dump the contents of physical memory to a file and you're analyzing that file on a Linux system (or if you're Jesse Kornblum, on a Mac), then you're not stuck and restricted to only tools written for that platform. The same is true if you're analyzing an image of a Windows system, and you're on Linux.
Now, if you are on Windows and don't want to install Perl, I try to provide standalone executables of the Perl scripts via Perl2Exe or PAR. These aren't really executables in the sense of a C/C++ file compiled in to a PE file, but more of the Perl script wrapped up the Perl interpreter. So, the EXE files will be larger than a "normal" EXE.
As with my last post, I hope this makes sense.
Well, first of all, Perl is pretty ubiquitous...it's everywhere. Perl is not only used for system administration, but for Web-based (CGI) interfaces, and a wide variety of other activities. Perl is used in security projects such as The SleuthKit, the MetaSploit Framework, and used extensively throughout my book and the Real Digital Forensics book.
Perl is great as a quick prototyping tool. Starting from scratch, or by using some code you've already got, you can put together a tool for performing a specific task, and run it quickly. If there are any errors (yes, I know I need to use "-w" more), you can quickly open the file up, locate the error and fix it. As Perl is an interpretted language, you don't have to rebuild/recompile the script...you can run it as soon as you make modifications and save them.
Perl is pretty easy to read...when compared to other languages. I like to comment my code, and will sometimes have more comments in a script than I have lines of code. Perl is also a great educational tool, as you can clearly walk through your script, and show were different things are done; open files, write to a file, access an API, close a file, etc.
One other thing I like about Perl is that because Perl is available on other (Mac, Linux, etc.) systems besides just Windows (yeah, imagine that!), with a little care (predominantly toward endianness) the script I write on Windows can be run on those other platforms. What this means is that a forensic analyst isn't restricted to performing analysis of a Windows system on a Windows system. So, if you dump the contents of physical memory to a file and you're analyzing that file on a Linux system (or if you're Jesse Kornblum, on a Mac), then you're not stuck and restricted to only tools written for that platform. The same is true if you're analyzing an image of a Windows system, and you're on Linux.
Now, if you are on Windows and don't want to install Perl, I try to provide standalone executables of the Perl scripts via Perl2Exe or PAR. These aren't really executables in the sense of a C/C++ file compiled in to a PE file, but more of the Perl script wrapped up the Perl interpreter. So, the EXE files will be larger than a "normal" EXE.
As with my last post, I hope this makes sense.
But...why?
When it comes to using dd.exe to dump the contents of physical memory from a Windows system, one thing that's been asked is...why? Why is any of this important? Why use dd.exe to dump the contents of RAM, and then why all the effort to write tools to parse through the resulting file? After all, if it really were important, wouldn't someone have done all of this already?
For a long time, the "normal" forensics steps that've been taken have been to document a scene, then remove power from the system before creating a forensic image of the hard drive. However, in recent years, there's been a realization, even among law enforcement, that there may be something of value found in the volatile memory of the system...perhaps even evidentary. For example, we know that the Clipboard occupies an area of memory designated by the system, and we can run a tool that will dump the contents of the Clipboard.
When I've talked to some law enforcement officers at conferences I've attended, I've asked them why they collect the contents of RAM, rather than say, run specific tools to get things like the contents of the Clipboard, memory used by specific processes, etc. In most cases, I'm simply told, "we want it all." When I ask, "what for?", I'm usually met with stares or responses like, "in case we need it."
Don't get me wrong...there may be something of value in memory that can be used to help further the investigation. Folks have found evidence of malware, passwords, etc., but most of the examination has been hit or miss...create the dump, then run strings on it to see what's there. At that point, you end up with a lot of output and you really have no way of tying what you found back to a particular process. Is that IP address or potential password you found in the output of strings from a malcode process, such as a backdoor, Trojan, or worm...or was it part of an email, or word processing document, or...? There's no way to know.
This is why I'm working on these tools. Not only because it's a challenge...and I have to thank several folks out there, particularly Andreas Schuster, for their help and assistance in moving this along. The other reasons are that (a) tools like this are needed...needed by folks who are working in the field and have a 512MB dump of RAM on their system, and no idea what to do next, and (b) knowledge of these things is needed. By talking to others, figuring things out, and presenting the information to more people, there might be a few people who get over that initial hurdle of "I don't know where to start", and start learning about this topic...and what we end up with is more folks with more knowledge, and we're all smarter.
I hope this makes sense.
For a long time, the "normal" forensics steps that've been taken have been to document a scene, then remove power from the system before creating a forensic image of the hard drive. However, in recent years, there's been a realization, even among law enforcement, that there may be something of value found in the volatile memory of the system...perhaps even evidentary. For example, we know that the Clipboard occupies an area of memory designated by the system, and we can run a tool that will dump the contents of the Clipboard.
When I've talked to some law enforcement officers at conferences I've attended, I've asked them why they collect the contents of RAM, rather than say, run specific tools to get things like the contents of the Clipboard, memory used by specific processes, etc. In most cases, I'm simply told, "we want it all." When I ask, "what for?", I'm usually met with stares or responses like, "in case we need it."
Don't get me wrong...there may be something of value in memory that can be used to help further the investigation. Folks have found evidence of malware, passwords, etc., but most of the examination has been hit or miss...create the dump, then run strings on it to see what's there. At that point, you end up with a lot of output and you really have no way of tying what you found back to a particular process. Is that IP address or potential password you found in the output of strings from a malcode process, such as a backdoor, Trojan, or worm...or was it part of an email, or word processing document, or...? There's no way to know.
This is why I'm working on these tools. Not only because it's a challenge...and I have to thank several folks out there, particularly Andreas Schuster, for their help and assistance in moving this along. The other reasons are that (a) tools like this are needed...needed by folks who are working in the field and have a 512MB dump of RAM on their system, and no idea what to do next, and (b) knowledge of these things is needed. By talking to others, figuring things out, and presenting the information to more people, there might be a few people who get over that initial hurdle of "I don't know where to start", and start learning about this topic...and what we end up with is more folks with more knowledge, and we're all smarter.
I hope this makes sense.
Thursday, April 13, 2006
Updated lsproc
I've updated lsproc with some small changes. For one, I made a small change to the detection portion of the script.
The other change I made was to output the creation time of the process rather than the FLink/BLink values. In doing so, I ran across some interesting output. Take a look:
Proc 156 176 winlogon.exe 0x01045d60 Sun Jun 5 00:32:44 2005
Proc 156 176 winlogon.exe 0x01048140 Sat Jun 4 23:36:31 2005
Proc 144 164 winlogon.exe 0x0104ca00 Fri Jun 3 01:25:54 2005
Proc 156 180 csrss.exe 0x01286480 Sun Jun 5 00:32:43 2005
Proc 144 168 csrss.exe 0x01297b40 Fri Jun 3 01:25:53 2005
Proc 8 156 smss.exe 0x012b62c0 Sun Jun 5 00:32:40 2005
Looking at the output, most of the processes seem to have been started on Sun, Jun 5...and yet there are a couple of processes that were started well before then. Definitely something to look into.
As with the other tools, the Perl source and a standalone executable for Windows are available in the archive.
The other change I made was to output the creation time of the process rather than the FLink/BLink values. In doing so, I ran across some interesting output. Take a look:
Proc 156 176 winlogon.exe 0x01045d60 Sun Jun 5 00:32:44 2005
Proc 156 176 winlogon.exe 0x01048140 Sat Jun 4 23:36:31 2005
Proc 144 164 winlogon.exe 0x0104ca00 Fri Jun 3 01:25:54 2005
Proc 156 180 csrss.exe 0x01286480 Sun Jun 5 00:32:43 2005
Proc 144 168 csrss.exe 0x01297b40 Fri Jun 3 01:25:53 2005
Proc 8 156 smss.exe 0x012b62c0 Sun Jun 5 00:32:40 2005
Looking at the output, most of the processes seem to have been started on Sun, Jun 5...and yet there are a couple of processes that were started well before then. Definitely something to look into.
As with the other tools, the Perl source and a standalone executable for Windows are available in the archive.
Prefetch files, revisited
I was listening to the latest CyberSpeak podcast (8 Apr) today, and picked up a little tidbit. With regards to those .pf files located in the Prefetch directory on Windows XP, Ovie and Bret stated that the DWORD located at offset 0x90 in the file records the number of times that particular application was launched, with the caveat that this does not apply to those applications autostarted (as via Registry entries). So this will tell you how many times the user launched that application.
Also, the guys said that the 2 DWORDs located at offset 0x78 is the FILETIME object for the time that the application was last launched. This should probably correlate with the last write time on the .pf file itself.
Anyone have any other tidbits like this that can be incorporated into a nice little Perl script? ;-)
Also, the guys said that the 2 DWORDs located at offset 0x78 is the FILETIME object for the time that the application was last launched. This should probably correlate with the last write time on the .pf file itself.
Anyone have any other tidbits like this that can be incorporated into a nice little Perl script? ;-)
Saturday, April 08, 2006
lspd posted
I've posted lspd (for "list process details") to the SourceForge site this morning.
First, I want to say that this is a tool written in Perl. The archive I posted includes the Perl source, as well as an executable compiled from the script using Perl2Exe (note: if you use this executable, you need to keep p2x587.dll with the exe at all times). If you don't want to use this executable, or want to modify the source and recompile it, take a look at the PAR module, which is available for Perl. PAR can produce either a portable package that you can run on other platforms (though this script does not use any additional modules), or an executable that is simply more portable.
I wanted to mention this up front, as you don't have to have just Windows to run the script...you can run it on any system that runs Perl. Well, take that with a caveat...I haven't actually tested this on some of the other platforms that run Perl, such as the Tivo.
So...on to the show.
lspd dumps the details of a process from a dd.exe-style dump file, such as those provided with the DFRWS 2005 Memory Challenge. The first thing you have to do is run the lsproc tool against the dump, and get the value of the offset for the process you're interested in.
For example, I ran lsproc against the first memory dump from the Memory Challenge, and found this:
Proc 1112 284 dd.exe 0x0414dd60 0x8046b980 0xff1190c0
From there, I ran the lspd.pl script against the dump file using he following command line:
C:\Perl>lspd.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
As you can see, lspd takes 2 arguements...the dump file, followed by the hex offset of the process you're interested in.
lspd ran very quickly, and dumped out process details, such as details from the EPROCESS block and process environment block (PEB), the command line used to launch the process, the Desktop name, the Window title, etc. lspd also extracts the modules and handles, if available.
Here's an example of the handles extracted for this process:
Type : File
Name = \Shells
Type : WindowStation
Type : WindowStation
Type : Desktop
Type : File
Name = \intrusion2005\audit.log
Type : File
Name = \intrusion2005\audit.log
lspd was also able to determine that the page located at the Image Base Address (from the PEB) contains a PE header. This will be addressed with another tool (tentative name: lspi, for "list process image").
One thing to keep in mind while using this tool...not all of the information that we're trying to extract is present in the physical memory dump file. When a virtual address is translated into a physical offset within the dump file, flags need to be checked to see if the 4K page is "present" (I put that in quotes b/c that's the name of the flag). Andreas Schuster has a very good tutorial about how this works, but I'm considering writing something specific to these tools, should I find the time to do so.
As always, if you have any comments or questions, please feel free to contact me.
First, I want to say that this is a tool written in Perl. The archive I posted includes the Perl source, as well as an executable compiled from the script using Perl2Exe (note: if you use this executable, you need to keep p2x587.dll with the exe at all times). If you don't want to use this executable, or want to modify the source and recompile it, take a look at the PAR module, which is available for Perl. PAR can produce either a portable package that you can run on other platforms (though this script does not use any additional modules), or an executable that is simply more portable.
I wanted to mention this up front, as you don't have to have just Windows to run the script...you can run it on any system that runs Perl. Well, take that with a caveat...I haven't actually tested this on some of the other platforms that run Perl, such as the Tivo.
So...on to the show.
lspd dumps the details of a process from a dd.exe-style dump file, such as those provided with the DFRWS 2005 Memory Challenge. The first thing you have to do is run the lsproc tool against the dump, and get the value of the offset for the process you're interested in.
For example, I ran lsproc against the first memory dump from the Memory Challenge, and found this:
Proc 1112 284 dd.exe 0x0414dd60 0x8046b980 0xff1190c0
From there, I ran the lspd.pl script against the dump file using he following command line:
C:\Perl>lspd.pl d:\hacking\dfrws-mem1.dmp 0x0414dd60
As you can see, lspd takes 2 arguements...the dump file, followed by the hex offset of the process you're interested in.
lspd ran very quickly, and dumped out process details, such as details from the EPROCESS block and process environment block (PEB), the command line used to launch the process, the Desktop name, the Window title, etc. lspd also extracts the modules and handles, if available.
Here's an example of the handles extracted for this process:
Type : File
Name = \Shells
Type : WindowStation
Type : WindowStation
Type : Desktop
Type : File
Name = \intrusion2005\audit.log
Type : File
Name = \intrusion2005\audit.log
lspd was also able to determine that the page located at the Image Base Address (from the PEB) contains a PE header. This will be addressed with another tool (tentative name: lspi, for "list process image").
One thing to keep in mind while using this tool...not all of the information that we're trying to extract is present in the physical memory dump file. When a virtual address is translated into a physical offset within the dump file, flags need to be checked to see if the 4K page is "present" (I put that in quotes b/c that's the name of the flag). Andreas Schuster has a very good tutorial about how this works, but I'm considering writing something specific to these tools, should I find the time to do so.
As always, if you have any comments or questions, please feel free to contact me.
Friday, April 07, 2006
lsproc released
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.
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.
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?
Subscribe to:
Posts (Atom)