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...
Tuesday, February 28, 2006
Tuesday, February 21, 2006
Quoted
Joab Jackson quote me in this article over on Government Computer News. File metadata has been an issue for a while, and this isn't anything new...except for the fact that it's still an issue. MSWord and PDF documents can both contain metadata, and most do. Do a little Google hacking and pull up MSWord documents based on domain (.mil) or content, and see what you can see.
The script mentioned in the article is now available as a Perl module.
The script mentioned in the article is now available as a Perl module.
In the news...
If you own a Windows system (home user, corporate or university admin, etc.), you will want to see Brian Krebs' latest article in the Washington Post Magazine. I read it this weekend...largely because people I know who aren't in the computer industry kept telling me, "dude...you've GOT to read this article!" They were right...it is an incredible article, well crafted and written, that gives the reader an insight into the issue of botnets, and a glimpse of one of the micro-economies created as a result of the Internet.
One thing is clear, too...breaking into computers is no longer just for kicks. There are economic/financial/profit motives now...things like adware and spyware, and identity theft are all reasons for someone to want to break into and gain control of your computer.
One thing is clear, too...breaking into computers is no longer just for kicks. There are economic/financial/profit motives now...things like adware and spyware, and identity theft are all reasons for someone to want to break into and gain control of your computer.
Friday, February 17, 2006
Determining group membership from an image
A while back, I received this question..."how do I figure out a user's group membership from an image?" Well, I didn't know off the top of my head, and decided that knowing would be useful, so I started digging around. After receiving some much-needed insight from a friend on one of the online forums I frequent, I was able to create a ProScript (Perl script) for use with ProDiscover. I posted the script to their online forum, along with one to enumerate users from an image...and that one is just the beginning, as it only retrieves the user's name from the V structure. There is still quite a bit of information embedded in the F and V structures.
In a nutshell, the way it works is this...within the HKLM\SAM\SAM\Domains\Builtin\Aliases key, there are several subkeys...00000220, etc. These keys have a value named "C", which is binary, and contains the name of the group, the comment describing the group, etc. The first 52 (13 DWORDS) bytes of this value is the header, and the last three DWORDs describe the offset to the listing of user SIDs, the length of the data, and how many users there are. One of the SIDs for the Administrators group will end with the RID of "1F4", which is 500 in decimal...the Administrator account.
Now, to map the user RID to a username, go to HKLM\SAM\SAM\Domains\Account\Users key, where you will find subkeys that look like 000001F4 and 00000E3B, etc. These are the user RIDs, and user info is maintained in the binary V and F values within the key. The offset to the username (ofsName) is stored in the DWORD located 0xC bytes into the binary V structure (the length of the username is maintained in the next DWORD, which starts at offset 0x10). The username itself is in Unicode format and is found at offset 0xCC + ofsName from the beginning of the structure.
So...pretty cool, eh? I got started down the path of looking to the Builtin\Aliases key by running one of the 'net' commands (to enumerate group membership) while also running RegMon, and then filtering on the process I wanted. From there, a little work with a hexeditor and a little help from a friend went a long way.
It's really no surprise that there's nothing in the above post that points to Microsoft as providing assistance of documentation...that information simply is not available. It's not the fault of the folks who have done their best to assist me (and others) over the years...they can't provide what doesn't exist. What I've had to do is go to Linux-based documentation, talk to others, experiment on my own, etc.
On a side note, sometimes when I'm working with or discussing something with someone, particularly things related to the forensic analysis of Windows systems, I'll ask them if they have any sort of documentation or reference. This isn't meant as an indictment of them...I'm not asking them to prove anything, though most of the times, the response I get seems to indicate that they were seriously offended by the question. No, I'm asking for that simply because sometimes I may be able to correlate information from some sort of documentation with something else I've been looking at, or some other little tidbit of information I mayhave. Whenever possible, I try to provide references and/or documentation for what I do as it not only gives everyone a common base to work from, but it also lets others see what I've been looking at, so that they don't have to relearn all that stuff on their own.
Thoughts?
In a nutshell, the way it works is this...within the HKLM\SAM\SAM\Domains\Builtin\Aliases key, there are several subkeys...00000220, etc. These keys have a value named "C", which is binary, and contains the name of the group, the comment describing the group, etc. The first 52 (13 DWORDS) bytes of this value is the header, and the last three DWORDs describe the offset to the listing of user SIDs, the length of the data, and how many users there are. One of the SIDs for the Administrators group will end with the RID of "1F4", which is 500 in decimal...the Administrator account.
Now, to map the user RID to a username, go to HKLM\SAM\SAM\Domains\Account\Users key, where you will find subkeys that look like 000001F4 and 00000E3B, etc. These are the user RIDs, and user info is maintained in the binary V and F values within the key. The offset to the username (ofsName) is stored in the DWORD located 0xC bytes into the binary V structure (the length of the username is maintained in the next DWORD, which starts at offset 0x10). The username itself is in Unicode format and is found at offset 0xCC + ofsName from the beginning of the structure.
So...pretty cool, eh? I got started down the path of looking to the Builtin\Aliases key by running one of the 'net' commands (to enumerate group membership) while also running RegMon, and then filtering on the process I wanted. From there, a little work with a hexeditor and a little help from a friend went a long way.
It's really no surprise that there's nothing in the above post that points to Microsoft as providing assistance of documentation...that information simply is not available. It's not the fault of the folks who have done their best to assist me (and others) over the years...they can't provide what doesn't exist. What I've had to do is go to Linux-based documentation, talk to others, experiment on my own, etc.
On a side note, sometimes when I'm working with or discussing something with someone, particularly things related to the forensic analysis of Windows systems, I'll ask them if they have any sort of documentation or reference. This isn't meant as an indictment of them...I'm not asking them to prove anything, though most of the times, the response I get seems to indicate that they were seriously offended by the question. No, I'm asking for that simply because sometimes I may be able to correlate information from some sort of documentation with something else I've been looking at, or some other little tidbit of information I mayhave. Whenever possible, I try to provide references and/or documentation for what I do as it not only gives everyone a common base to work from, but it also lets others see what I've been looking at, so that they don't have to relearn all that stuff on their own.
Thoughts?
Sunday, February 12, 2006
What do you do when...??
Sometimes you find yourself in one of those situations, where the customer calls you and wants to know:
So, what do you do? After all, if it wasn't important, the customer wouldn't have called you, right? What do you tell them?
- Who copied or modified a file, or
- Who created or modified a user account
So, what do you do? After all, if it wasn't important, the customer wouldn't have called you, right? What do you tell them?
What the...??
What is the weirdest/most interesting thing you've seen when performing an investigation of a Windows system?
I once was asked to look at a Win2K system with no auditing enabled, and a weak Admin password. The system was infested with spyware and malware...at least three Trojans were installed. I also found three additional Admin accounts...God, g0d and gawd. It looked to me as if one person had gotten in and created the first account (gee-oh-dee), then the second person got in and found the account he wanted to create already there, so he created his own variation...gee-zero-dee.
What about you?
I once was asked to look at a Win2K system with no auditing enabled, and a weak Admin password. The system was infested with spyware and malware...at least three Trojans were installed. I also found three additional Admin accounts...God, g0d and gawd. It looked to me as if one person had gotten in and created the first account (gee-oh-dee), then the second person got in and found the account he wanted to create already there, so he created his own variation...gee-zero-dee.
What about you?
Tuesday, February 07, 2006
The Forensic Server Project
Recently, I've received a couple of emails about the Forensic Server Project (aka, FSP), seen it written up in the Helix 1.7 Beginner's Manual, and even seen it demo'd on the CERT VTE.
For a listing of sites that mention the FSP, go here.
Anyway, the one thing in common amongst all of these sites seems to be that the FSP is simply misunderstood. I talked about the FSP in chapter 8 of my book, but soon after the book was published, I made some updates to the tools, and released them as standalone executables (I compiled the Perl scripts with Perl2Exe).
So...what is the FSP? The FSP is a client/server architecture for effective, sound incident response procedures. The FSP, along with the client application (the First Responder Utility), provides a framework for quick, efficient, and effective data collection during incident response activities. The FRU can be run from a CD or thumb drive, and communicates via TCP with the FSP server component in order to get data off of a system.
Think of it like this...have you seen where netcat is used to get data off of systems? Each command is typed in by hand, or run via a batch file, and the output is piped out over netcat to a waiting listener on another system. The responder has to log each command entered, and do a lot of documentation manually. On the server end, the investigator either ends up with one huge file he must parse, or he has to shutdown and restart the listener for each new command.
The FSP, on the other hand, handles all that for you. The server component takes care of logging, hash generation (and comparison, if files are copied), timestamping of the logs, etc.
The FSP is also very flexible. The FRU runs off of ini files, which tell the application what commands to run, which Registry keys/values to collect, etc. With all of the necessary tools copied to the CD, the investigator create and choose from a variety of ini files, based on location, operating system, installed applications, etc. The ini file can be loaded on the CD or thumb drive, or run from a floppy or even a mapped drive.
So, yes, the FSP does require a little bit extra work in set up, but in providing the standalone executables, I've made that process MUCH easier. The flexibility simply can't be beat...there's no waiting for updates, as the FSP framework allows the investigator to run whichever third party tools she chooses.
There is still some room for improvement, though. For example, incorporating the ability to select files to be copied directly into the FRU. Another thing is the analysis suite...pulling together tools to parse and analyze that data that's collected.
Which brings me to something else that's beneficial about the FSP...it's written in Perl. A lot of folks may look at this and think "Ugh!" Well, being written in Perl, it's also open source. Which means that you can run the server component on just about any platform the supports Perl, and write your own client apps. The currently available FRU is the client for Windows, but clients can be written for Linux, the Mac, etc. And because the framework is open, you're not restricted to using just Perl. Use Python, Ruby, shell scripts...whatever you're most comfortable with.
So I guess I just added a couple of things to my ToDo list...a user manual, and a developer's manual.
For a listing of sites that mention the FSP, go here.
Anyway, the one thing in common amongst all of these sites seems to be that the FSP is simply misunderstood. I talked about the FSP in chapter 8 of my book, but soon after the book was published, I made some updates to the tools, and released them as standalone executables (I compiled the Perl scripts with Perl2Exe).
So...what is the FSP? The FSP is a client/server architecture for effective, sound incident response procedures. The FSP, along with the client application (the First Responder Utility), provides a framework for quick, efficient, and effective data collection during incident response activities. The FRU can be run from a CD or thumb drive, and communicates via TCP with the FSP server component in order to get data off of a system.
Think of it like this...have you seen where netcat is used to get data off of systems? Each command is typed in by hand, or run via a batch file, and the output is piped out over netcat to a waiting listener on another system. The responder has to log each command entered, and do a lot of documentation manually. On the server end, the investigator either ends up with one huge file he must parse, or he has to shutdown and restart the listener for each new command.
The FSP, on the other hand, handles all that for you. The server component takes care of logging, hash generation (and comparison, if files are copied), timestamping of the logs, etc.
The FSP is also very flexible. The FRU runs off of ini files, which tell the application what commands to run, which Registry keys/values to collect, etc. With all of the necessary tools copied to the CD, the investigator create and choose from a variety of ini files, based on location, operating system, installed applications, etc. The ini file can be loaded on the CD or thumb drive, or run from a floppy or even a mapped drive.
So, yes, the FSP does require a little bit extra work in set up, but in providing the standalone executables, I've made that process MUCH easier. The flexibility simply can't be beat...there's no waiting for updates, as the FSP framework allows the investigator to run whichever third party tools she chooses.
There is still some room for improvement, though. For example, incorporating the ability to select files to be copied directly into the FRU. Another thing is the analysis suite...pulling together tools to parse and analyze that data that's collected.
Which brings me to something else that's beneficial about the FSP...it's written in Perl. A lot of folks may look at this and think "Ugh!" Well, being written in Perl, it's also open source. Which means that you can run the server component on just about any platform the supports Perl, and write your own client apps. The currently available FRU is the client for Windows, but clients can be written for Linux, the Mac, etc. And because the framework is open, you're not restricted to using just Perl. Use Python, Ruby, shell scripts...whatever you're most comfortable with.
So I guess I just added a couple of things to my ToDo list...a user manual, and a developer's manual.
Images to play with
From other forums, I've found example images that can be used to sharpen your skills in forensic analysis. For example, there are some images at the CRFeDS Project at NIST...I've downloaded the "Hacking Case" images. There are also Digital Forensics Tool Testing images that are available.
There are also some things to play with over at the HoneyNet Project SotM site. Not only are there binaries you can look at and log files you can examine, but SotMs 24 and 26 involve examining the image of a floppy.
On a slightly tangential note, VMWare has made their Server product a free download...from there, you can find a list of community-built virtual machines. These are primarily various flavors of Linux/*nix, but would offer some practice if you ran the VMs and performed live imaging (I do this with my Windows VMs, using ProDiscover).
Are there any other example images of Windows systems out there, available for download?
On a side note, has anyone used some of the popular tools (such as the FSP, or WFT, or any of the various batch files) for retrieving volatile data from live Windows systems, and posted the data for analysis?
There are also some things to play with over at the HoneyNet Project SotM site. Not only are there binaries you can look at and log files you can examine, but SotMs 24 and 26 involve examining the image of a floppy.
On a slightly tangential note, VMWare has made their Server product a free download...from there, you can find a list of community-built virtual machines. These are primarily various flavors of Linux/*nix, but would offer some practice if you ran the VMs and performed live imaging (I do this with my Windows VMs, using ProDiscover).
Are there any other example images of Windows systems out there, available for download?
On a side note, has anyone used some of the popular tools (such as the FSP, or WFT, or any of the various batch files) for retrieving volatile data from live Windows systems, and posted the data for analysis?
Registry research
Is anyone out there doing research into the Windows Registry, from a forensic perspective?
I know that there are viewers available to allow you to see what's in the raw Registry files, and that these viewers are available for a variety of platforms. That's not what I'm looking for.
I'm also aware of the lists of Registry keys that are available, particular the one from AccessData that seems to be pretty popular. While it is a good starting point, there really isn't enough information about the keys/values in the list, and what causes them to be created, modified, or deleted to be useful beyond a certain point.
What I'm asking here is this...is anyone doing research into the conditions that cause various keys/values to be added to, modified, or deleted from the Registry (this also applies to the LastWrite time associated with Registry keys)? This is extremely important in the area of Windows forensic analysis, as it adds context to what the investigator sees.
Some things are obvious (though they could be better documented) such as the TypedURLs key...values are added when the user types a URL into the Address bar of IE. Other things aren't so obvious, such as what causes the LastWrite time of the unique ID key for a USB removeable storage device to be updated?
Is there anyone out there doing this kind of research? At the least, I'd like to consolidate a list of links. Ideally, I'd like to see the efforts themselves consolidated and optimized.
I know that there are viewers available to allow you to see what's in the raw Registry files, and that these viewers are available for a variety of platforms. That's not what I'm looking for.
I'm also aware of the lists of Registry keys that are available, particular the one from AccessData that seems to be pretty popular. While it is a good starting point, there really isn't enough information about the keys/values in the list, and what causes them to be created, modified, or deleted to be useful beyond a certain point.
What I'm asking here is this...is anyone doing research into the conditions that cause various keys/values to be added to, modified, or deleted from the Registry (this also applies to the LastWrite time associated with Registry keys)? This is extremely important in the area of Windows forensic analysis, as it adds context to what the investigator sees.
Some things are obvious (though they could be better documented) such as the TypedURLs key...values are added when the user types a URL into the Address bar of IE. Other things aren't so obvious, such as what causes the LastWrite time of the unique ID key for a USB removeable storage device to be updated?
Is there anyone out there doing this kind of research? At the least, I'd like to consolidate a list of links. Ideally, I'd like to see the efforts themselves consolidated and optimized.
Subscribe to:
Posts (Atom)