You're probably wondering, "Since when did Metallica have anything to do with Windows forensics?"
My answer to that is...since ALWAYS!
Okay...enough of that. The Sandman I'm referring to isn't the one from the Metallica song. Rather this one has to do with the Windows hibernation file (get it? "sleep". "Sandman". get it? no...you don't...). Evidently Nicholas and Mattheiu has been working on a C library for reading/writing the Windows hibernation file. This sounds really cool, and it looks as if they're going to include Python bindings, as well as a couple of sample apps, one of which will reportedly convert a hibernation file into a dd-style memory dump. Very cool. Keep in mind, however, that a hibernation file doesn't contain the current contents of memory, but rather the contents of memory from when the file was created.
Sandman looks like a good tool to have in your kit, and I can't wait to try it out.
Thursday, January 31, 2008
Artifact Repositories, part deux
I wanted to take my last post on this topic just a bit further...
I received an email from someone recently asking me about checklists for determining the attack vector of an incident. Yeah, I know...that's a pretty broad question, but I do see the issue here. Sure, some folks are "finding stuff", but the question is now becoming, how did it get there? That's the next logical question, I suppose, and it is being asked.
Over on F-Secure, I saw this post this morning about a PHP IRC Bot. This is just one example, but once the IRC bot is located on the infected system, how does one go about determining how it got there? One thought would be to look at the method you used to locate the bot...say, scanning with an AV scanner...and use that as a starting point. What did the AV scanner identify the malware as? Once you get a name, go to the vendor's web site and see what it says about infection vectors. Again...this is one way to go about the process, not the way.
Another example is this...I'm sure that finding a bot or backdoor isn't too difficult, particularly if you have volatile data or the malware is easily detected by the scanner you're using. But how did it get there? Was the attack vector a downloader from a malicious web site that pulled down a Trojan or bot that was then used to put the backdoor on the system?
At this point, you might be thinking..."who cares?" After all, you found the bad stuff, right? But is that really sufficient? If you you don't discover the root cause, how do you protect yourself in the future? How do you protect other systems?
Another aspect to consider are the application artifacts. Hogfly recently posted on intel gathering...what are the artifacts of the use of the three applications he listed in the post? Does anyone know? After all, one thing to be concerned about is USB devices...but how many are considering remote storage repositories? Anyone remember this three year old blog post regarding the GMail Drive? Some of the artifacts listed in the post are easily added to any sort of Registry scanning tool... ;-)
I'm thinking that it's about time to add a little something to our investigative process. Artifact repositories will very likely make it much easier to determine root causes, keeping in mind, though, that such a thing isn't really a comprehensive solution. Training or instruction in OS and application basics will provide a better understanding of how to determine root causes, particularly when there a multiple possibilities.
I received an email from someone recently asking me about checklists for determining the attack vector of an incident. Yeah, I know...that's a pretty broad question, but I do see the issue here. Sure, some folks are "finding stuff", but the question is now becoming, how did it get there? That's the next logical question, I suppose, and it is being asked.
Over on F-Secure, I saw this post this morning about a PHP IRC Bot. This is just one example, but once the IRC bot is located on the infected system, how does one go about determining how it got there? One thought would be to look at the method you used to locate the bot...say, scanning with an AV scanner...and use that as a starting point. What did the AV scanner identify the malware as? Once you get a name, go to the vendor's web site and see what it says about infection vectors. Again...this is one way to go about the process, not the way.
Another example is this...I'm sure that finding a bot or backdoor isn't too difficult, particularly if you have volatile data or the malware is easily detected by the scanner you're using. But how did it get there? Was the attack vector a downloader from a malicious web site that pulled down a Trojan or bot that was then used to put the backdoor on the system?
At this point, you might be thinking..."who cares?" After all, you found the bad stuff, right? But is that really sufficient? If you you don't discover the root cause, how do you protect yourself in the future? How do you protect other systems?
Another aspect to consider are the application artifacts. Hogfly recently posted on intel gathering...what are the artifacts of the use of the three applications he listed in the post? Does anyone know? After all, one thing to be concerned about is USB devices...but how many are considering remote storage repositories? Anyone remember this three year old blog post regarding the GMail Drive? Some of the artifacts listed in the post are easily added to any sort of Registry scanning tool... ;-)
I'm thinking that it's about time to add a little something to our investigative process. Artifact repositories will very likely make it much easier to determine root causes, keeping in mind, though, that such a thing isn't really a comprehensive solution. Training or instruction in OS and application basics will provide a better understanding of how to determine root causes, particularly when there a multiple possibilities.
Sunday, January 27, 2008
Artifact Repositories
I see posts in a number of lists asking about (and for) forensic artifacts for P2P applications...lately, there have been several about LimeWire. For the most part, general questions regarding P2P apps drift toward...well...general questions, like "has anyone ever dealt with this" kind of questions. When specific apps are named, like LimeWire, specific questions are asked, such as "what are the contents of this file?" I can easily see how these issues would be relevant to cases involving files being shared, whether they are illicit images, or company proprietary information and IP.
It has occurred to me, time and again, that what is needed is a central repository of forensic artifact information. Something like a searchable database portal where you can login, type in a few keywords, and obtain a listing of relevant articles. These articles could be downloadable PDF documents...something that you can take with you, print out, etc. These articles would be written for forensic analysts, by forensic analysts...that way, they would contain relevant information, as well as have tips for techniques to use for data extraction and analysis, or even the tools themselves.
Now, the question becomes...if this repository were to contain more than just a few articles on forensic artifacts of P2P applications, but instead covered other areas, and even addressed other OSs, is this something you would pay for? Far too often in this community, when something is provided for free, it languishes unused...be it tools, information, or books. An annual subscription fee would be necessary to keep something like this up and running.
Now, articles would be updated, of course, and information would constantly be added to the library. Something like this could also have a forum where information could be exchanged, and clarify questions could be asked. Also, a subscriber could request additional information or make a request for the latest version of the app to be examined.
Is there anything else you'd like to see, or wouldn't like to see in something like this? Does this make any sense at all?
It has occurred to me, time and again, that what is needed is a central repository of forensic artifact information. Something like a searchable database portal where you can login, type in a few keywords, and obtain a listing of relevant articles. These articles could be downloadable PDF documents...something that you can take with you, print out, etc. These articles would be written for forensic analysts, by forensic analysts...that way, they would contain relevant information, as well as have tips for techniques to use for data extraction and analysis, or even the tools themselves.
Now, the question becomes...if this repository were to contain more than just a few articles on forensic artifacts of P2P applications, but instead covered other areas, and even addressed other OSs, is this something you would pay for? Far too often in this community, when something is provided for free, it languishes unused...be it tools, information, or books. An annual subscription fee would be necessary to keep something like this up and running.
Now, articles would be updated, of course, and information would constantly be added to the library. Something like this could also have a forum where information could be exchanged, and clarify questions could be asked. Also, a subscriber could request additional information or make a request for the latest version of the app to be examined.
Is there anything else you'd like to see, or wouldn't like to see in something like this? Does this make any sense at all?
Tuesday, January 22, 2008
Free AV Scanners
Many times during an examination, you may want to do a little data reduction, by scanning your image for the presence of malware. While this should not be considered a 100% guarantee that there is no malware if there are no hits, this may lead you to something and narrow your search a bit. Again, this is just a tool, something that as a forensic analyst you can use.
Start by mounting the image as a read-only drive letter using Mount Image Pro or VDKWin. Then scan the drive letter with your AV scanner of choice. Some free AV scanner options include:
GriSoft AVG Free Edition
avast! Home Edition (free for home/non-commercial use)
ClamWin
Avir AntiVirus PersonalEdition
Comodo AV
Windows Defender (spyware)
Some rankings reports (includes free and for-pay):
PCWorld
Top10 Reviews
GCN Lab
Top Windows AV
Note that some of the available AV products may include a command line interface (F-Prot, for example) which means that you can run the scanner after hours using a Scheduled Task.
So, what's in your wallet? What is your AV scanner of choice (free or otherwise)?
Start by mounting the image as a read-only drive letter using Mount Image Pro or VDKWin. Then scan the drive letter with your AV scanner of choice. Some free AV scanner options include:
GriSoft AVG Free Edition
avast! Home Edition (free for home/non-commercial use)
ClamWin
Avir AntiVirus PersonalEdition
Comodo AV
Windows Defender (spyware)
Some rankings reports (includes free and for-pay):
PCWorld
Top10 Reviews
GCN Lab
Top Windows AV
Note that some of the available AV products may include a command line interface (F-Prot, for example) which means that you can run the scanner after hours using a Scheduled Task.
So, what's in your wallet? What is your AV scanner of choice (free or otherwise)?
Sunday, January 13, 2008
IR Immediate Actions
As you may remember, in December 2007 I presented at the HTCIA conference in Hong Kong, the first HTCIA conference for this chapter. It was a great conference, and a great opportunity to meet a lot of folks in this field (see the Speaker's page).
While there, I presented on Registry Analysis and Windows Memory Analysis, both of which seemed to be well received. One question came up during discussions of Windows Memory Analysis...during the presentation, I talk about different tools and techniques that are available for extracting the contents of RAM, and also talk about the difference between tools I can use as a private individual and those I can use as a consultant. At one point, someone asked me which tools and techniques I use most often as a consultant...and my response was simply "none of them". The reason for this is that in most all of the responses I've dealt with, the system (or systems) have already been turned off, rebooted, or sufficiently imposed upon by others (AV scans, running multiple tools, etc.) that even if I did, as a consultant, have an option available for collecting the contents of RAM available to me, doing so would be of little benefit to either my analysis, or any information I could provide to the customer.
Part of the issue is that as a consultant, I am extremely limited in the tools I can use to collect the contents of physical memory from a system, not so much due to the availability of a particular tool, but more so due to the license agreement associated with that tool.
However, a bigger issue is that the immediate actions performed by most first responders on-site are to take systems offline, shutdown them down, or "clean" and reboot them prior to any calls for outside assistance being made. While this may be pertinent for business preservation and continuity, it most often has a detrimental impact on any follow-on analysis that may take place.
If there is data leakage due to an intrusion (or this is suspected, or this is just a question that needs to be answered...), then the immediate reaction is (apparently) to shut the system down. This may be pertinent, particularly if there is no incident response plan in place that lets people know what they need to do, and time is required to notify and get approval for follow-on activities (such as calling consultants). This reaction appears to be fairly ingrained, and I'm not suggesting that we change it by saying DO NOT shut systems down. What I am going to suggest is that we modify those immediate actions such that pertinent information is collected from systems before they are shut down.
Wait...what? It looks like what I am saying is, go ahead and shut the systems down, or reboot them, or "clean" them...and I am. This is going to happen anyway. There's nothing I can say or do, either on this blog or as a paid consultant, to change that. In order to change that behavior, there has to be an incident response plan (CSIRP) in place that tells people what to do, and when someone shuts a system off inappropriately or incorrectly, that issue needs to be addressed. The issue is that some kind of overwhelming stimulus needs to be put in place to change this behavior, and until this happens, nothing anyone can say or do is going to change that. So...it's gonna happen anyway, and instead of changing it, let's go ahead and go with it...but throw something else in there along the way.
What can we do? Well, one thing is to put tools on systems (for a list of tools, check out my book) when they are set up, or at least at some point prior to an incident occurring. If you can't put tools and a simple batch file on systems (for whatever reason...the most common of which seems to be, "...we don't know how..."), then issue each admin/responder a CD with tools, and a thumb drive. Then make it a policy within the organization that a batch file (could be a DOS batch file, or WMI script, etc.) be run and the output saved to a thumb drive, shared drive, etc., prior to the system being taken offline.
While there, I presented on Registry Analysis and Windows Memory Analysis, both of which seemed to be well received. One question came up during discussions of Windows Memory Analysis...during the presentation, I talk about different tools and techniques that are available for extracting the contents of RAM, and also talk about the difference between tools I can use as a private individual and those I can use as a consultant. At one point, someone asked me which tools and techniques I use most often as a consultant...and my response was simply "none of them". The reason for this is that in most all of the responses I've dealt with, the system (or systems) have already been turned off, rebooted, or sufficiently imposed upon by others (AV scans, running multiple tools, etc.) that even if I did, as a consultant, have an option available for collecting the contents of RAM available to me, doing so would be of little benefit to either my analysis, or any information I could provide to the customer.
Part of the issue is that as a consultant, I am extremely limited in the tools I can use to collect the contents of physical memory from a system, not so much due to the availability of a particular tool, but more so due to the license agreement associated with that tool.
However, a bigger issue is that the immediate actions performed by most first responders on-site are to take systems offline, shutdown them down, or "clean" and reboot them prior to any calls for outside assistance being made. While this may be pertinent for business preservation and continuity, it most often has a detrimental impact on any follow-on analysis that may take place.
If there is data leakage due to an intrusion (or this is suspected, or this is just a question that needs to be answered...), then the immediate reaction is (apparently) to shut the system down. This may be pertinent, particularly if there is no incident response plan in place that lets people know what they need to do, and time is required to notify and get approval for follow-on activities (such as calling consultants). This reaction appears to be fairly ingrained, and I'm not suggesting that we change it by saying DO NOT shut systems down. What I am going to suggest is that we modify those immediate actions such that pertinent information is collected from systems before they are shut down.
Wait...what? It looks like what I am saying is, go ahead and shut the systems down, or reboot them, or "clean" them...and I am. This is going to happen anyway. There's nothing I can say or do, either on this blog or as a paid consultant, to change that. In order to change that behavior, there has to be an incident response plan (CSIRP) in place that tells people what to do, and when someone shuts a system off inappropriately or incorrectly, that issue needs to be addressed. The issue is that some kind of overwhelming stimulus needs to be put in place to change this behavior, and until this happens, nothing anyone can say or do is going to change that. So...it's gonna happen anyway, and instead of changing it, let's go ahead and go with it...but throw something else in there along the way.
What can we do? Well, one thing is to put tools on systems (for a list of tools, check out my book) when they are set up, or at least at some point prior to an incident occurring. If you can't put tools and a simple batch file on systems (for whatever reason...the most common of which seems to be, "...we don't know how..."), then issue each admin/responder a CD with tools, and a thumb drive. Then make it a policy within the organization that a batch file (could be a DOS batch file, or WMI script, etc.) be run and the output saved to a thumb drive, shared drive, etc., prior to the system being taken offline.
Tuesday, January 08, 2008
Response to "antiforensics"
On one of the online forums this evening, someone posted about reading the latest issue of 2600 and finding an article that mentions the use of "antiforensics" techniques, specifically with regards to one forensic analysis application in particular.
My response was this:
[Most of] these techniques don't defeat tools...they defeat examiners.
Thoughts?
My response was this:
[Most of] these techniques don't defeat tools...they defeat examiners.
Thoughts?
Saturday, January 05, 2008
Metadata, again...
I've blogged about metadata for various file types before, and the other day I saw a question regarding metadata in MS Works documents. That was pretty interesting, so I fired up my 'leet Google h4x0R skillz and entered in metadata + "MS Works" as my search terms, and I ended up finding something called Meta-Extractor from the folks at the National Library of New Zealand. This tool appears to be Java-based, is about a 10.7MB download, and appears to extract metadata from a variety of file formats...to include MS Works! That's interesting...I didn't even know that MS Works docs had metadata! My first real intro into Word metadata involved the Blair doc...and I'm aware that other Office OLE file formats have metadata, as well.
Another such tool is Metagoofil, from DarkNet. I haven't tried this one...but then I haven't had a great deal of need for things like metadata. When I have, I've written my own tools.
One of the more interesting ways to generate some cool metadata is to use MergeStreams to merge an Excel spreadsheet into a Word doc. I used to present on this at LE conferences all the time, along with things like NTFS alternate data streams, and hiding data in the Registry...but it looks like this stuff is just kewl nerd stuff and nothing more...
Another such tool is Metagoofil, from DarkNet. I haven't tried this one...but then I haven't had a great deal of need for things like metadata. When I have, I've written my own tools.
One of the more interesting ways to generate some cool metadata is to use MergeStreams to merge an Excel spreadsheet into a Word doc. I used to present on this at LE conferences all the time, along with things like NTFS alternate data streams, and hiding data in the Registry...but it looks like this stuff is just kewl nerd stuff and nothing more...
Tuesday, January 01, 2008
First Post of '08
So, here it is...the first post of 2008 on my blog...what to say, what to say? I'm not a big fan of the "predictions" posts, pontificating on what's going to happen in the coming year. For the most part, who knows? Anything we do see in the media regarding data breaches is...well...tainted by the media, so we're not going to have any idea of the validity of what we're seeing.
Let's do some highlights...
From the perspective of this blog and the subject matter, the highlights for 2007 were the release of Windows Forensic Analysis in May, followed at the end of the year by the release of Perl Scripting for IT Security (the cover on Amazon says "IT", but the book on my bookshelf says
"Windows"...it was published by Elsevier).
Another highlight, as it relates to the WFA book, is that Richard Bejtlich posted his Best Books Bejtlich Read in 2007, and ranked WFA #3! High praise, indeed, considering that Richard is a *BSD guy!
Goals I'd like to achieve in the coming year include:
If you got some goals, thoughts or comments that relate to the subject matter of this blog, feel free to post a comment...and have a great 2008!
Addendum:
Andrew Hay's Predictions for '08
Let's do some highlights...
From the perspective of this blog and the subject matter, the highlights for 2007 were the release of Windows Forensic Analysis in May, followed at the end of the year by the release of Perl Scripting for IT Security (the cover on Amazon says "IT", but the book on my bookshelf says
"Windows"...it was published by Elsevier).
Another highlight, as it relates to the WFA book, is that Richard Bejtlich posted his Best Books Bejtlich Read in 2007, and ranked WFA #3! High praise, indeed, considering that Richard is a *BSD guy!
Goals I'd like to achieve in the coming year include:
- Finish development on Windows memory parsing tools (or at least progress along in the stages....)
- Finish development of a Windows Registry preprocessor (basically, extract the Registry hive files from an image and drop them into a "thresher", and the wheat gets separated from the chaff...)
- Include more Vista- and Windows 2008-specific data in #1 and #2 above
- Do more codification and documentation of frameworks and processes related to my day job; things like live response, CSIRP development, documentation of data extraction and analysis processes for Windows platforms, etc.
If you got some goals, thoughts or comments that relate to the subject matter of this blog, feel free to post a comment...and have a great 2008!
Addendum:
Andrew Hay's Predictions for '08
Subscribe to:
Posts (Atom)