Okay, this is part II for this post, because I posted an awesome rant to a thread in one of the forums, and I wanted to include that here, as well, because it kind of applied...and it's my blog, I can do what I want. ;-)
The thread can be found here, and the post I'm referring to is on the third page, in response to someone mentioning, "...don't forget that if you wind up working civil or criminal cases your tools are going to get challenged in court. Open source tools are more vulnerable to attack by the opposition than commercial tools that are standardized."
My rant, if you want to call it that, had to do with what I see as a gross misconception with respect to court cases; specifically, some commercial tools are used primarily because the analysts themselves are familiar with them, and perhaps as a result, the players in the court system have also become familiar with them. That is to say that some commercial tools are recognized within the court system, and therefore, not a great deal of additional explanation is required.
As such, it isn't the tools that are challenged in court...it's the analyst and their processes.
Also, I think another huge issue that doesn't appear to be considered when folks are making statements such as the one I quoted above is that an analyst just doesn't decide one day to walk into court, take the stand, and testify. It just doesn't happen that way.
Instead, the attorney you're working with or for (prosecution or defense) is gonna want to know your answers before he asks you questions on the stand, and the fact that you're testifying and what you're testifying about are going to be part of the discovery process...so the other side is going to have a chance to cross-examine you. As such, if there's anything that would lead the attorney you're working with to suspect that you being cross-examined would sink the case, they're not going to put you on the stand. The same is true if he or she simply doesn't feel that the results of your analysis are pertinent to their case.
With me so far? I guess what I'm saying here is that there's a heck of a lot that goes on before an analyst ever gets to the point of approaching the stand in a court of law.
Now, can we agree that an acquired image is nothing more than a stream of bits, 1s and 0s, in a file on a disk? If we can agree to that, and if the integrity of that data, that stream of bits, can be verified and validated, then why does it matter what tool I use to extract data? What does it matter if an analyst determines that an illicit image is in the image using some commercial tool's Gallery View, or by mounting the image read-only with ImDisk and viewing the image file through Windows Explorer? Regardless of the tool used, the image was there, and that doesn't change. The same is true with other data...credit card numbers, other sensitive data, etc. One tool doesn't necessarily magically make it visible where some other free and/or open source tool wouldn't be able to extract the same data.
Now, don't get me wrong...I'm not against using commercial tools. I've used them myself (and I'm seeking therapy...just kidding) when the need has arisen. But the fact of the matter is that commercial forensic applications are just like any other tool, with their own inherent strengths and weaknesses. In some cases, I've found that processes using open-source and free tools, such as timeline creation tools, have allowed me to structure data for analysis in ways not possible through the use of commercial tools. In other cases, I've found short-comings in using commercial tools, just as I've found short-comings in using open-source and free tools. That doesn't mean that commercial tools shouldn't be used...it just means that all tools should be considered just for what they are...tools.
What should matter most is the process used and documentation created by the analyst. If you thoroughly document what you've done, then why shouldn't you be able to testify about it on the stand, regardless of the tools used? I know a few analysts who've documented their work such that someone else (i.e., LE) could validate their findings via commercial tools (because that's what the LE analyst was most comfortable with) and then testify about the "findings".
So, what do you think? Are open-source tools "more vulnerable to attack"? Why does it matter if I extracted a Registry hive file from an image, and then extracted the LastWrite time from a specific key using a Perl script? Or a hex editor? Or if someone else did the same thing, but through EnCase or FTK? The fact of the matter is that if you go to that location on the disk or within the hive file, extract 64-bits, everyone who does so should arrive at the same answer...right?
Or should I just curl up in the fetal position in the corner of my office, and rock myself to sleep, chanting, "I'm a pretty girl" over and over again?
Thursday, December 17, 2009
When a tool is just a tool, pt I
A tool is just a tool...that's it. A tool by any other name would smell so sweet...no, wait...what? Who let Willy Shakes in here? ;-)
I know what you're thinking..."fount of wisdom, dude." Sweet. But think about it...think about what we do, and how we do it. If you hear someone say, "yeah...I do forensics. But I need <insert commercial tool name here>", then back away slowly, don't make direct eye contact and make no sudden movements.
It's long been known that subversive tools and techniques, colloquially referred to as "anti-forensics" tools, haven't been directed at subverting other tools...no, tools such as timestomp aren't meant to subvert EnCase or even NTFS. What's being targeted here is the analyst and their training.
Not sure what I mean by this? Check out Simon's post over on Praetorian Prefect that discusses, in part, that whole COFEE/DECAF yawnfest. Simon had a previous post that addressed COFEE and some of the hype surrounding the tool set being "leaked".
When you really think about it, DECAF is meant for one thing...to subvert the use of COFEE. If the responder is a one-trick pony, and ALL they have is that COFEE package...game over, and DECAF has...no, wait...I wasn't gonna say "done it's job". No, what I was gonna say was the DECAF has demonstrated the shortcomings inherent to types of responders that rely solely on the use of one tool, such as COFEE.
Have you ever heard, "...I ran these tools, some of them didn't work...but here ya go."? I was working a fairly (in)famous engagement back in Dec '06 and one of the analysts from the primary on the contract ran the Windows tools from Helix 1.9 against a live system. I was handed the data the next day, and found that a little over half of the tools didn't have output from the tool available...they just had that "XXX is not recognized as an internal or external command" message. In this case, the issue wasn't due to something being loaded on the system, rather it was an issue of someone really knowledgeable in Linux trying to do IR on a Windows system. The one tool they had didn't work...but the system could ONLY be accessed at 2am, and the analyst had no idea that anything had gone wrong. So, even though I was tasked with doing "emergency" IR, I (and everyone else) had to wait another 24 hrs to get the data we needed.
Okay, that was three years ago...but in a lot of ways, for a LOT of responders, this really hasn't changed too terribly much. Take a malware detection gig, for example...someone has a system that they think has malware on it, so the responder acquires an image of the system, and maybe memory. They take the data back to the lab, in-process the data, then mount a working copy of the acquired image read-only and scan it with one AV scanner...and find nothing, and that's ALL they do, and they report their findings. But wait...did they check to see if the scanner they used was the same one already installed on the system? If it is, what have they really done at that point? What about the fact that a great deal of malware (depending upon what you read and who you believe, this could be as much as 40-60%) isn't detected by commercial AV the first couple of months that it's in the wild?
Are you beginning to see my point here? Look at Conficker...remember Conficker? One of the things I found most interesting about it was that it took advantage of standard business processes (ie, file shares, thumb drives) to spread on internal networks. Imagine responding to a customer site and telling them, "you're gonna have to shut down your file servers until we get this cleaned up." What the...?? A great many calls came in over the next couple of months as organizations with up-to-date AV scanning engines and signatures got p0wnd'd by variants of Conficker, Virut, and other nastiness. That's right...variants. As in, stuff that the AV couldn't see, but eventually got classified as being pretty close to the stuff that the AV could see...just not close enough for it to see it. See what I mean? Not the stuff the AV could detect, but the new stuff...stuff that did the same thing as the other stuff, but just "looked" different.
The problems and p0wnage that folks faced with this stuff had everything to do with the fact that they relied on a tool, rather than a process, to protect them. "Hey, I've got AV in place...I'm good." Who said that...the dudes from AIG? If your fallback plan was to call in an IR team...well, the malware continues to own you for 72 hrs or more as you go through contract negotiations, waiting for analysts to arrive, and finally getting them spun up on your infrastructure and the situation.
I know what you're thinking..."fount of wisdom, dude." Sweet. But think about it...think about what we do, and how we do it. If you hear someone say, "yeah...I do forensics. But I need <insert commercial tool name here>", then back away slowly, don't make direct eye contact and make no sudden movements.
It's long been known that subversive tools and techniques, colloquially referred to as "anti-forensics" tools, haven't been directed at subverting other tools...no, tools such as timestomp aren't meant to subvert EnCase or even NTFS. What's being targeted here is the analyst and their training.
Not sure what I mean by this? Check out Simon's post over on Praetorian Prefect that discusses, in part, that whole COFEE/DECAF yawnfest. Simon had a previous post that addressed COFEE and some of the hype surrounding the tool set being "leaked".
When you really think about it, DECAF is meant for one thing...to subvert the use of COFEE. If the responder is a one-trick pony, and ALL they have is that COFEE package...game over, and DECAF has...no, wait...I wasn't gonna say "done it's job". No, what I was gonna say was the DECAF has demonstrated the shortcomings inherent to types of responders that rely solely on the use of one tool, such as COFEE.
Have you ever heard, "...I ran these tools, some of them didn't work...but here ya go."? I was working a fairly (in)famous engagement back in Dec '06 and one of the analysts from the primary on the contract ran the Windows tools from Helix 1.9 against a live system. I was handed the data the next day, and found that a little over half of the tools didn't have output from the tool available...they just had that "XXX is not recognized as an internal or external command" message. In this case, the issue wasn't due to something being loaded on the system, rather it was an issue of someone really knowledgeable in Linux trying to do IR on a Windows system. The one tool they had didn't work...but the system could ONLY be accessed at 2am, and the analyst had no idea that anything had gone wrong. So, even though I was tasked with doing "emergency" IR, I (and everyone else) had to wait another 24 hrs to get the data we needed.
Okay, that was three years ago...but in a lot of ways, for a LOT of responders, this really hasn't changed too terribly much. Take a malware detection gig, for example...someone has a system that they think has malware on it, so the responder acquires an image of the system, and maybe memory. They take the data back to the lab, in-process the data, then mount a working copy of the acquired image read-only and scan it with one AV scanner...and find nothing, and that's ALL they do, and they report their findings. But wait...did they check to see if the scanner they used was the same one already installed on the system? If it is, what have they really done at that point? What about the fact that a great deal of malware (depending upon what you read and who you believe, this could be as much as 40-60%) isn't detected by commercial AV the first couple of months that it's in the wild?
Are you beginning to see my point here? Look at Conficker...remember Conficker? One of the things I found most interesting about it was that it took advantage of standard business processes (ie, file shares, thumb drives) to spread on internal networks. Imagine responding to a customer site and telling them, "you're gonna have to shut down your file servers until we get this cleaned up." What the...?? A great many calls came in over the next couple of months as organizations with up-to-date AV scanning engines and signatures got p0wnd'd by variants of Conficker, Virut, and other nastiness. That's right...variants. As in, stuff that the AV couldn't see, but eventually got classified as being pretty close to the stuff that the AV could see...just not close enough for it to see it. See what I mean? Not the stuff the AV could detect, but the new stuff...stuff that did the same thing as the other stuff, but just "looked" different.
The problems and p0wnage that folks faced with this stuff had everything to do with the fact that they relied on a tool, rather than a process, to protect them. "Hey, I've got AV in place...I'm good." Who said that...the dudes from AIG? If your fallback plan was to call in an IR team...well, the malware continues to own you for 72 hrs or more as you go through contract negotiations, waiting for analysts to arrive, and finally getting them spun up on your infrastructure and the situation.
Tuesday, December 15, 2009
Incident Prep, part deux
I've mentioned incident preparation before, and recently blogged on best practices, which was sort of a result of one of the comments to my first Incident Prep blog post. Specifically, the comment stated:
After having read the title I was really looking forward to this post, hoping I could compare our "CSIRP" against one you suggest - or at least making sure we've covered all the "must dos" and avoided the common traps...
So, this is that follow-up post...or one of them...that Anonymous asked about.
First, a couple of things...I can't suggest an online CSIRP example, per se, because there aren't many posted out there. However, I know absolutely NOTHING about Anonymous's infrastructure, so how can I recommend anything? Really? Ask me to recommend a good lunch, I know a wonderful carnivore-heaven/BBQ place nearby...but you may get there and say, "hey, I'm vegetarian!" Dude...you never said anything.
To address the other questions...again, knowing NOTHING about Anonymous's infrastructure or organization...the "must dos" are to have a CSIRP, and the common traps are to not have a CSIRP.
If you have a CSIRP and need a gap analysis, or if you need a CSIRP, here are a couple of things I can suggest to get you started...but again, these are all really dependent upon your organization, it's internal structure, as well as geographic, political and cultural considerations:
1. Is your organization subject to any legislative or regulatory oversight? Think HIPAA, PCI, etc. If so, start there. The PCI DSS v1.2, paragraph 12.9, has some information that specifies what a CSIRP should encompass, and is a good place to start...actually, for just about anyone, not just organizations subject to PCI. But the standard caveat applies...if it's associated with the PCI DSS, it's only a start.
2. CERT.ORG has an entire section on CSIRT Development.
3. Look at what you already have in place. Do you have a disaster recovery/business continuity plan? How about response plans for medical emergencies or in the event of workplace violence?
4. Keep in mind that a CSIRP is a communications plan, outlining who does what and when, in the event of an incident. Consider this...during CPR training, trainees are told to point to someone and say, "Call 911!" If there's a crowd gathered 'round and you just say, "would someone call 911?", what're the chances someone will do so? It's a good bet that everyone in the crowd will be thinking that someone else will do it...so you need to designate response staff. Think Star Trek, only without the dudes in red shirts.
Finally, and perhaps most importantly, if you're considering hiring outside consultants to assist with CSIRP development, you have to understand that this is NOT a drive-by service. What this means is that you cannot expect to hire someone to come in and drop off a CSIRP for you...at least, not without spending 6-9 months as a member of your staff. Why is that, you ask? Consider what I've said in previous posts...what is considered best practice for one organization may be completely undoable to another. It takes work, but ultimately your organization will have to take ownership of the CSIRP...after all, it's yours; your data, your infrastructure, your CSIRP.
After having read the title I was really looking forward to this post, hoping I could compare our "CSIRP" against one you suggest - or at least making sure we've covered all the "must dos" and avoided the common traps...
So, this is that follow-up post...or one of them...that Anonymous asked about.
First, a couple of things...I can't suggest an online CSIRP example, per se, because there aren't many posted out there. However, I know absolutely NOTHING about Anonymous's infrastructure, so how can I recommend anything? Really? Ask me to recommend a good lunch, I know a wonderful carnivore-heaven/BBQ place nearby...but you may get there and say, "hey, I'm vegetarian!" Dude...you never said anything.
To address the other questions...again, knowing NOTHING about Anonymous's infrastructure or organization...the "must dos" are to have a CSIRP, and the common traps are to not have a CSIRP.
If you have a CSIRP and need a gap analysis, or if you need a CSIRP, here are a couple of things I can suggest to get you started...but again, these are all really dependent upon your organization, it's internal structure, as well as geographic, political and cultural considerations:
1. Is your organization subject to any legislative or regulatory oversight? Think HIPAA, PCI, etc. If so, start there. The PCI DSS v1.2, paragraph 12.9, has some information that specifies what a CSIRP should encompass, and is a good place to start...actually, for just about anyone, not just organizations subject to PCI. But the standard caveat applies...if it's associated with the PCI DSS, it's only a start.
2. CERT.ORG has an entire section on CSIRT Development.
3. Look at what you already have in place. Do you have a disaster recovery/business continuity plan? How about response plans for medical emergencies or in the event of workplace violence?
4. Keep in mind that a CSIRP is a communications plan, outlining who does what and when, in the event of an incident. Consider this...during CPR training, trainees are told to point to someone and say, "Call 911!" If there's a crowd gathered 'round and you just say, "would someone call 911?", what're the chances someone will do so? It's a good bet that everyone in the crowd will be thinking that someone else will do it...so you need to designate response staff. Think Star Trek, only without the dudes in red shirts.
Finally, and perhaps most importantly, if you're considering hiring outside consultants to assist with CSIRP development, you have to understand that this is NOT a drive-by service. What this means is that you cannot expect to hire someone to come in and drop off a CSIRP for you...at least, not without spending 6-9 months as a member of your staff. Why is that, you ask? Consider what I've said in previous posts...what is considered best practice for one organization may be completely undoable to another. It takes work, but ultimately your organization will have to take ownership of the CSIRP...after all, it's yours; your data, your infrastructure, your CSIRP.
Monday, December 14, 2009
Link-idy link-idy
Tools
Claus (no, I'm not saying that Claus is a tool...) has posted a nice summary of some of the free tools posts from WindowsIR and added some really nice grep tools for the Windows platform. Using tools like this would greatly increase an analyst's capabilities with respect to some of the Analysis stuff I've mentioned recently. For instance, if you're interested in doing searches for PANs/CCNs, you can use BareGrep and consult the Regex reference for syntax in writing your regex; of course, additional checks will be necessary (in particular, the Luhn formula) to reduce false positives, but it's a start.
Memory
JL's got a new Misc Stuff post goin' on over on her blog. I'd picked up on the demise of support for mdd.exe from her blog post, as well as from Volatility (note the recommendation to use Matthieu Suiche's windd for your memory dumping needs). She also points out that MHL has some new and updated Volatility plugins, even one that incorporates YARA for scanning of malware!
Analysis
Speaking of malware analysis, Kristinn posted on PDF Malware Analysis over on the SANS Forensic Blog, as well. Add this information to Lenny's cheat sheet, and you can develop a pretty decent approach for determining the method by which a system was compromised or infected. This is often one of the most difficult aspects of analysis, and very often left to speculation in a report. Many times, the assumption is made that the initial infection/compromise vector was via web browser "drive-by" ("browse-by"??)...I say "assumption" because there is no specific data or analysis within the report which supports the statement. In most cases, the assumption is based on malware write-ups provided by AV vendors; this may be an initial indicator, but the analysis of identified files using techniques such as those identified by Kristinn and others, and listed in Lenny's cheat sheet, can provide definitive answers, and potentially even identify sources and additional issues.
Anti-Analysis
Remember the hoopla surrounding MS's COFEE being leaked? Well, check out DECAF. I wonder how this will affect other response toolkits and techniques that are similar to COFEE? Check out this post from the Praetorian Prefect blog on DECAF (thanks to Claus for the mention of the blog...).
Claus (no, I'm not saying that Claus is a tool...) has posted a nice summary of some of the free tools posts from WindowsIR and added some really nice grep tools for the Windows platform. Using tools like this would greatly increase an analyst's capabilities with respect to some of the Analysis stuff I've mentioned recently. For instance, if you're interested in doing searches for PANs/CCNs, you can use BareGrep and consult the Regex reference for syntax in writing your regex; of course, additional checks will be necessary (in particular, the Luhn formula) to reduce false positives, but it's a start.
Memory
JL's got a new Misc Stuff post goin' on over on her blog. I'd picked up on the demise of support for mdd.exe from her blog post, as well as from Volatility (note the recommendation to use Matthieu Suiche's windd for your memory dumping needs). She also points out that MHL has some new and updated Volatility plugins, even one that incorporates YARA for scanning of malware!
Analysis
Speaking of malware analysis, Kristinn posted on PDF Malware Analysis over on the SANS Forensic Blog, as well. Add this information to Lenny's cheat sheet, and you can develop a pretty decent approach for determining the method by which a system was compromised or infected. This is often one of the most difficult aspects of analysis, and very often left to speculation in a report. Many times, the assumption is made that the initial infection/compromise vector was via web browser "drive-by" ("browse-by"??)...I say "assumption" because there is no specific data or analysis within the report which supports the statement. In most cases, the assumption is based on malware write-ups provided by AV vendors; this may be an initial indicator, but the analysis of identified files using techniques such as those identified by Kristinn and others, and listed in Lenny's cheat sheet, can provide definitive answers, and potentially even identify sources and additional issues.
Anti-Analysis
Remember the hoopla surrounding MS's COFEE being leaked? Well, check out DECAF. I wonder how this will affect other response toolkits and techniques that are similar to COFEE? Check out this post from the Praetorian Prefect blog on DECAF (thanks to Claus for the mention of the blog...).
Friday, December 11, 2009
Some New Stuff
F-Response
In case you hadn't noticed, Matt posted recently that F-Response works on Google Chrome OS! Very cool! That's another one for Matt, and in this case, he wasn't even trying!
CheatSheets
From the SANS Internet Storm Center, I found an interesting link on cheatsheets for analyzing malicious documents. This took me to Lenny Zeltser's site where he not only has the info up on a web page (click links to get the tools), but also PDF and DOCX versions of the sheet. Lenny also hosts a series of cheatsheets, some of which look quite useful.
PodCasts
In addition to the CyberSpeak and Forensic4Cast podcasts, Andy and friends have come out with Episode 0 of the Southern Fried Security podcast! The podcast faded in and out several times, but I have to say that I really enjoyed the fact that the guys discussed the business end of patch management...too often this sort of thinking is missed by purely technical guys, whether during incident response activities or pen tests.
In The "News"
I usually don't follow The Register, but I did see something come across a list recently that talked about "RAM scrappers" which, of course, caught my eye. A couple of things struck me as interesting about this article, in large part due to the fact that when I was working for a QIRA-certified organization conducting PCI forensic assessments, I (and others) saw incidents involving this sort of malware. These types of incidents involve extremely targeted attacks, as one of the malware components dumps the virtual memory of several specifically-named processes...which, from the card swipe at the P0S terminal through authorization and processing, is the only place where the track data is unencrypted. One of those things that isn't quite right in the article, however, is that you won't expect to find Perl scripts on the system, as Windows doesn't ship with Perl installed...what you'll find is a Perl script (used to parse the virtual memory dump for track data) "compiled" using Perl2Exe with no switches...that last part will make sense to anyone who is involved in IR/DF and has some knowledge of Perl2Exe.
It appears that at least some part of the article was based on this Verizon Business data breach investigations supplemental report (thanks to Jamie for the link!)...drop down to page 20 and you'll see what I'm referring to. Notice that the Case Example section lists four file names...three EXE and one BAT...and the Indicators section refers to "perl scripts". If this were the case, one would think that there would be at least one file listed with a .pl extension.
Don't get me wrong...I'm not knocking the article or the report at all. I think that this kind of thing is great to see, but I do think that to the discerning eye, this sort of thing does open up from some questions, as well as an opportunity for sharing...not only amongst analysts, but also with LE.
'Zine
Speaking of sharing, let's not forget the ITB...the Into The Boxes e-zine coming out in the not-too-distant future!
In case you hadn't noticed, Matt posted recently that F-Response works on Google Chrome OS! Very cool! That's another one for Matt, and in this case, he wasn't even trying!
CheatSheets
From the SANS Internet Storm Center, I found an interesting link on cheatsheets for analyzing malicious documents. This took me to Lenny Zeltser's site where he not only has the info up on a web page (click links to get the tools), but also PDF and DOCX versions of the sheet. Lenny also hosts a series of cheatsheets, some of which look quite useful.
PodCasts
In addition to the CyberSpeak and Forensic4Cast podcasts, Andy and friends have come out with Episode 0 of the Southern Fried Security podcast! The podcast faded in and out several times, but I have to say that I really enjoyed the fact that the guys discussed the business end of patch management...too often this sort of thinking is missed by purely technical guys, whether during incident response activities or pen tests.
In The "News"
I usually don't follow The Register, but I did see something come across a list recently that talked about "RAM scrappers" which, of course, caught my eye. A couple of things struck me as interesting about this article, in large part due to the fact that when I was working for a QIRA-certified organization conducting PCI forensic assessments, I (and others) saw incidents involving this sort of malware. These types of incidents involve extremely targeted attacks, as one of the malware components dumps the virtual memory of several specifically-named processes...which, from the card swipe at the P0S terminal through authorization and processing, is the only place where the track data is unencrypted. One of those things that isn't quite right in the article, however, is that you won't expect to find Perl scripts on the system, as Windows doesn't ship with Perl installed...what you'll find is a Perl script (used to parse the virtual memory dump for track data) "compiled" using Perl2Exe with no switches...that last part will make sense to anyone who is involved in IR/DF and has some knowledge of Perl2Exe.
It appears that at least some part of the article was based on this Verizon Business data breach investigations supplemental report (thanks to Jamie for the link!)...drop down to page 20 and you'll see what I'm referring to. Notice that the Case Example section lists four file names...three EXE and one BAT...and the Indicators section refers to "perl scripts". If this were the case, one would think that there would be at least one file listed with a .pl extension.
Don't get me wrong...I'm not knocking the article or the report at all. I think that this kind of thing is great to see, but I do think that to the discerning eye, this sort of thing does open up from some questions, as well as an opportunity for sharing...not only amongst analysts, but also with LE.
'Zine
Speaking of sharing, let's not forget the ITB...the Into The Boxes e-zine coming out in the not-too-distant future!
Monday, December 07, 2009
Plugin Browser - New RegRipper Tool
One of the things I've noticed since I first released the tools with RegRipper was that I thought I had a great idea by providing functionality in rip.pl/.exe to create a list of plugins with details, including which hive each plugin is intended for, the version, etc. In fact, I included the ability to create a listing of plugins in .csv format, so you could open the list in Excel.To do this, you'd use the command line:
C:\tools>rip.pl -l -c > plugins.csv
However, I don't think that this really caught on. Over the past year or so, I've received requests for plugins that are already part of the currently available distribution.
However, the current version of rip.pl (i.e., released with RegRipper v.2.02) relies on the fact that the plugins directory (i.e., the directory where you keep your plugins) is set and stagnant, and that you don't change it. In the new version of RegRipper, I'm supporting a user-configurable plugin directory setting.
So this is a neat little tool that came out of my work with some different UI things I have been working with and trying lately. In putting together some of the new RegRipper tools, I wanted to have something of an updated user interface; I'm programming the UI using Win32::GUI. The Plugin Browser tool came out of the desire to try some of the things I found, as well as just wanting to have something a little different.
Addendum: Based on Adam's comment to the initial post, I updated the tool to include the ability to create plugins files. As you can see in the second image, I added tabs to the UI, one of which allows you to select plugins from the list on the left, add them to the list on the right, and then click the Save button (notice the tooltip for that button visible in the image). As the plugins file will be using plugins from a particular directory, the plugins file will be saved in that directory...otherwise, the RegRipper tools won't know where to go to get the actual plugins!
One of the cool things about this is that as you're building your plugins file, you can go back and forth between the Browse and Plugin File tabs, looking at what hive the plugin is for and what it extracts, then adding it to your plugins file.
Once you save the plugins file, the content of the listbox on the right will be cleared.
Pretty cool stuff, eh?
Friday, December 04, 2009
Best Practices: What is 'best'?
I know what you're thinking..."What?!?"
As a consultant, many times I will be asked, "what are 'best practices'?" or "can you give us 'best practices'?" Well, I've often thought...what ARE 'best practices'? When I look around at best practices for various things...CSIRPs, IR, etc....I find that many times, the publicly available best practices are based on a particular technology or a particular corporate culture, and will simply not be best or even work at all for a particular customer environment.
Here's an example that I look at, because I have seen it so many times...you're a corporate security person, tasked with some level of incident response. You work for the CISO, and the corporate IT department (which includes the SOC) is nowhere in your management chain. The data center is either in another part of the building, or in another building nearby. During IR activities, you may need to obtain data (could be anything in the IR triad...network captures, data from devices, or host-based data, which includes memory and images) from systems managed by the SOC.
What are best practices for this type of situation? Truth be told, you can come up with any best practice, and I can come up with at least one real-world example or reason, and possibly more, why it simply won't work.
So, one best practice might be to immediately go to the data center, take the affected system off-line, and acquire an image of the hard drive via a write-blocker. As the IR guy, do you have access to the data center? In many cases I worked, this would be a big "no". Can you take the affected system off-line? Again...no. The system may be critical, may be RAID, or may be boot-from-SAN. Do you have money to purchase write-blockers? Again...in many cases, no.
The next approach might be to cultivate relationships with the SOC staff and get them to help you. This works sometimes, but it's usually best effort, not best practice. Does the SOC staff have the ability or training to assist you? Sure, plugging in an external HDD and running FTK Imager to obtain a live acquisition might sound easy, but try doing it when it's not part of your job, you aren't trained for it, and your manager/boss is screaming at the team to get stuff done that's already overdue.
Okay, what about pre-deploying a solution? That might work, but remember, you don't own the systems in the data center, so installing some sort of agent, not to monitor, but to allow you to collect data might not be something that you can do...at least not easily. And we all know what happens when the tasks pile up...anything related to security gets popped off the stack.
I once supported an organization in which the CIRT had NO access to anything in the infrastructure...they didn't even have admin access to their own systems. IF something was flagged and IF the CIRT received notification of it, then they had to ask the NOC staff to collect information from the affected system(s). This amounted to running a single tool against the systems...not a batch file of tools, just one single tool...and more often than not the data wasn't returned in anything close to what you might consider timely.
Sometimes, best practices don't turn out to be usable practices at all. When considering best practices, we need to look beyond just the technology and take geographical, political, and cultural considerations into play.
As a consultant, many times I will be asked, "what are 'best practices'?" or "can you give us 'best practices'?" Well, I've often thought...what ARE 'best practices'? When I look around at best practices for various things...CSIRPs, IR, etc....I find that many times, the publicly available best practices are based on a particular technology or a particular corporate culture, and will simply not be best or even work at all for a particular customer environment.
Here's an example that I look at, because I have seen it so many times...you're a corporate security person, tasked with some level of incident response. You work for the CISO, and the corporate IT department (which includes the SOC) is nowhere in your management chain. The data center is either in another part of the building, or in another building nearby. During IR activities, you may need to obtain data (could be anything in the IR triad...network captures, data from devices, or host-based data, which includes memory and images) from systems managed by the SOC.
What are best practices for this type of situation? Truth be told, you can come up with any best practice, and I can come up with at least one real-world example or reason, and possibly more, why it simply won't work.
So, one best practice might be to immediately go to the data center, take the affected system off-line, and acquire an image of the hard drive via a write-blocker. As the IR guy, do you have access to the data center? In many cases I worked, this would be a big "no". Can you take the affected system off-line? Again...no. The system may be critical, may be RAID, or may be boot-from-SAN. Do you have money to purchase write-blockers? Again...in many cases, no.
The next approach might be to cultivate relationships with the SOC staff and get them to help you. This works sometimes, but it's usually best effort, not best practice. Does the SOC staff have the ability or training to assist you? Sure, plugging in an external HDD and running FTK Imager to obtain a live acquisition might sound easy, but try doing it when it's not part of your job, you aren't trained for it, and your manager/boss is screaming at the team to get stuff done that's already overdue.
Okay, what about pre-deploying a solution? That might work, but remember, you don't own the systems in the data center, so installing some sort of agent, not to monitor, but to allow you to collect data might not be something that you can do...at least not easily. And we all know what happens when the tasks pile up...anything related to security gets popped off the stack.
I once supported an organization in which the CIRT had NO access to anything in the infrastructure...they didn't even have admin access to their own systems. IF something was flagged and IF the CIRT received notification of it, then they had to ask the NOC staff to collect information from the affected system(s). This amounted to running a single tool against the systems...not a batch file of tools, just one single tool...and more often than not the data wasn't returned in anything close to what you might consider timely.
Sometimes, best practices don't turn out to be usable practices at all. When considering best practices, we need to look beyond just the technology and take geographical, political, and cultural considerations into play.
Wednesday, December 02, 2009
Linkaliciousness
Timeline Stuff
Don has put together something very interesting with respect to timeline creation called System Combo Timeline; it looks like he's added quite a degree of automation (following artifact extraction) to the whole process of creating timelines (in TLN format) on Windows systems.
Download syscombotln and smell what Don's been cookin'!
Analysis
Speaking of Don, he and I were chatting the other day, and during the course of our discussion, we covered an analysis technique. Now, I have no doubt that this technique is NOT new, and I am sure that there are folks out there who've used it in one form or another...however, I wanted to present it here in the hopes that someone would see it and use it, or add to it. So, starting with an acquired image from a Windows system, do the following:
1. Extract unstructured data (i.e., pagefile, unallocated space via blkls, etc.).
2. Parse the output with strings (the version from MS includes a -o switch that outputs the offset of each string within the file).
3. Search the output of strings for specific items; indications of commands being run (wget, etc.) and/or other Windows artifacts. This can be run on Windows using a keyword list in a file, via findstr (see the /G switch).
4a. Using your scripting language of choice, read in the output of strings and when you find a "hit of interest", access the original data at the offset provided by strings, and extract either X bytes on either side of the hit, or X bytes from the hit going forward; now, you've got something of a search hit preview capability (a la EnCase).
4b. Using your scripting language of choice, process any discovered Windows artifacts based on their structure; I've seen hits such as nk and hbin (Registry keys and hives, respectively), as well as LfLe (event records). We know how to process the structures, so this is pretty straightforward.
5. You can also carve the unstructured data for files (via PhotoRec, scalpel, or foremost) as well as indications of Internet activity (i.e., Internet Evidence Finder).
Like I said...this is nothing new, I'm sure. I just wanted to put it out there so that others could see it, and perhaps provide their own take, or even add to it. I've run this technique on a test image, and found entire pages of source code, as well as some nifty artifacts.
Document Metadata
Something cool from the SANS Forensic blog was the ability to pull VB script macros from Office documents, using OfficeMalScanner. This looks like an excellent means by which you can investigate an intrusion, particularly if you find Office documents in web browser download or email attachment directories.
Other useful tools for examining Office document metadata include OffVis (pre-Office 2007) and cat_open_xml.pl from Kristinn. Note that Windows 7 uses the OLE format for a number of file types, including Sticky Notes, so OffVis will be very useful.
RegRipper
It seems RegRipper has gained popularity around the world! Pedro from Spain found RegRipper interesting enough to post about...thanks, Pedro! Gracias!
Speaking of RegRipper, Mike Tarnawsky sent me a plugin he'd written to extract the Internet Server Cache from the Office Registry keys in the user's hive. This plugin (oisc.pl) is posted in the RegRipper.net forum, as well as in the Win4n6 Yahoo Group Files section. Mike did a great job putting it together and even provided references in the header of the plugin that help the analyst to understand why the data is being extracted, and how it can be important to an investigation. Thanks, Mike!
Don has put together something very interesting with respect to timeline creation called System Combo Timeline; it looks like he's added quite a degree of automation (following artifact extraction) to the whole process of creating timelines (in TLN format) on Windows systems.
Download syscombotln and smell what Don's been cookin'!
Analysis
Speaking of Don, he and I were chatting the other day, and during the course of our discussion, we covered an analysis technique. Now, I have no doubt that this technique is NOT new, and I am sure that there are folks out there who've used it in one form or another...however, I wanted to present it here in the hopes that someone would see it and use it, or add to it. So, starting with an acquired image from a Windows system, do the following:
1. Extract unstructured data (i.e., pagefile, unallocated space via blkls, etc.).
2. Parse the output with strings (the version from MS includes a -o switch that outputs the offset of each string within the file).
3. Search the output of strings for specific items; indications of commands being run (wget, etc.) and/or other Windows artifacts. This can be run on Windows using a keyword list in a file, via findstr (see the /G switch).
4a. Using your scripting language of choice, read in the output of strings and when you find a "hit of interest", access the original data at the offset provided by strings, and extract either X bytes on either side of the hit, or X bytes from the hit going forward; now, you've got something of a search hit preview capability (a la EnCase).
4b. Using your scripting language of choice, process any discovered Windows artifacts based on their structure; I've seen hits such as nk and hbin (Registry keys and hives, respectively), as well as LfLe (event records). We know how to process the structures, so this is pretty straightforward.
5. You can also carve the unstructured data for files (via PhotoRec, scalpel, or foremost) as well as indications of Internet activity (i.e., Internet Evidence Finder).
Like I said...this is nothing new, I'm sure. I just wanted to put it out there so that others could see it, and perhaps provide their own take, or even add to it. I've run this technique on a test image, and found entire pages of source code, as well as some nifty artifacts.
Document Metadata
Something cool from the SANS Forensic blog was the ability to pull VB script macros from Office documents, using OfficeMalScanner. This looks like an excellent means by which you can investigate an intrusion, particularly if you find Office documents in web browser download or email attachment directories.
Other useful tools for examining Office document metadata include OffVis (pre-Office 2007) and cat_open_xml.pl from Kristinn. Note that Windows 7 uses the OLE format for a number of file types, including Sticky Notes, so OffVis will be very useful.
RegRipper
It seems RegRipper has gained popularity around the world! Pedro from Spain found RegRipper interesting enough to post about...thanks, Pedro! Gracias!
Speaking of RegRipper, Mike Tarnawsky sent me a plugin he'd written to extract the Internet Server Cache from the Office Registry keys in the user's hive. This plugin (oisc.pl) is posted in the RegRipper.net forum, as well as in the Win4n6 Yahoo Group Files section. Mike did a great job putting it together and even provided references in the header of the plugin that help the analyst to understand why the data is being extracted, and how it can be important to an investigation. Thanks, Mike!
Sunday, November 29, 2009
Incident Preparation
In the course of my work, I will often encounter a customer's computer security incident response plan, or CSIRP...often, not always. In some cases, it may be that the customer had a CSIRP, and simply wanted validation of the plan and their processes, or a gap analysis. However, in most cases, responders such as myself encounter a complete lack of a CSIRP all together, which is an indicator that the organization we're assisting was not prepared for an incident at all.
In the end, the true impact of this fact is on the customer themselves (which, in may cases, may be passed on to their customers), who may have already been subject to an intrusion/compromise, and may be facing notification costs, fines...and maybe more.
The Art of Preparation
No, preparation for incident really isn't an art...I just wanted to get you to read further. The fact is, we all know what incident preparation is and consists of, because we do it all the time. An easy example of incident preparation is when we notice that the fuel gauge in our car is nearing the big "E". We anticipate a potential incident (i.e., running out of gas) was we take steps to prepare and mitigate the risks associated with an empty gas tank...we go to the gas station and fill up.
How about those of us who live in states where it may snow? We anticipate the risks associated with a driveway covered in snow, and we prepare to mitigate those risks; we get shovels, maybe some driveway de-icer compound, make sure we have a scraper available, etc. These aren't all the steps we may take...it really depends on where we live, and how willing we are to prepare.
So let's say someone lives in Maine or Minnesota, and makes a habit of NOT having a shovel, de-icer, tire chains, a full tank of gas, etc? Is this person prepared? Given that they're in a state with a high probability of it snowing, wouldn't it be prudent to take the necessary steps to prepare for an incident that has a high likelihood of occurring?
I would suggest to you that if your organization uses any sort of computing resources, the likelihood of you having (or, having had) a computer security incident of some kind is akin to that of it snowing in Maine in the winter months (and I know that this year, it already has!)...that is, the probability is rapidly approaching certainty. So why not be prepared?
Temporal Proximity
This is a term I heard a friend of mine use several years ago, and because I like stuff like Star Trek and the SciFi Channel, I keep it in the back of my brain housing group, ready to bring forth and assault my readers with. Oddly enough, it has a purpose here...that is, the closer proximity to the incident (with respect to time) that you begin collecting information and containing that incident, the greater your ability to really understand what's going on and address the issues of the incident. I'll use an example to illustrate what I mean...actually, a combination of several examples: a "victim" organization is notified of a breach of data by an outside third party, fully three months after the breach occurred. After about a week of trying to understand what could have happened, a responder such as myself is called in to assist. At that point, logs have rolled over and not been saved, systems have been taken out of service and reprovisioned, and IT staff is so busy that they can't remember what they had for breakfast, let alone what happened almost four months previously.
Another good example (by good, I really mean "seen often", not that the issue itself is good) is adding to the temporal dispersion by having relatively untrained staff conduct an "investigation" into the incident. By this point, systems have been scanned and rebooted (sometimes several times), patches installed, and again, some systems may have been rotated into or out of service. At this point, there is so much time (temporal dispersion) and activity between when the incident occurred and when any really meaningful steps are taken to respond to the incident, that the actual response activities are close to futile.
Consider an episode of your favorite variation of CSI, and let's say a crime occurred in a residence; if there is nothing mentioned about the crime for three years, and in that time, the residence has been burned to the ground, the structure completely razed and carted off to the dump, and a commercial structure built up in it's place, how is Grissom or Mac Taylor gonna to solve the crime?
Key Elements
Some of the key elements of Incident Preparation are your CSIRP, an understanding of your infrastructure (in particular, where your critical assets/data are located), and instrumentation. Without instrumentation, you have no visibility into what's happening within your infrastructure. Guys in submarines don't troll around the ocean depths without some sort of ability and instrumentation to determine where they are and what's going on around them. Instrumentation gives you visibility, and as such, decreases temporal proximity, particularly for intrusions or incidents of sensitive data leakage/theft.
In the end, the true impact of this fact is on the customer themselves (which, in may cases, may be passed on to their customers), who may have already been subject to an intrusion/compromise, and may be facing notification costs, fines...and maybe more.
The Art of Preparation
No, preparation for incident really isn't an art...I just wanted to get you to read further. The fact is, we all know what incident preparation is and consists of, because we do it all the time. An easy example of incident preparation is when we notice that the fuel gauge in our car is nearing the big "E". We anticipate a potential incident (i.e., running out of gas) was we take steps to prepare and mitigate the risks associated with an empty gas tank...we go to the gas station and fill up.
How about those of us who live in states where it may snow? We anticipate the risks associated with a driveway covered in snow, and we prepare to mitigate those risks; we get shovels, maybe some driveway de-icer compound, make sure we have a scraper available, etc. These aren't all the steps we may take...it really depends on where we live, and how willing we are to prepare.
So let's say someone lives in Maine or Minnesota, and makes a habit of NOT having a shovel, de-icer, tire chains, a full tank of gas, etc? Is this person prepared? Given that they're in a state with a high probability of it snowing, wouldn't it be prudent to take the necessary steps to prepare for an incident that has a high likelihood of occurring?
I would suggest to you that if your organization uses any sort of computing resources, the likelihood of you having (or, having had) a computer security incident of some kind is akin to that of it snowing in Maine in the winter months (and I know that this year, it already has!)...that is, the probability is rapidly approaching certainty. So why not be prepared?
Temporal Proximity
This is a term I heard a friend of mine use several years ago, and because I like stuff like Star Trek and the SciFi Channel, I keep it in the back of my brain housing group, ready to bring forth and assault my readers with. Oddly enough, it has a purpose here...that is, the closer proximity to the incident (with respect to time) that you begin collecting information and containing that incident, the greater your ability to really understand what's going on and address the issues of the incident. I'll use an example to illustrate what I mean...actually, a combination of several examples: a "victim" organization is notified of a breach of data by an outside third party, fully three months after the breach occurred. After about a week of trying to understand what could have happened, a responder such as myself is called in to assist. At that point, logs have rolled over and not been saved, systems have been taken out of service and reprovisioned, and IT staff is so busy that they can't remember what they had for breakfast, let alone what happened almost four months previously.
Another good example (by good, I really mean "seen often", not that the issue itself is good) is adding to the temporal dispersion by having relatively untrained staff conduct an "investigation" into the incident. By this point, systems have been scanned and rebooted (sometimes several times), patches installed, and again, some systems may have been rotated into or out of service. At this point, there is so much time (temporal dispersion) and activity between when the incident occurred and when any really meaningful steps are taken to respond to the incident, that the actual response activities are close to futile.
Consider an episode of your favorite variation of CSI, and let's say a crime occurred in a residence; if there is nothing mentioned about the crime for three years, and in that time, the residence has been burned to the ground, the structure completely razed and carted off to the dump, and a commercial structure built up in it's place, how is Grissom or Mac Taylor gonna to solve the crime?
Key Elements
Some of the key elements of Incident Preparation are your CSIRP, an understanding of your infrastructure (in particular, where your critical assets/data are located), and instrumentation. Without instrumentation, you have no visibility into what's happening within your infrastructure. Guys in submarines don't troll around the ocean depths without some sort of ability and instrumentation to determine where they are and what's going on around them. Instrumentation gives you visibility, and as such, decreases temporal proximity, particularly for intrusions or incidents of sensitive data leakage/theft.
Wednesday, November 25, 2009
More Timeline Creation Techniques
Some of you may have seen (or be using) the timeline tools I released within the Win4n6 Yahoo group and included in my most recent Hakin9 article on Windows Timeline Analysis. If you've taken a look at the tools, you'll notice that I have some tools available for parsing Event Logs from Windows 2000, XP, and 2003 (i.e., .evt files) into the timeline (TLN) format I use. However, there's nothing there, at the moment, for parsing Windows Event Log/.evtx files from Vista, Windows 2008, or Windows 7.
A quick look around showed me that there weren't many free (as in beer) tools for parsing .evtx files. Andreas Schuster has done a good deal of work in this area, has picked apart some of the .evtx data types, and made some tools and an article on the subject available. However, these tools are somewhat limited due to the nature of the new .evtx file format.
Then along came LogParser...freely available from MS and extremely flexible. There are a number of sites available that are dedicated to or include the use of LogParser, and there's even a GUI or two available. However, that's a bit beyond what we're going to talk about at the moment.
You can download the Logparser.msi file from MS and install it, and then copy the files from the installation folder to a thumb drive or CD, making the tool available for live incident response activities. What this means is that you now have a platform-independent means for extracting event records from Windows systems. Using this command:
E:\>logparser -i:evt -o:csv "Select * from System" > %ComputerName%-system.csv
...will do the same thing on Windows XP as it will on Vista or Windows 2008. Now, you have a nice comma-separated value file that you can open in Excel or parse with Perl, and include the entries in a timeline.
Okay, that's live response...what about post-mortem analysis? Well, it turns out that there's a couple of ways you can go on this issue. The first is to have a VM available for each version of Windows, or at least one on the Windows XP/2003 side, and one on the Vista/Windows 7 side. For example, you can mount or access an image of a Windows 2008 system on Windows 7 system, extract the .evtx files, and use the following command:
C:\tools>logparser -i:evt -o:csv "Select * from d:\cases\System.evtx" > system.csv
At this point, all you need to do is parse the resulting .csv file...Perl works quite nicely for this.
The other option is to use just Windows 2008 or Windows 7 as your analysis platform, and convert the .evt files to .evtx format using wevtutil.exe.
C:\tools>wevtutil epl AppEvent.evt AppEvent.evtx /lf:true
This gives you the ability to parse both .evt and .evtx formats on the same platform. However, if you're primarily interested in producing a timeline of events, the timeline tools from the Win4n6 Yahoo group contain a Perl script that parses .evt files into TLN format, without relying on the API. Also, the timeline tools for parsing .evt files will be able to extract event records that aren't "seen" by the API.
A quick look around showed me that there weren't many free (as in beer) tools for parsing .evtx files. Andreas Schuster has done a good deal of work in this area, has picked apart some of the .evtx data types, and made some tools and an article on the subject available. However, these tools are somewhat limited due to the nature of the new .evtx file format.
Then along came LogParser...freely available from MS and extremely flexible. There are a number of sites available that are dedicated to or include the use of LogParser, and there's even a GUI or two available. However, that's a bit beyond what we're going to talk about at the moment.
You can download the Logparser.msi file from MS and install it, and then copy the files from the installation folder to a thumb drive or CD, making the tool available for live incident response activities. What this means is that you now have a platform-independent means for extracting event records from Windows systems. Using this command:
E:\>logparser -i:evt -o:csv "Select * from System" > %ComputerName%-system.csv
...will do the same thing on Windows XP as it will on Vista or Windows 2008. Now, you have a nice comma-separated value file that you can open in Excel or parse with Perl, and include the entries in a timeline.
Okay, that's live response...what about post-mortem analysis? Well, it turns out that there's a couple of ways you can go on this issue. The first is to have a VM available for each version of Windows, or at least one on the Windows XP/2003 side, and one on the Vista/Windows 7 side. For example, you can mount or access an image of a Windows 2008 system on Windows 7 system, extract the .evtx files, and use the following command:
C:\tools>logparser -i:evt -o:csv "Select * from d:\cases\System.evtx" > system.csv
At this point, all you need to do is parse the resulting .csv file...Perl works quite nicely for this.
The other option is to use just Windows 2008 or Windows 7 as your analysis platform, and convert the .evt files to .evtx format using wevtutil.exe.
C:\tools>wevtutil epl AppEvent.evt AppEvent.evtx /lf:true
This gives you the ability to parse both .evt and .evtx formats on the same platform. However, if you're primarily interested in producing a timeline of events, the timeline tools from the Win4n6 Yahoo group contain a Perl script that parses .evt files into TLN format, without relying on the API. Also, the timeline tools for parsing .evt files will be able to extract event records that aren't "seen" by the API.
Sunday, November 22, 2009
Even More Linky Goodness...
Tools
I received an email recently that let me know that the latest version of RevealerToolkit is available, a project from a Barcelona security company. The RVT framework is based on Brian Carrier's TSK tools, and even makes use of some of my code to parse EVT files. More information on RVT is available here. Also, be sure to take a look at the user guide, as well.
Remember when I got p0wned by Intel and MS? Thanks to a blog comment, I was pointed to VMLite, which provides an alternative to MS's XPMode, and without the requirement for hardware virtualization in the CPU. This may definitely be something to take a look at, as virtualization can play pretty important role in forensic analysis in a number of ways. Take a look at packages such as MojoPac and Moka-5, for example.
Rob Lee pointed the GCFA mailing list to RE-Google the other day...this is apparently (quoted) a plugin for the Interactive DisAssembler (IDA) Pro that queries Google Code for information about the functions contained in a disassembled binary. Wow, that sounds pretty cool!
Lance has posted another EnScript, this one to locate Limewire download remnants. This may be pertinent if you're looking at a case involving Limewire or just P2P in general.
Speaking of Lance, I've used the images he has made available for his practicals as examples on a number of occasions; these are excellent resources. However, if you want to work with these practicals as raw dd images (rather than .E0x format), you'll need to convert them using something like FTK Imager. But if you want to mount the EWF/EOx format images and access the files within them, you can use mount_ewf, which Chris has talked about. To do this on Windows, you need to follow these steps (from David Loveall, which Rob Lee so graciously provided to the Win4n6 Yahoo group):
1. Extract the mount_ewf files for Windows into a directory
2. Download and install the Visual Studio runtime files, if you don't already have them
3. Download and install ImDisk
At this point, you should just be able to double-click the E01 file, and tell it Open With... mount_ewf.exe. I'll have to say that I haven't tested this as of yet, but if you've got E0x files you'd like to access, but don't want to have to give up additional space in converting it to raw dd format, this may be an option. P2 Explorer (free) and SmartMount (not free) will also allow you to mount EWF/E0x format images.
Memory Collection and Analysis
An engineer at HBGary recently posted a review of Matthieu's windd tool, based on testing against their own FDPro tool. It's an interesting read...take a look. Here's Matthieu's response, along with some personal notes. I think it's good to see, read, and digest both sides of an issue, and this is definitely worth taking a look at.
On the analysis end of things, Jeff Bryner posted about his FaceBook Memory Forensics tool (ie, pdfbook) on the SANS Forensics Blog recently. Jeff's posted about other tools for parsing memory dumps, and I'm sure that you could use the output of the tool you're using (as opposed to pd.exe, as he mentions in the blog post) to obtain similar results. Looking at the code for pdfbook, as well as the other tools that Jeff's made available, I don't see why they can't be run across unallocated space or the pagefile, for that matter. Another thought might be to give the code the ability to do an EnCase-like preview of X number of bytes on either side of the 'hit' that's been located.
While you're conducting IR or memory analysis activities, Didier's done it again and given us all something new to worry about with SelectMyParent! SMP is a proof-of-concept tool to demonstrate that with the right privileges, you can create a process and designate a parent process for that process. So, instead of running Notepad or Solitaire with your privileges, as a child process of Explorer.exe, you can run it as a child of lsass.exe. And yes, I know what you're thinking...so what? Who's really going to use something like this? Perhaps malware authors...
Print Matter
As a side note from Jeff's post, DFM has it's inaugural issue available...this may be something worth taking a look at. I'd like to see how it compares to Into The Boxes...hopefully, there will be more of a supporting role than competitive.
Along those lines, my second article on timeline analysis is now available in Hakin9 magazine. This one is a hands-on walk-through for using the tools I discuss (and make available via the Win4n6 Yahoo group...go to the Files section) to create a timeline for forensic analysis. I mentioned at an ECTF meeting recently that I have used this technique to great effectiveness. In one instance during a PCI forensic assessment, I was able to narrow down the window of exposure by demonstrating that shortly after the malware was first installed on the system, AV detected and deleted it. In that instance, sources of information included not only the file system metadata and Event Log records, but also AV logs and even information derived from Dr. Watson logs...combining these allowed us to demonstrate that while the malware had been installed, it did not appear to be running at certain times (this malware was not a DLL injected into another process). The two big take-aways from the articles should be that (a) timeline analysis allows you to view events from a system (or several systems) in temporal proximity to each other, and (b) when additional analysis support is required, you can ship off the necessary information for a timeline to another analyst without worrying about exposing sensitive data.
You can also download free Hakin9 articles here.
Correction
I was taken to task by an anonymous poster recently regarding what I've described as a 128-bit timestamp. Apparently, this isn't a timestamp, but rather a SYSTEMTIME structure. I had searched for this, and even been asked by someone from Microsoft about it, but neither of us was able to find a link. So, thanks to Anonymous for sharing this. Apparently, I also stand corrected on how prevalent this structure is within the various versions of Windows, although that's still something of a mystery.
Media
Bret and Ovie have a new CyberSpeak podcast posted...check it out.
I received an email recently that let me know that the latest version of RevealerToolkit is available, a project from a Barcelona security company. The RVT framework is based on Brian Carrier's TSK tools, and even makes use of some of my code to parse EVT files. More information on RVT is available here. Also, be sure to take a look at the user guide, as well.
Remember when I got p0wned by Intel and MS? Thanks to a blog comment, I was pointed to VMLite, which provides an alternative to MS's XPMode, and without the requirement for hardware virtualization in the CPU. This may definitely be something to take a look at, as virtualization can play pretty important role in forensic analysis in a number of ways. Take a look at packages such as MojoPac and Moka-5, for example.
Rob Lee pointed the GCFA mailing list to RE-Google the other day...this is apparently (quoted) a plugin for the Interactive DisAssembler (IDA) Pro that queries Google Code for information about the functions contained in a disassembled binary. Wow, that sounds pretty cool!
Lance has posted another EnScript, this one to locate Limewire download remnants. This may be pertinent if you're looking at a case involving Limewire or just P2P in general.
Speaking of Lance, I've used the images he has made available for his practicals as examples on a number of occasions; these are excellent resources. However, if you want to work with these practicals as raw dd images (rather than .E0x format), you'll need to convert them using something like FTK Imager. But if you want to mount the EWF/EOx format images and access the files within them, you can use mount_ewf, which Chris has talked about. To do this on Windows, you need to follow these steps (from David Loveall, which Rob Lee so graciously provided to the Win4n6 Yahoo group):
1. Extract the mount_ewf files for Windows into a directory
2. Download and install the Visual Studio runtime files, if you don't already have them
3. Download and install ImDisk
At this point, you should just be able to double-click the E01 file, and tell it Open With... mount_ewf.exe. I'll have to say that I haven't tested this as of yet, but if you've got E0x files you'd like to access, but don't want to have to give up additional space in converting it to raw dd format, this may be an option. P2 Explorer (free) and SmartMount (not free) will also allow you to mount EWF/E0x format images.
Memory Collection and Analysis
An engineer at HBGary recently posted a review of Matthieu's windd tool, based on testing against their own FDPro tool. It's an interesting read...take a look. Here's Matthieu's response, along with some personal notes. I think it's good to see, read, and digest both sides of an issue, and this is definitely worth taking a look at.
On the analysis end of things, Jeff Bryner posted about his FaceBook Memory Forensics tool (ie, pdfbook) on the SANS Forensics Blog recently. Jeff's posted about other tools for parsing memory dumps, and I'm sure that you could use the output of the tool you're using (as opposed to pd.exe, as he mentions in the blog post) to obtain similar results. Looking at the code for pdfbook, as well as the other tools that Jeff's made available, I don't see why they can't be run across unallocated space or the pagefile, for that matter. Another thought might be to give the code the ability to do an EnCase-like preview of X number of bytes on either side of the 'hit' that's been located.
While you're conducting IR or memory analysis activities, Didier's done it again and given us all something new to worry about with SelectMyParent! SMP is a proof-of-concept tool to demonstrate that with the right privileges, you can create a process and designate a parent process for that process. So, instead of running Notepad or Solitaire with your privileges, as a child process of Explorer.exe, you can run it as a child of lsass.exe. And yes, I know what you're thinking...so what? Who's really going to use something like this? Perhaps malware authors...
Print Matter
As a side note from Jeff's post, DFM has it's inaugural issue available...this may be something worth taking a look at. I'd like to see how it compares to Into The Boxes...hopefully, there will be more of a supporting role than competitive.
Along those lines, my second article on timeline analysis is now available in Hakin9 magazine. This one is a hands-on walk-through for using the tools I discuss (and make available via the Win4n6 Yahoo group...go to the Files section) to create a timeline for forensic analysis. I mentioned at an ECTF meeting recently that I have used this technique to great effectiveness. In one instance during a PCI forensic assessment, I was able to narrow down the window of exposure by demonstrating that shortly after the malware was first installed on the system, AV detected and deleted it. In that instance, sources of information included not only the file system metadata and Event Log records, but also AV logs and even information derived from Dr. Watson logs...combining these allowed us to demonstrate that while the malware had been installed, it did not appear to be running at certain times (this malware was not a DLL injected into another process). The two big take-aways from the articles should be that (a) timeline analysis allows you to view events from a system (or several systems) in temporal proximity to each other, and (b) when additional analysis support is required, you can ship off the necessary information for a timeline to another analyst without worrying about exposing sensitive data.
You can also download free Hakin9 articles here.
Correction
I was taken to task by an anonymous poster recently regarding what I've described as a 128-bit timestamp. Apparently, this isn't a timestamp, but rather a SYSTEMTIME structure. I had searched for this, and even been asked by someone from Microsoft about it, but neither of us was able to find a link. So, thanks to Anonymous for sharing this. Apparently, I also stand corrected on how prevalent this structure is within the various versions of Windows, although that's still something of a mystery.
Media
Bret and Ovie have a new CyberSpeak podcast posted...check it out.
Wednesday, November 18, 2009
Working with Volume Shadow Copies
To begin with, let me say right up front that most of the information in this post, particularly the latter half, is not something that I developed myself...consider this more of me being a secretary(albeit unpaid) for Rob Lee, Troy Larson, and apparently Jimmy Weg...apparently, these guys all knew about what I'm going to present here well before I started down this road.
That being said, away we go...
Based on something I saw in Troy Larson's presentation at DCC2009 regarding Volume Shadow Copies, I thought I'd try something...I wanted to see if I could mount an image of a Vista system from a Vista system, and access the Volume Shadow Copies within the image.
I started with a Vista Home Edition system and an image of that same system on a USB external HDD. I connected the USB external HDD to the live Vista system and mounted the acquired image with each of several tools. I used ImDisk, SmartMount v1.0.5, the 14 day trial copy of Mount Image Pro, and P2 Explorer.
In each instance I mounted the image as a drive letter, verified that I could access the volume, and ran vssadmin list shadows. In none of the instances did vssadmin recognize the mounted drive as a source of Volume Shadow Copies. Well, I take that back...I didn't even get that far with P2 Explorer...it automatically kicked off its MD5 hashing, and once that was done, reported that the image was corrupt.
Now, Troy had mentioned in his testing that only EnCase PDE will mount an image in a manner through which vssadmin can access Volume Shadow Copies within the image. Okay, well, that's not something I have available at this point.
Now, Troy, Jimmy, and Rob mentioned something in one of the lists recently that seemed interesting...basically, to summarize what was said...if you have a VMWare guest of Vista, for example, and you have an acquired raw/dd image of a Vista system, you can generate at .vmdk file for the image and add it to the Vista VM as a hard drive, and then you can 'see' the Volume Shadow Copies in the acquired image.
So I set out to see if this was something I could replicate. I used ProDiscover to create a .vmdk file for the acquired image (again...Vista Home OS), and I opened VMWare Workstation 6.5. I went to the settings for my Vista Ultimate VM and added the new .vmdk file to the properties for the VM as a hard drive. When I booted the Vista VM and logged in, I could see the acquired image right here as E:\. So far, so good.
I then ran vssadmin, like so:
C:\>vssadmin list shadows /for=e:
Lo and behold, I saw a list of Volume Shadow Copies for the E:\ drive! And yes, the entries for "Originating Machine" corresponded to the name of the system from which the image had been acquired.
The next step was to see if I could create symbolic links using mklink...the short version is that I could, but I could not access them, as I kept getting "The parameter is incorrect" messages. Suffice to say, I even created symbolic links for Volume Shadow Copies from the C:\ drive, and got the same message. It turns out that the issue with mklink is that the trailing \ is absolutely required (something that was also mentioned on the SANS blog). So the command looks like:
C:\>mklink /d C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy18\
With this, you can then run tools such as RegRipper against the hive files, or copy out selected files for analysis (or better yet, just run your tools to collect the information), etc. Once you're done, you can remove the symbolic link with:
C:\>rd C:\shadow
Before I go on, let me remind you...you MUST have a \ at the end of the Volume Shadow Copy in the mklink command.
Moving on, I downloaded George M. Garner, Jr.'s FAU tools and ran the following command:
C:\tools>dd if=\\.\HarddiskVolumeShadowCopy6 of=g:\shadow6.dd --localwrt
HarddiskVolumeShadowCopy6 is one of the identified Volume Shadow Copies from the E:\ drive. I wanted to acquire an image of the Volume Shadow Copy to an attached USB external drive (G:\), hence the use of the --localwrt switch. For about 10 min, I let the command run, and kept running "dir g:\" from another command prompt, and kept seeing that shadow6.dd was 0 bytes. I stopped the imaging (Ctrl-C) and found that the output file was over 2.5GB! So I then re-ran the command, and just let it run...and it will run for a while, as I'm acquiring from a USB ext HDD to a USB ext HDD.
Here's the results of the 'dd' command:
C:\tools>dd if=\\.\HarddiskVolumeShadowCopy6 of=g:\shadow6_2.dd --localwrt
Copying \\.\HarddiskVolumeShadowCopy6 to g:\shadow6_2.dd
Output: g:\shadow6_2.dd
146526953472 bytes
139738+1 records in
139738+1 records out
146526953472 bytes written
Succeeded!
Now that the acquisition is complete, the next step is to verify the acquired image. Opening the image in FTK Imager, I was able to verify that I had a complete, readable file system. At this point, I can do everything with this image that I would with any other acquired image.
Again, let me remind you that this isn't something I came up with...apparently, others have known about this, I'm just writing it down.
Summary
1. Start with a raw/dd image of Vista or above
2. Create a .vmdk file for the image
3. Add the .vmdk as a hard drive to a VM of a like OS (if image is Vista, use a Vista VM)
4. Boot the VM, use vssadmin to locate VSC's on the image drive (or use WMI to get concise info)
5a. Use mklink to 'mount' the VSC's you're interested in, or...
5b. Acquire the full VSC using dd
Resources
Troy's Vista Forensics Slides (one version, anyway)
Shadow Copies on Wikipedia
Shadow Copy Client
Win32_ShadowCopy WMI Class
That being said, away we go...
Based on something I saw in Troy Larson's presentation at DCC2009 regarding Volume Shadow Copies, I thought I'd try something...I wanted to see if I could mount an image of a Vista system from a Vista system, and access the Volume Shadow Copies within the image.
I started with a Vista Home Edition system and an image of that same system on a USB external HDD. I connected the USB external HDD to the live Vista system and mounted the acquired image with each of several tools. I used ImDisk, SmartMount v1.0.5, the 14 day trial copy of Mount Image Pro, and P2 Explorer.
In each instance I mounted the image as a drive letter, verified that I could access the volume, and ran vssadmin list shadows. In none of the instances did vssadmin recognize the mounted drive as a source of Volume Shadow Copies. Well, I take that back...I didn't even get that far with P2 Explorer...it automatically kicked off its MD5 hashing, and once that was done, reported that the image was corrupt.
Now, Troy had mentioned in his testing that only EnCase PDE will mount an image in a manner through which vssadmin can access Volume Shadow Copies within the image. Okay, well, that's not something I have available at this point.
Now, Troy, Jimmy, and Rob mentioned something in one of the lists recently that seemed interesting...basically, to summarize what was said...if you have a VMWare guest of Vista, for example, and you have an acquired raw/dd image of a Vista system, you can generate at .vmdk file for the image and add it to the Vista VM as a hard drive, and then you can 'see' the Volume Shadow Copies in the acquired image.
So I set out to see if this was something I could replicate. I used ProDiscover to create a .vmdk file for the acquired image (again...Vista Home OS), and I opened VMWare Workstation 6.5. I went to the settings for my Vista Ultimate VM and added the new .vmdk file to the properties for the VM as a hard drive. When I booted the Vista VM and logged in, I could see the acquired image right here as E:\. So far, so good.
I then ran vssadmin, like so:
C:\>vssadmin list shadows /for=e:
Lo and behold, I saw a list of Volume Shadow Copies for the E:\ drive! And yes, the entries for "Originating Machine" corresponded to the name of the system from which the image had been acquired.
The next step was to see if I could create symbolic links using mklink...the short version is that I could, but I could not access them, as I kept getting "The parameter is incorrect" messages. Suffice to say, I even created symbolic links for Volume Shadow Copies from the C:\ drive, and got the same message. It turns out that the issue with mklink is that the trailing \ is absolutely required (something that was also mentioned on the SANS blog). So the command looks like:
C:\>mklink /d C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy18\
With this, you can then run tools such as RegRipper against the hive files, or copy out selected files for analysis (or better yet, just run your tools to collect the information), etc. Once you're done, you can remove the symbolic link with:
C:\>rd C:\shadow
Before I go on, let me remind you...you MUST have a \ at the end of the Volume Shadow Copy in the mklink command.
Moving on, I downloaded George M. Garner, Jr.'s FAU tools and ran the following command:
C:\tools>dd if=\\.\HarddiskVolumeShadowCopy6 of=g:\shadow6.dd --localwrt
HarddiskVolumeShadowCopy6 is one of the identified Volume Shadow Copies from the E:\ drive. I wanted to acquire an image of the Volume Shadow Copy to an attached USB external drive (G:\), hence the use of the --localwrt switch. For about 10 min, I let the command run, and kept running "dir g:\" from another command prompt, and kept seeing that shadow6.dd was 0 bytes. I stopped the imaging (Ctrl-C) and found that the output file was over 2.5GB! So I then re-ran the command, and just let it run...and it will run for a while, as I'm acquiring from a USB ext HDD to a USB ext HDD.
Here's the results of the 'dd' command:
C:\tools>dd if=\\.\HarddiskVolumeShadowCopy6 of=g:\shadow6_2.dd --localwrt
Copying \\.\HarddiskVolumeShadowCopy6 to g:\shadow6_2.dd
Output: g:\shadow6_2.dd
146526953472 bytes
139738+1 records in
139738+1 records out
146526953472 bytes written
Succeeded!
Now that the acquisition is complete, the next step is to verify the acquired image. Opening the image in FTK Imager, I was able to verify that I had a complete, readable file system. At this point, I can do everything with this image that I would with any other acquired image.
Again, let me remind you that this isn't something I came up with...apparently, others have known about this, I'm just writing it down.
Summary
1. Start with a raw/dd image of Vista or above
2. Create a .vmdk file for the image
3. Add the .vmdk as a hard drive to a VM of a like OS (if image is Vista, use a Vista VM)
4. Boot the VM, use vssadmin to locate VSC's on the image drive (or use WMI to get concise info)
5a. Use mklink to 'mount' the VSC's you're interested in, or...
5b. Acquire the full VSC using dd
Resources
Troy's Vista Forensics Slides (one version, anyway)
Shadow Copies on Wikipedia
Shadow Copy Client
Win32_ShadowCopy WMI Class
Saturday, November 14, 2009
It's about time...
Sometimes you need a tool, and you just don't have one available to do the thing you need done.Recently, I was doing some analysis, and as part of that was running regslack to see what I could find in the unallocated space of some Registry hive files. Within the hex dump of unallocated space, I could see what appeared to be Registry keys (signature "nk"), but these were in the unallocated space dumps, not as part of deleted keys that had been extracted by Jolanta's regslack tool. I could also see, right there in my editor, what appeared to be a FILETIME date/time stamp. So I had a string that comprised the date/time stamp, but no way to translate it quickly.
So I wrote a tool.
I called this tool Decode64, as I wanted to decode the 64-bit FILETIME objects...but from the starting point of a binary value, the way RegRipper does it. No, I needed to be able to start with a string. So I wrote Decode64 to take a string representing the date/time stamp (analyst pastes it into a textfield...how easy is that??) and with the push of a button, translate that to both a Unix epoch time, as well as to a human-readable time, in GMT format.
Now, if you look closely at the graphic with this post, you'll see that the string entered into the first field is not indicative of a 64-bit timestamp...nope, it's one of those 128-bit timestamps that MS uses (i.e., in the Scheduled Task .job file format, and in various Registry values beginning with Vista). Consider that an Easter egg. ;-) So, I'll be using this to not only determine if something falls within my incident timeframe, but to also enter information into a timeline via the TLN tool that I wrote, and included with the timeline tools in the Win4n6 group.
Speaking of time, when I talk to folks about analyzing images for indications of malware infections, I will usually start with asking what AV product was installed. What most folks don't realize is that many Windows systems will have the MS Malicious Software Removal Tool (MRT) installed, and that the MRT maintains a log of activity, to include anything it finds and removes during a scan. I thought, cool...I can include that information in a timeline, IF I can parse it out. Now I can. ;-)
C:\tools>mrtparse.pl -f mrt.log -s YoUrMoM
1257686548|MRT|YoUrMoM|| - Backdoor:Win32/Rbot in file://C:\WINDOWS\system32\ss ms.exe (sigseq 0x000016677E6E8F8A)
1257686548|MRT|YoUrMoM|| - Win32/Rbot and Removed!
As you can see, mrtparse.pl is a pretty simple script. Right now what it does is parse through the mrt.log file looking for any segment of the log file that contains a return code between 6 and 13 (all I've see so far is 0 and 6). Once it finds such a segment, it parses out what was found. Pretty simple.
I only have a couple of log files for testing, so the functionality of the script is limited at this point. Also, I don't have anything definitive that describes the format that the time is maintained in (i.e., local system time or GMT). So there is definitely area for improvement, but those are both easy fixes, as well.
Some other thoughts I had were to include all return codes of "0", as well. My thought that it would be a good idea if you could see something like a malware file being added to the system, and the results of tools such as MRT and AV right in there, as well.
NOTE: Keep in mind that MRT is NOT an AV solution (...and you're going to ask me, "...but what is?", aren't you??) - it's more akin to a microscanner (similar to Stinger) in that it only protects against a very specific list of malware.
A possible next step would be to look at adding support for Windows Defender logs...
Resources
A note on Defender settings
Default Scheduled Tasks in Vista
Defender not working and IE homepage set to "about:blank"?
AV recommendations for Windows (links to log files)
Friday, November 13, 2009
Some Analysis Coolness
TimeLine AnalysisThe most recent issue of Hakin9 is available now...my second article on timeline creation and analysis is in this one; it's a hands-on walk-through of using the tools I put together, and use on a regular basis. You know...eat your own dogfood, as it were.
What do I like so much about this analysis method? Well, it's fast, it's relatively easy, and it lets an analyst (i.e., me) see a bunch of stuff all together in one place. It's pretty cool to see things like a remote login, creation of the PSExecSvc service, see that service start, then see a bunch of other files being created...to include the data files created by the malware.
Another thing I like about timeline creation and analysis is this...let's say you've got an analyst (or a team) on-site working an engagement, and they're stuck with something; determining the avenue of infection or compromise...whatever. Now let's assume that it's an engagement involving sensitive data, and they're trying to scope everything AND do collections. You can have those analysts dump the file system metadata, extract selected files from the system or image, zip all of that up and send it to someone for analysis. Not only do you run your analysis in parallel...you're not sending that sensitive data out! That's right, folks...you can increase your response efficiency and effectiveness using off-site staff, without further exposing sensitive data!
The version of the tools used in the article are available for download from the Win4n6 Yahoo group. The tools are all separate, standalone tools for right now because, to be honest, I don't always use them all together. Sometimes, it's good to see activity in a different format...in others, it's good to see a limited subset of activity (say, just your Event Log records) all at once, before moving on. By having separate tools, the analyst can intelligently select what they want added to the timeline in order to build it out.
What do I like so much about this analysis method? Well, it's fast, it's relatively easy, and it lets an analyst (i.e., me) see a bunch of stuff all together in one place. It's pretty cool to see things like a remote login, creation of the PSExecSvc service, see that service start, then see a bunch of other files being created...to include the data files created by the malware.
Another thing I like about timeline creation and analysis is this...let's say you've got an analyst (or a team) on-site working an engagement, and they're stuck with something; determining the avenue of infection or compromise...whatever. Now let's assume that it's an engagement involving sensitive data, and they're trying to scope everything AND do collections. You can have those analysts dump the file system metadata, extract selected files from the system or image, zip all of that up and send it to someone for analysis. Not only do you run your analysis in parallel...you're not sending that sensitive data out! That's right, folks...you can increase your response efficiency and effectiveness using off-site staff, without further exposing sensitive data!
The version of the tools used in the article are available for download from the Win4n6 Yahoo group. The tools are all separate, standalone tools for right now because, to be honest, I don't always use them all together. Sometimes, it's good to see activity in a different format...in others, it's good to see a limited subset of activity (say, just your Event Log records) all at once, before moving on. By having separate tools, the analyst can intelligently select what they want added to the timeline in order to build it out.
File and Document Metadata
When I used to present at LE-oriented conferences more often, I'd talk about a nifty little tool out there called MergeStreams. This is a great little tool that essentially allows you to "hide" an Excel spreadsheet inside a Word document. This only applies to pre-Office 2007 document formats, however. I'll say that again...it only works on versions of MSOffice that use the OLE compound document format. What I'd show is someone pasting pictures (re: illicit images) into a Word document and then merging those with an Excel spreadsheet. Name the file "myspreadsheet.xls" and you would see the Excel spreadsheet. Rename the file, giving it a .doc extension, and you'd see the Word document.
While we're talking about Office document metadata, now is a good time to revisit some tools for extracting metadata; for pre-Office 2007 documents that use the OLE structured storage format, I've used the tools from my book, oledmp.pl and wmd.pl quite effectively, and there's OffVis from MS; for Office 2007 documents, try cat_open_xml.pl.
While we're talking about Office document metadata, now is a good time to revisit some tools for extracting metadata; for pre-Office 2007 documents that use the OLE structured storage format, I've used the tools from my book, oledmp.pl and wmd.pl quite effectively, and there's OffVis from MS; for Office 2007 documents, try cat_open_xml.pl.
Speaking of files, have you seen this new plugin from Bit9 called FileAdvisor? It's apparently a shell plugin for Windows, so if you find a suspicious file on your system, you can right-click it, and hash it and submit it for analysis. To view results, you'll need to register at the site with your name, email address, and a password. I don't necessarily see this on every user's desktop, but I do see responders and analysts possibly having it installed on a system somewhere.
Memory Parsing/Analysis
Jeff Bryner has put together a Python script for extracting FaceBook artifacts from a memory dump called pdfbook. For Windows systems, the script parses memory dumps from pd...I wonder if you could do the same thing using a full memory dump, extracting just the memory used by the process? Jeff has also released yim2text, a Python script for extracting Yahoo chat artifacts. Very cool.
Wednesday, November 11, 2009
In The News
The Register is reporting that bot masters have hidden a control channel in the Google cloud via AppEngine. Interesting article, take a read. The article also points out that both Facebook and Twitter accounts have been seen being leveraged as control mechanisms. Quoted from the article:
I'd suggest that that would have to do with the implementation. Cloud is being sold as the next big thing...but what is it? Well, it depends on who you're talking to.
Something else that's been making its rounds is spilled COFEE...Dark Reading picked it up, as well. Folks, the only reason this is getting the press it is, is because this was originally released only to law enforcement. Other than that, it's really not that big of a deal. Hogfly weighed in on this, as well...he apparently felt so strongly about this...dude, his last post was in August! ;-)
FTK 3 has "explicit image detection" capabilities (PDF here). This looks to be very useful for finding images, but I'm not sure that that's really the issue at hand these days...I may be wrong. I mean, I thought that it wasn't so much a matter for LE to find the images (although the coolness factor might be that in the video, Erika Lee uses the term "trained", implying a neural network of some kind...), but it was more a matter of addressing the Trojan Defense. I mean, once you find the images, you have to then demonstrate that the user in question intentionally downloaded and viewed them, and possibly shared them. This is were browser/web history, P2P, and Registry analysis come into play. Know anyone who knows anything about "Registry analysis"?
Speaking of which...
I ran across this AP article regarding the "Trojan Defense" hosted at the Fox News site. This is an interesting article to me, because this is something I've been discussing with LE for a number of years now. One of the key aspects of the analysis performed can be seen here:
A technician found child porn in the PC folder that stores images viewed online.
For most examiners, this refers to the browser cache; for IE, the Temporary Internet Files subfolders. Now, I'm not about to disparage any analysts skills or capabilities...all I'm going to do is point some things out. First, those TIF subfolders aren't created by IE, they're created by the use of the WinInet APIs, which IE uses. Now, this means that another app that uses the same APIs would also create the subfolders, and if it were running in the context of the logged on user, the folders would be created in the user's TIF directory.
Where did I get this? Well, I got a little help from my buddy Robert "Van" Hensing...check out his blog post from 2006. This was valuable to me, as I had conducted an exam for a customer, and one of the oddities I found was that the Default User's web history (I was using ProDiscover in my examination, and there's an extremely useful function to search for and parse web history...) had been populated. I tracked that back to a copy of wget.exe running with privileges elevated to System level...but I digress.
So, it's entirely possible to get just about anything on a system and make it look like the user did it. Why do that? Perhaps to discredit the user or law enforcement...I don't know, I'm not this guy.
My point is that we can't simply look at the folder the files are located in and their date/time stamps, and think we've got it wrapped up. There are a number of other places on the system that we can look...Prefetch folder, Registry, etc...in order to answer the question of did a Trojan do it? before it's asked.
And that may be another reason why black hats are flocking to the cloud.
"Going to a company as big as Google and saying 'Can we get an image of that server,' that's a pretty high barrier," he said.I'd suggest that that would have to do with the implementation. Cloud is being sold as the next big thing...but what is it? Well, it depends on who you're talking to.
Something else that's been making its rounds is spilled COFEE...Dark Reading picked it up, as well. Folks, the only reason this is getting the press it is, is because this was originally released only to law enforcement. Other than that, it's really not that big of a deal. Hogfly weighed in on this, as well...he apparently felt so strongly about this...dude, his last post was in August! ;-)
FTK 3 has "explicit image detection" capabilities (PDF here). This looks to be very useful for finding images, but I'm not sure that that's really the issue at hand these days...I may be wrong. I mean, I thought that it wasn't so much a matter for LE to find the images (although the coolness factor might be that in the video, Erika Lee uses the term "trained", implying a neural network of some kind...), but it was more a matter of addressing the Trojan Defense. I mean, once you find the images, you have to then demonstrate that the user in question intentionally downloaded and viewed them, and possibly shared them. This is were browser/web history, P2P, and Registry analysis come into play. Know anyone who knows anything about "Registry analysis"?
Speaking of which...
I ran across this AP article regarding the "Trojan Defense" hosted at the Fox News site. This is an interesting article to me, because this is something I've been discussing with LE for a number of years now. One of the key aspects of the analysis performed can be seen here:
A technician found child porn in the PC folder that stores images viewed online.
For most examiners, this refers to the browser cache; for IE, the Temporary Internet Files subfolders. Now, I'm not about to disparage any analysts skills or capabilities...all I'm going to do is point some things out. First, those TIF subfolders aren't created by IE, they're created by the use of the WinInet APIs, which IE uses. Now, this means that another app that uses the same APIs would also create the subfolders, and if it were running in the context of the logged on user, the folders would be created in the user's TIF directory.
Where did I get this? Well, I got a little help from my buddy Robert "Van" Hensing...check out his blog post from 2006. This was valuable to me, as I had conducted an exam for a customer, and one of the oddities I found was that the Default User's web history (I was using ProDiscover in my examination, and there's an extremely useful function to search for and parse web history...) had been populated. I tracked that back to a copy of wget.exe running with privileges elevated to System level...but I digress.
So, it's entirely possible to get just about anything on a system and make it look like the user did it. Why do that? Perhaps to discredit the user or law enforcement...I don't know, I'm not this guy.
My point is that we can't simply look at the folder the files are located in and their date/time stamps, and think we've got it wrapped up. There are a number of other places on the system that we can look...Prefetch folder, Registry, etc...in order to answer the question of did a Trojan do it? before it's asked.
Happy Birthday, VMI!
I know, another off-topic blog post, but this should the last one for a while!The Virginia Military Institute was established on 11 Nov 1839, having originally been an armory manned by unruly troops. The armory was turned into a school, with the idea of having the students/cadets (or "keydets") guard the armory. The daily changing of the guard existed while I was there, and exists today.
Something old is shed and something new is added with each era. VMI started as a single barrack, and when I was there, I lived all four years in "New Barracks". This passed April, while visiting during my 20th reunion, I got a look into the "third barracks", which stands on the spot where LeJeune Hall, the cadet canteen, stood while I was there.
I did note that the cannon balls were still present in the wall of Old Barracks nearest Mallory Hall. To see other changes, check out Brother Rat, filmed in 1938, and starring Ronald Reagan...it was filmed, in part, on post at VMI.
VMI has a great tradition and a number of notable alumni; Chesty Puller attended, as did Patton. Dabney Coleman attended VMI. Perhaps VMI's most notable graduate is George C. Marshall, 1901, who went on to become the Chief of Staff of the Army (5-star general), Secretary of Defense, and Secretary of State. He is also a recipient of the Nobel Peace Prize, and the "Marshall Plan" for the restoration of Europe after WWII is named for him.
Happy Birthday, VMI, and Happy Birthday, Brother Rats!
Tuesday, November 10, 2009
Happy Birthday, Marines!
This is usually a technical blog, but I wanted to take a moment to recognize the service and sacrifice of all current and former Marines on what is the 234th Birthday of the Corps.
For 234 years, Marines have served just like is says in the Marine's Hymn, exemplified by the motto, Semper Fidelis (Always Faithful).
In my short service in the Corps, I celebrated this date on land, in foreign lands, and even at sea. I was even the commander of the cake detail once (not nearly as ominous as it sounds). I've also seen some pretty humorous things happen during the ceremony...like the time four 2ndLts from TBS comprised the cake detail... 4 2ndLts + 1 Cake + 1 ramp to the stage = a true Benny Hill moment!
That being said, today is a day to thank any and all Marines you know...and by "thank", hug or buy 'em a beer...or both.
Semper Fi!
For 234 years, Marines have served just like is says in the Marine's Hymn, exemplified by the motto, Semper Fidelis (Always Faithful).
In my short service in the Corps, I celebrated this date on land, in foreign lands, and even at sea. I was even the commander of the cake detail once (not nearly as ominous as it sounds). I've also seen some pretty humorous things happen during the ceremony...like the time four 2ndLts from TBS comprised the cake detail... 4 2ndLts + 1 Cake + 1 ramp to the stage = a true Benny Hill moment!
That being said, today is a day to thank any and all Marines you know...and by "thank", hug or buy 'em a beer...or both.
Semper Fi!
Monday, November 09, 2009
p0wnage
A little over a month ago, I purchased a Dell Inspiron 1545 from the Dell Refurbished shelf. Most of the systems I've purchased from Dell have been procured through this route, and I've been pretty happy with the systems.Until now. Tonight, I was p0wned by MS.
See, I'd purchased the laptop to do Windows 7 forensic (and in particular Registry) research. You know, use it like a user would and then see what the system "looks like" from a forensic perspective. Do what a user would do, then do like a forensic nerd would do.
Well, it seems that the laptop I purchased is running an Intel T4200 processor. It has 410 Million transistors, but does not support hardware virtualization.
Okay, my thought was that I was going to get an almost-brand-spanking-new system...no way it wouldn't support hardware virtualization. Well, it doesn't. What this means is that this laptop doesn't support XP Mode. Wow, so much for that rather critical portion of research.
So, the lesson learned here is, don't assume that the latest and greatest box, even one birthed in the past year, is going to have the necessary functionality to support what you want to do. In fact, as far as XP Mode is concerned, if that system you've got your eye on has an Intel processor, assume that it doesn't until proven otherwise. Wonder where I got that? My favorite forensics tool, Cory Altheide, found this at the Parallels site...notice what it says at the bottom of the page about AMD microprocessors.
Addendum: It seems that while the laptop I just purchased does not have a processor that supports hardware virtualization, the Dell Latitude D820 that I purchased in 2006 DOES! All I need to do is enable it in the BIOS...
More Linky Goodness, plus
I attended one day of the NetWitness User Conference last week, and ran into Richard Bejtlich there. Richard posted some of his thoughts on the keynote address that day. Hey, can you pick out in the picture which one is Richard? ;-)
As a side note, I'll be presenting at the WFO-ECTF meeting later this month, on Registry and timeline analysis.
Check out Claus's blog post on spilled COFEE. Claus also has an very good post full of links to useful tools...I know this is kind of circular, me linking to Claus's set of links (in this post by Claus, they come back to this blog...), but Claus's set is comprehensive enough, why bother retyping all that? Claus has always had some excellent links to portable apps, particularly AV tools that can make IR a bit easier, and in his most recent blog points out some remote desktop tools that IT admins may find useful, as well as Wireshark for Windows 7!
Brett and Ovie have got a couple of new CyberSpeak podcasts up...the 7 Nov podcast not only has a news story where a system infected with a keystroke logger led to the conviction of the suspect, but there's also an interview with Matt Shannon of F-Response.
Speaking of Matt, you have GOT to check out his latest press release about TACTICAL and the CyberSpeak podcast! Regarding TACTICAL, this is what Matt has about it on his site:
F-Response TACTICAL is the newest F-Response software product. TACTICAL has been uniquely designed to streamline live analysis, collection, and authentication. TACTICAL is built around the best of the F-Response Field Kit and Consultant edition, it was designed from the bottom up to be easier to use, faster, smaller, and more efficient.
TACTICAL uses a unique dual dongle/storage device solution that allows an investigator to bring their favorite tools to bear on Windows, Apple, and Linux targets.
This sounds very cool! Check out Matt's excellent CyberSpeak interview for more information! I cannot wait to see TACTICAL in action...
The 1 Nov CyberSpeak podcast has an interesting discussion on data breach notification...check it out.
Hey, anyone remember Clippy? If you do, check out the version of Clippy for VIM...
I ran into an interesting issue recently that I thought I'd bring up here. I've been doing some analysis, and as part of that analysis, I've been using regslack to get deleted keys and unallocated space from Registry hive files. When I find a deleted key, there's a LastWrite time associated with it, but sometimes I see Registry keys in the unallocated space of the hive files. What this means is that the key found in unallocated space no longer meets the conditions for or definition of a "deleted key" (more on that later). However, in the hex found in unallocated space, I can clearly see the FILETIME data for the key's LastWrite time, and that's something I might like to translate into something usable. So let's say I see the FILETIME data:
be 31 72 dc d4 94 c9 01
Using Perl, I can run that through a conversion routine and get something a bit more usable:
Sun Feb 22 10:03:50 2009
Pretty simple. Pretty cool.
Speaking of FILETIME objects, its a brave new forensics world, folks! Windows Registry keys have FILETIME LastWrite times, and some values contain FILETIME "objects" within their binary data. Others contain *nix epoch (32-bit) timestamps. Still others contain 128-bit representations of date/time stamps - this format is also found in Scheduled Task .job files. I was parsing some Symantec AV logs recently, and it turns out that they have their own format for date/time stamps! Interesting stuff...and there's SO much more!
As a side note, I'll be presenting at the WFO-ECTF meeting later this month, on Registry and timeline analysis.
Check out Claus's blog post on spilled COFEE. Claus also has an very good post full of links to useful tools...I know this is kind of circular, me linking to Claus's set of links (in this post by Claus, they come back to this blog...), but Claus's set is comprehensive enough, why bother retyping all that? Claus has always had some excellent links to portable apps, particularly AV tools that can make IR a bit easier, and in his most recent blog points out some remote desktop tools that IT admins may find useful, as well as Wireshark for Windows 7!
Brett and Ovie have got a couple of new CyberSpeak podcasts up...the 7 Nov podcast not only has a news story where a system infected with a keystroke logger led to the conviction of the suspect, but there's also an interview with Matt Shannon of F-Response.
Speaking of Matt, you have GOT to check out his latest press release about TACTICAL and the CyberSpeak podcast! Regarding TACTICAL, this is what Matt has about it on his site:
F-Response TACTICAL is the newest F-Response software product. TACTICAL has been uniquely designed to streamline live analysis, collection, and authentication. TACTICAL is built around the best of the F-Response Field Kit and Consultant edition, it was designed from the bottom up to be easier to use, faster, smaller, and more efficient.
TACTICAL uses a unique dual dongle/storage device solution that allows an investigator to bring their favorite tools to bear on Windows, Apple, and Linux targets.
This sounds very cool! Check out Matt's excellent CyberSpeak interview for more information! I cannot wait to see TACTICAL in action...
The 1 Nov CyberSpeak podcast has an interesting discussion on data breach notification...check it out.
Hey, anyone remember Clippy? If you do, check out the version of Clippy for VIM...
I ran into an interesting issue recently that I thought I'd bring up here. I've been doing some analysis, and as part of that analysis, I've been using regslack to get deleted keys and unallocated space from Registry hive files. When I find a deleted key, there's a LastWrite time associated with it, but sometimes I see Registry keys in the unallocated space of the hive files. What this means is that the key found in unallocated space no longer meets the conditions for or definition of a "deleted key" (more on that later). However, in the hex found in unallocated space, I can clearly see the FILETIME data for the key's LastWrite time, and that's something I might like to translate into something usable. So let's say I see the FILETIME data:
be 31 72 dc d4 94 c9 01
Using Perl, I can run that through a conversion routine and get something a bit more usable:
Sun Feb 22 10:03:50 2009
Pretty simple. Pretty cool.
Speaking of FILETIME objects, its a brave new forensics world, folks! Windows Registry keys have FILETIME LastWrite times, and some values contain FILETIME "objects" within their binary data. Others contain *nix epoch (32-bit) timestamps. Still others contain 128-bit representations of date/time stamps - this format is also found in Scheduled Task .job files. I was parsing some Symantec AV logs recently, and it turns out that they have their own format for date/time stamps! Interesting stuff...and there's SO much more!
Wednesday, November 04, 2009
Link-alicious
Thanks to Rob Lee's tweets, I read about AccessData's new Registry Summary Reports recently. These seem like baby RegRipper plugins...not quite there yet. I contacted some marketing guys from AD and they said that Registry Viewer has had this capability for years...I never knew about it when I was using FTK v1.71 or 1.8 (and I was too busy pulling my hair out just trying to install v2.0!!)...guess I just missed it.
ImagineLan has an SRP Explorer utility that looks quite interesting, allowing you do to do diffs of Registry hives across Restore Points. Interesting.
From the MMPC, a post regarding the MSRT October release, with a case study.
Rifiuti, the tool from FoundStone for parsing Recycle Bin INFO2 files, has a version available for Vista Recycle Bins called rifiuti2. This is actually a rewrite of the original code, according to the Google Code page. And yes, there is a version available for Windows.
Anyone caught the most recent edition of Captain Forensics??
Addendum: Chris Novak had an excellent (albeit short) article published on the Fundamental Failures With IR Plans...essentially, not having/testing one. Chris makes an excellent point...although war stories are sexy (re: fascinating) and writing is boring, the fact is, you have to have an IR plan. I was talking to someone recently about a company that stores CVV data, and does their own PCI self-assessment...and passes. I bet they also check "yes" when they get to the PCI DSS requirement 12.9...
I found some interesting stuff on Ophacki recently, starting with this analysis from Joe Stewart, and then moving on to the ISC write-up. Folks, if nothing else, this sort of thing demonstrates the lengths malware authors can and will go to in order to keep their stuff on systems. This bit of malware is a link hijacker, which essentially means that it's relatively harmless...however, more and more customers are asking folks like me (and the malware experts I work with) to determine if the malware has the capability to steal data, and if so, what did it take. First, this ties in to the IR plan article...if you have no plan and do nothing but shut the system off (i.e., capture no volatile or network traffic data), my ability to help you answer those questions is limited. Your IT staff are closest to the incident...it may take me 24-48 hrs to get there, depending on flights (and contract negotiations). If you have a plan and trained response staff, you can at least collect the data...
Second, if you haven't hugged your malware analyst today, do it now. I mean, seriously...look at how complex Ophacki is...it reportedly hides in memory by destroying the PE header. It doesn't decrypt the strings it needs in memory until it needs them, and then it deletes them when it's done. It also deletes the SafeBoot key, and reportedly hooks the APIs to delete Registry keys so that you can't delete the keys it uses for persistence. It also removes Zeus.
In short, there is a lot of sophistication for a simple link hijacker...which tells me that there's some kind of economy at work here...someone REALLY wants to make money!! What if the intent were different? What if the author really wanted to steal data? What if the malware was used to determine the type of system it was on...if a home user's system, look for indications of web-based purchases (or just sniff the keyboard), look for tax returns, and then turn the system into a zombie.
My point is that malware is getting more and more sophisticated, and malware authors are responding not only to standard business practices (i.e., Conficker spread via network shares) but also to some of the response procedures - some malware does not write to disk, but instead remains persistent in memory because the systems are rarely rebooted. Some folks recommend simply nuking the box from orbit...clean and reinstall...but malware authors know that the box will likely be put right back in place with the same holes and vulnerabilities, because that part of the re-installation plan is very often missed or skipped, because there is no IR plan.
ImagineLan has an SRP Explorer utility that looks quite interesting, allowing you do to do diffs of Registry hives across Restore Points. Interesting.
From the MMPC, a post regarding the MSRT October release, with a case study.
Rifiuti, the tool from FoundStone for parsing Recycle Bin INFO2 files, has a version available for Vista Recycle Bins called rifiuti2. This is actually a rewrite of the original code, according to the Google Code page. And yes, there is a version available for Windows.
Anyone caught the most recent edition of Captain Forensics??
Addendum: Chris Novak had an excellent (albeit short) article published on the Fundamental Failures With IR Plans...essentially, not having/testing one. Chris makes an excellent point...although war stories are sexy (re: fascinating) and writing is boring, the fact is, you have to have an IR plan. I was talking to someone recently about a company that stores CVV data, and does their own PCI self-assessment...and passes. I bet they also check "yes" when they get to the PCI DSS requirement 12.9...
I found some interesting stuff on Ophacki recently, starting with this analysis from Joe Stewart, and then moving on to the ISC write-up. Folks, if nothing else, this sort of thing demonstrates the lengths malware authors can and will go to in order to keep their stuff on systems. This bit of malware is a link hijacker, which essentially means that it's relatively harmless...however, more and more customers are asking folks like me (and the malware experts I work with) to determine if the malware has the capability to steal data, and if so, what did it take. First, this ties in to the IR plan article...if you have no plan and do nothing but shut the system off (i.e., capture no volatile or network traffic data), my ability to help you answer those questions is limited. Your IT staff are closest to the incident...it may take me 24-48 hrs to get there, depending on flights (and contract negotiations). If you have a plan and trained response staff, you can at least collect the data...
Second, if you haven't hugged your malware analyst today, do it now. I mean, seriously...look at how complex Ophacki is...it reportedly hides in memory by destroying the PE header. It doesn't decrypt the strings it needs in memory until it needs them, and then it deletes them when it's done. It also deletes the SafeBoot key, and reportedly hooks the APIs to delete Registry keys so that you can't delete the keys it uses for persistence. It also removes Zeus.
In short, there is a lot of sophistication for a simple link hijacker...which tells me that there's some kind of economy at work here...someone REALLY wants to make money!! What if the intent were different? What if the author really wanted to steal data? What if the malware was used to determine the type of system it was on...if a home user's system, look for indications of web-based purchases (or just sniff the keyboard), look for tax returns, and then turn the system into a zombie.
My point is that malware is getting more and more sophisticated, and malware authors are responding not only to standard business practices (i.e., Conficker spread via network shares) but also to some of the response procedures - some malware does not write to disk, but instead remains persistent in memory because the systems are rarely rebooted. Some folks recommend simply nuking the box from orbit...clean and reinstall...but malware authors know that the box will likely be put right back in place with the same holes and vulnerabilities, because that part of the re-installation plan is very often missed or skipped, because there is no IR plan.
Tuesday, November 03, 2009
The Future of RegRipper
You may have been wondering why, over the past months, I've been mentioning various plugins (or you may not, I don't know...), but they don't seem to be being released. Well, that's because, in part, that I don't really have a means for doing so other than uploading them to RegRipper.net (again, many, many thanks to Brett for that), and also, I've been working on updating RegRipper to something much more than what it is now.
As an example, I have a test script for the new version of RegRipper working...working fairly well, actually. Here's an example of the output:
C:\Perl\forensics\rr3>test.pl d:\cases\xp\config
Software d:\cases\xp\config\Software
Sam d:\cases\xp\config\Sam
Security d:\cases\xp\config\Security
System d:\cases\xp\config\System
ProductName = Microsoft Windows XP
CSDVersion = Service Pack 1
CurrrentVersion = 5.1
S-1-5-21-1220945662-884357618-682003330-1004
%SystemDrive%\Documents and Settings\Caster Troy
So, I provided the example output so that you could see what's happening, but there are still some things that are happening under the hood. In this example, I've pointed the test script to a directory where I have the Registry hives (SAM, Security, Software, and System) extracted from a sample image (one of Lance Mueller's practicals)...so the script locates the files with the right names, and then checks to see of they're the right type of hive file - that's the first list in the output. Then the script accesses the Software hive file (because now we know that it's a Software hive file) and extracts information about the OS, as well as about user profiles that the Registry knows about.
So know we have a pretty good opportunity for a great deal of automation, don't we? So, I can mount an acquired image via SmartMount, ImDisk, or P2 Explorer (or my app of choice), or access a remote drive via F-Response, or mount a Volume Shadow Copy, and then just point RR at the system32/config directory. Point and shoot...very cool. Now the application has a good deal of information on which to make decisions and choices to control program flow...such as, if the system isn't Windows 2000 or XP, is there any sense in running the ACMru plugin against the user hives? Or, if the system is XP, I may want to run one plugin to get wireless SSIDs, but if the system is Vista or above, I may want to run another plugin.
So, you're looking at the future of RegRipper...well, you're not so much as I am! ;-) For those of you who've already seen the power of RegRipper, and for those of you who've said that using RegRipper reduced what used to take you days into minutes, there's a lot to look forward to!
Speaking of plugins, I wrote another one tonight...svcdll.pl. This one runs through the Services subkeys in the ControlSet marked "Current", and locates all services with a ServiceDll value...many times, these are services run via SvcHost. This is also used by some malware variants...they'll create a service with a random name, and the ServiceDll value will point to a similarly oddly-named DLL. Svcdll.pl gives you a quick look for such things, providing a modicum of malware detection, and hey...it can be run against live systems if you're using F-Response!
As an example, I have a test script for the new version of RegRipper working...working fairly well, actually. Here's an example of the output:
C:\Perl\forensics\rr3>test.pl d:\cases\xp\config
Software d:\cases\xp\config\Software
Sam d:\cases\xp\config\Sam
Security d:\cases\xp\config\Security
System d:\cases\xp\config\System
ProductName = Microsoft Windows XP
CSDVersion = Service Pack 1
CurrrentVersion = 5.1
S-1-5-21-1220945662-884357618-682003330-1004
%SystemDrive%\Documents and Settings\Caster Troy
So, I provided the example output so that you could see what's happening, but there are still some things that are happening under the hood. In this example, I've pointed the test script to a directory where I have the Registry hives (SAM, Security, Software, and System) extracted from a sample image (one of Lance Mueller's practicals)...so the script locates the files with the right names, and then checks to see of they're the right type of hive file - that's the first list in the output. Then the script accesses the Software hive file (because now we know that it's a Software hive file) and extracts information about the OS, as well as about user profiles that the Registry knows about.
So know we have a pretty good opportunity for a great deal of automation, don't we? So, I can mount an acquired image via SmartMount, ImDisk, or P2 Explorer (or my app of choice), or access a remote drive via F-Response, or mount a Volume Shadow Copy, and then just point RR at the system32/config directory. Point and shoot...very cool. Now the application has a good deal of information on which to make decisions and choices to control program flow...such as, if the system isn't Windows 2000 or XP, is there any sense in running the ACMru plugin against the user hives? Or, if the system is XP, I may want to run one plugin to get wireless SSIDs, but if the system is Vista or above, I may want to run another plugin.
So, you're looking at the future of RegRipper...well, you're not so much as I am! ;-) For those of you who've already seen the power of RegRipper, and for those of you who've said that using RegRipper reduced what used to take you days into minutes, there's a lot to look forward to!
Speaking of plugins, I wrote another one tonight...svcdll.pl. This one runs through the Services subkeys in the ControlSet marked "Current", and locates all services with a ServiceDll value...many times, these are services run via SvcHost. This is also used by some malware variants...they'll create a service with a random name, and the ServiceDll value will point to a similarly oddly-named DLL. Svcdll.pl gives you a quick look for such things, providing a modicum of malware detection, and hey...it can be run against live systems if you're using F-Response!
Monday, November 02, 2009
Into The Boxes
Into The Boxes is a new e-mag (first issue due out in Jan, 2010) covering issues concerning the Digital Forensics and Incident Response (DF/IR) community. The purpose of this e-mag is NOT to replace or compete with any of the other information resources within this community; in fact, it’s an attempt to augment what’s already out there, by providing additional resources in an easy-to-read and easy-to-manage format.
Sound cool? Check out the Welcome Message. If you'd like to contribute, check out the Collaboration Box. Comments and suggestions can be sent using the Call Box. Complaints and whining will be piped to /dev/null. ;-)
Sound cool? Check out the Welcome Message. If you'd like to contribute, check out the Collaboration Box. Comments and suggestions can be sent using the Call Box. Complaints and whining will be piped to /dev/null. ;-)
Subscribe to:
Posts (Atom)