Every now and then, I'll post (to this blog or to an online forum) on the topic of sharing and collaboration within the community, and how it benefits those who are actively involved. Actively engaging with others in the field has worked out very well for me in a number of circumstances, both during casework and research, and I seek out that kind of active engagement and recommend it to others.
Here are some examples of how active engagement has been a benefit:
I was working on a malware detection case a while back, and by actively engaging with our malware analysis guy, we were able to provide much more information and intelligence to the customer than either one of us working separately...the final result was much greater than the sum of it's parts. I provided information to the malware analyst regarding where the malware was found, artifacts associated with it, how it was likely launched, etc. He was able to successfully launch the malware on a similar platform, and then provide information and intel from memory analysis that was then used to further extend the host-based analysis. Working together in this manner, we were able to collect much more information in a timely manner, which allowed us to extend that information into intelligence by collecting and incorporating information from external sources. The final turn-around on all of this was 4 1/2 days, where the customer would have been happy with (and was more used to) 6 months.
Last January, when returning from a conference, a friend mentioned to me that he had an NT 4.0 system (yes, that's exactly right...NT 4.0) to examine, and the Event Logs had apparently been cleared. I was able to offer him a solution, allowing him to recover Event Log records from unallocated space, and progress and extend his analysis.
Okay, so continuing on...not long ago, the folks at Mandiant posted regarding the AppCompatCache Registry value (which is where the "0xbadc0fee" reference in the post title comes from...), and provided example code. This was a great bit of sharing with the community, and I was able to not only find and correct an issue with the tools I was using, but also create a RegRipper plugin based on the information and code they provided. From there, I started looking at other locations within the Registry that could provide indications of program execution, and created plugins for these, as well.
Then when I updated the Prefetch file parsing code in preparation for some upcoming training courses, I added some 'filters' to the code, so that certain artifacts (modules with "temp" in their path, etc.) were extracted and highlighted.
I was exchanging code and emails with Corey Harrell, engaging in discussions with him with respect to the usefulness of both the code and analysis techniques, and he suggested adding similar filtering capability to some of the already available RegRipper plugins (MUICache, UserAssist, etc.)...something I'd considered, but it hadn't occurred to me how useful that might be. Thanks to engaging with Corey on this, he made it clear to me that not only would these filters be valuable, but he also suggested some additional filters that would be useful in other areas, as well. In short, the idea was to take the breadth of both of our experiences and put that into filters that would illustrate to other analysts, "look, here's a bunch of data, but here are some things you might consider looking at sooner rather than later...".
It was that active sharing and collaboration that not only served to extend our own individual knowledge through the exchange of our experiences, but also allowed us to extend the tools themselves. Clearly, this would then have a cyclic effect...running the updated tools would likely show us artifacts that we might have missed, extending our knowledge and experience, which we could then use to extend the tools, etc.
One of the things I really appreciate about engaging with Corey is that he puts a great deal of thought into things. We're all busy, and I don't expect immediate responses from anyone, but I can always count on Corey to come back with something thoughtful, such as, "why would you want to do that?", or "how about if we did it this way?" It's this kind of thoughtfulness when engaging that allows all parties involved to grow and develop. Sometimes, when you're used to doing something a certain way, or if you're really actively engaged on something, a simple question like, "why?" can really provide a great deal of value.
If you haven't done so already, I highly recommend that you vote for Corey or his blog in the 2012 Forensic4Cast awards. Particularly in the last year, Corey has contributed a great deal to the community as a whole, and it would really being doing him justice if he were to win at least one of the awards that he's nominated for. Also, he'll be at the SANS Forensic Summit in Austin this year, so be sure to buy him a beer, regardless.
You'll notice that throughout this post, I kept using the term "active" or "actively". I did this to make a distinction; downloading code or tools that someone
provides is not actively engaging.
Showing posts with label sharing. Show all posts
Showing posts with label sharing. Show all posts
Friday, May 18, 2012
Saturday, April 21, 2012
Tools, Updates...
Tools
Didier has released an updated version of an older viewer that he'd written, called InteractiveSieve. Based on the description of the viewer, this looks like an excellent tool for performing timeline analysis.
Here's what I would do...may times, I will want to look at a particular date range, so I would run the parse.pl script to extract just that date range from my events file. I would then open the resulting mini-timeline in Didier's viewer and go about deleting those things that I didn't want to see, and colorize things that might be important, or interesting but not specifically relevant without further investigation.
AppCompatCache
The folks over at Mandiant posted to the M-unition blog regarding the Application Compatibility Cache, which is maintained in the Registry (see their paper). They've released a free tool to view this data, and in less than 30 minutes, I wrote up a RegRipper plugin to parse this data. The first test data that I had available was 32-bit XP, so it's limited, but it's a start, and I think that it really shows the power of open source. I don't say this to take anything away from the efforts of the Mandiant folks...rather, I thank them for their willingness to share the results of their research with the community at large. I provided a copy of the plugin to the SANSForensics team, and gave them permission to post the code via the SANS Case Leads. Rob contacted me with the test results, which weren't good. It appears that the module I use has an issue, which I describe below in the "Troubleshooting" section.
Now, how is this information useful? Check out Mandiant's paper...this particular data source is very rich in data, and I'll be updating the plugins once I get the module "fixed".
Open Source
I had posted to the Win4n6 Yahoo group some thoughts I had on the power of open source tools, with respect to the information Mandiant released. The purpose of the post was not to say, "hey, look at me...I wrote another plugin!!", but rather to demonstrate the power and flexibility of open source tools, and how they can be quickly be extended to provide a capability that might take days or weeks for commercial applications. Andrew provided another example, one that involved extending Volatility during Stuxnet analysis. As someone who's done DFIR work for a long time, I really appreciate having the ability to decide what analysis I will do, rather than being penned in by a commercial tool or framework.
Troubleshooting
Okay, back to the information Mandiant provided regarding the Registry value...one of the members of the Win4n6 group (Ben) sent me a Windows 7 System hive...I have several, which I had opened in MiTeC's WRR and found the value in question to be all zeros...yet Mandiant's free tool pulled a great deal of data from the hive. I checked again, and sure enough, the value in both ControlSets was all zeros. So, based on a suggestion from Ben, I tried Yaru from TZWorks, and found all of the data. I also wrote up a quick Perl script to extract the data from the value and place it into a file; from there, I opened up the file in a hex editor and could easily view the data. It turns out that the issue is that Yaru is apparently the only tool of those I looked at that correctly handles 'db' node types within the Registry. I have attempted to contact the author of the Parse::Win32Registry module about this, in hopes that it's an easy fix.
Registry Unallocated Space
Another interesting aspect of TZWorks' Yaru is that when you load the hive, it indexes the contents of the hive...and finds deleted keys. Pretty cool!
I wanted to see how that compared to regslack, so I ran regslack against the same hive and got a bit different information; I got the same deleted key that Yaru found, plus one other, and I also got a LOT of unallocated space! The web page for Yaru says that finding deleted keys is an experimental capability, which is great...it's also great that someone else is working on this topic. Yolanta's work and release of regslack were a significant milestone for Registry analysis (here is one of my first blog posts on the topic).
The description of Yaru also states that you can view "cell slack", or unused "key value data space"...that's something else that might be very interesting to look into, although I'm not completely clear on what value there may be in data included in cell slack.
A while back, while I was involved in PCI forensic assessments, I used our documented process once I was back in the lab, and my scan for CCNs with an acquired image turned up hits within the Software and NTUSER.DAT hives on a system. I thought that was odd...looking at the data surrounding the hits, it wasn't 100% clear to me that these were actual CCNs; that is, there were no indications that this was track data. So I exported the hives and ran searches across the "live" Registry...and got nothing. It turned out that the CCNs were part of unallocated space within the hive files...so understanding that there is unallocated space within a hive file can mean the difference between saying, "CCNs were found in the Registry", and actually providing accurate information in your report (as it can affect your customer).
Malware Persistence
The MMPC site has a description of Trojan:Win32/Reveton.A,which provides a good deal of information about this bit of ransomware. Apparently, this baddie locks the infected system and displays a warning to the user that they've been reported to authorities as possessing illicit material.
Okay, so what is the persistence mechanism? This one creates a Windows shortcut (LNK file) for itself in the Windows Startup folder. Since the malware arrives as a DLL, it uses rundll32.exe to launch itself via the shortcut.
So what this gives us is some very good info to add to our malware detection checklist, doesn't it? Not only should we check the Startup folders shortcuts (easy check; can accomplish this with a simple 'dir' command), but we might want to get some additional information via Prefetch analysis, particular of Prefetch files that start with "rundll32.exe".
"Community"
There's a new post up over on the Hexacorn blog, and comments are turned off, so I can't comment there...so let's do it here. ;-) Overall, let me say that I find most of the posts here interesting, and this one is no exception, but in this case, I'm only interested in four words from the post:
Like many before me...
I think that what a lot of us loose sight of is the fact that with few exceptions, there's probably someone out there who has faced the same challenges we've seen, and had to deal with the same...or at least very similar issues, as we have. So, when faced with these challenges, we have options...we can seek help, or (if we're racing the clock to get stuff done) we can try to muddle through things and figure things out for ourselves. I've heard people say this...that they want to wrestle with the issue and try to figure things out for themselves...even though there are others willing to help, or material and documentation available. This is very noble, but think about it...is there any wonder why we don't see anything from them about what they learned later? It's probably because they spent so much time wrestling that they don't have much time for anything else.
Recently, Girl, Unallocated gave an excellent DFIROnline presentation that involved a spoliation case and CCleaner. Now, I've had an opportunity recently to work with the latest version of this tool...not in a forensic analysis capacity...so I'm a little familiar with it. However, not long ago, I dealt with a case that involved an older version of WindowWasher. So this shows that in a lot of ways, there are very few "new" cases; that is to say, it's likely that technology aside (XP vs. Win7, for example), there are very few, "This is what I need to determine..." cases.
Need to recover Event Log records (or MFT records) from unallocated space on an XP workstation or Win2003 server? Perform USB device analysis? Determine if that malware on the system actually executed? I'm sure that someone else has run into this before...probably many "somebodys".
So, what to do? Well, we can start by recognizing that if we have a road block, there's a way around it that someone else may already have found. Ask for assistance. It's also helpful that (a) the response not be taken "off list", and (b) that when the dust has settled, there's some final feedback or closure.
Remember, no one of us is as smart as all of us together.
To close this out, I recently had an event that made the issue of "community" clear to me. Back in 2009, I'd written a script to parse Windows XP Scheduled Task/.job files (pull out the command run, the last time the job was run, and the status), and I have it is part of my personal stash of timeline tools. In recent weeks, I had two different people ask me for a copy of the script, which I was somewhat hesitant to do because of my past experience with doing this sort of thing. I decided to give the first person a chance and sent them the script. I was notified that they received it, but getting feedback on how well it worked was like pulling hen's teeth. So the second person came along, and I was just gonna say, "No, thanks" to their request...but they had a compelling need. And they ran into an issue with the script...during testing, I'd never encountered a .job file that had been created but never run. Now, I simply don't have any of those types of files available...but I asked Corey for some help, and thankfully, he was able to provide a couple of files. All in all, the script is working very well, and providing not just some useful output, but it will also provide that output in TLN format. Thanks to Corey providing some sample files, that meant I didn't need to go find an XP install disk, set up a VM, etc., etc., and was able to provide a solution much sooner.
Didier has released an updated version of an older viewer that he'd written, called InteractiveSieve. Based on the description of the viewer, this looks like an excellent tool for performing timeline analysis.
Here's what I would do...may times, I will want to look at a particular date range, so I would run the parse.pl script to extract just that date range from my events file. I would then open the resulting mini-timeline in Didier's viewer and go about deleting those things that I didn't want to see, and colorize things that might be important, or interesting but not specifically relevant without further investigation.
AppCompatCache
The folks over at Mandiant posted to the M-unition blog regarding the Application Compatibility Cache, which is maintained in the Registry (see their paper). They've released a free tool to view this data, and in less than 30 minutes, I wrote up a RegRipper plugin to parse this data. The first test data that I had available was 32-bit XP, so it's limited, but it's a start, and I think that it really shows the power of open source. I don't say this to take anything away from the efforts of the Mandiant folks...rather, I thank them for their willingness to share the results of their research with the community at large. I provided a copy of the plugin to the SANSForensics team, and gave them permission to post the code via the SANS Case Leads. Rob contacted me with the test results, which weren't good. It appears that the module I use has an issue, which I describe below in the "Troubleshooting" section.
Now, how is this information useful? Check out Mandiant's paper...this particular data source is very rich in data, and I'll be updating the plugins once I get the module "fixed".
Open Source
I had posted to the Win4n6 Yahoo group some thoughts I had on the power of open source tools, with respect to the information Mandiant released. The purpose of the post was not to say, "hey, look at me...I wrote another plugin!!", but rather to demonstrate the power and flexibility of open source tools, and how they can be quickly be extended to provide a capability that might take days or weeks for commercial applications. Andrew provided another example, one that involved extending Volatility during Stuxnet analysis. As someone who's done DFIR work for a long time, I really appreciate having the ability to decide what analysis I will do, rather than being penned in by a commercial tool or framework.
Troubleshooting
Okay, back to the information Mandiant provided regarding the Registry value...one of the members of the Win4n6 group (Ben) sent me a Windows 7 System hive...I have several, which I had opened in MiTeC's WRR and found the value in question to be all zeros...yet Mandiant's free tool pulled a great deal of data from the hive. I checked again, and sure enough, the value in both ControlSets was all zeros. So, based on a suggestion from Ben, I tried Yaru from TZWorks, and found all of the data. I also wrote up a quick Perl script to extract the data from the value and place it into a file; from there, I opened up the file in a hex editor and could easily view the data. It turns out that the issue is that Yaru is apparently the only tool of those I looked at that correctly handles 'db' node types within the Registry. I have attempted to contact the author of the Parse::Win32Registry module about this, in hopes that it's an easy fix.
Registry Unallocated Space
I wanted to see how that compared to regslack, so I ran regslack against the same hive and got a bit different information; I got the same deleted key that Yaru found, plus one other, and I also got a LOT of unallocated space! The web page for Yaru says that finding deleted keys is an experimental capability, which is great...it's also great that someone else is working on this topic. Yolanta's work and release of regslack were a significant milestone for Registry analysis (here is one of my first blog posts on the topic).
The description of Yaru also states that you can view "cell slack", or unused "key value data space"...that's something else that might be very interesting to look into, although I'm not completely clear on what value there may be in data included in cell slack.
A while back, while I was involved in PCI forensic assessments, I used our documented process once I was back in the lab, and my scan for CCNs with an acquired image turned up hits within the Software and NTUSER.DAT hives on a system. I thought that was odd...looking at the data surrounding the hits, it wasn't 100% clear to me that these were actual CCNs; that is, there were no indications that this was track data. So I exported the hives and ran searches across the "live" Registry...and got nothing. It turned out that the CCNs were part of unallocated space within the hive files...so understanding that there is unallocated space within a hive file can mean the difference between saying, "CCNs were found in the Registry", and actually providing accurate information in your report (as it can affect your customer).
Malware Persistence
The MMPC site has a description of Trojan:Win32/Reveton.A,which provides a good deal of information about this bit of ransomware. Apparently, this baddie locks the infected system and displays a warning to the user that they've been reported to authorities as possessing illicit material.
Okay, so what is the persistence mechanism? This one creates a Windows shortcut (LNK file) for itself in the Windows Startup folder. Since the malware arrives as a DLL, it uses rundll32.exe to launch itself via the shortcut.
So what this gives us is some very good info to add to our malware detection checklist, doesn't it? Not only should we check the Startup folders shortcuts (easy check; can accomplish this with a simple 'dir' command), but we might want to get some additional information via Prefetch analysis, particular of Prefetch files that start with "rundll32.exe".
"Community"
There's a new post up over on the Hexacorn blog, and comments are turned off, so I can't comment there...so let's do it here. ;-) Overall, let me say that I find most of the posts here interesting, and this one is no exception, but in this case, I'm only interested in four words from the post:
Like many before me...
I think that what a lot of us loose sight of is the fact that with few exceptions, there's probably someone out there who has faced the same challenges we've seen, and had to deal with the same...or at least very similar issues, as we have. So, when faced with these challenges, we have options...we can seek help, or (if we're racing the clock to get stuff done) we can try to muddle through things and figure things out for ourselves. I've heard people say this...that they want to wrestle with the issue and try to figure things out for themselves...even though there are others willing to help, or material and documentation available. This is very noble, but think about it...is there any wonder why we don't see anything from them about what they learned later? It's probably because they spent so much time wrestling that they don't have much time for anything else.
Recently, Girl, Unallocated gave an excellent DFIROnline presentation that involved a spoliation case and CCleaner. Now, I've had an opportunity recently to work with the latest version of this tool...not in a forensic analysis capacity...so I'm a little familiar with it. However, not long ago, I dealt with a case that involved an older version of WindowWasher. So this shows that in a lot of ways, there are very few "new" cases; that is to say, it's likely that technology aside (XP vs. Win7, for example), there are very few, "This is what I need to determine..." cases.
Need to recover Event Log records (or MFT records) from unallocated space on an XP workstation or Win2003 server? Perform USB device analysis? Determine if that malware on the system actually executed? I'm sure that someone else has run into this before...probably many "somebodys".
So, what to do? Well, we can start by recognizing that if we have a road block, there's a way around it that someone else may already have found. Ask for assistance. It's also helpful that (a) the response not be taken "off list", and (b) that when the dust has settled, there's some final feedback or closure.
Remember, no one of us is as smart as all of us together.
To close this out, I recently had an event that made the issue of "community" clear to me. Back in 2009, I'd written a script to parse Windows XP Scheduled Task/.job files (pull out the command run, the last time the job was run, and the status), and I have it is part of my personal stash of timeline tools. In recent weeks, I had two different people ask me for a copy of the script, which I was somewhat hesitant to do because of my past experience with doing this sort of thing. I decided to give the first person a chance and sent them the script. I was notified that they received it, but getting feedback on how well it worked was like pulling hen's teeth. So the second person came along, and I was just gonna say, "No, thanks" to their request...but they had a compelling need. And they ran into an issue with the script...during testing, I'd never encountered a .job file that had been created but never run. Now, I simply don't have any of those types of files available...but I asked Corey for some help, and thankfully, he was able to provide a couple of files. All in all, the script is working very well, and providing not just some useful output, but it will also provide that output in TLN format. Thanks to Corey providing some sample files, that meant I didn't need to go find an XP install disk, set up a VM, etc., etc., and was able to provide a solution much sooner.
Tuesday, February 28, 2012
More Win
A good friend of mine reached out to me last week, in order to ask for my assistance with something. They had an issue that they were working on, and it turned out that Facebook chat artifacts played an important role in that issue. Fortunately, I had taken a personal day, and had some time to devote to this interesting issue; interesting because I'd never had to parse FB chat messages before.
So, armed with a description of what my friend was looking at, and what they wanted to see with respect to the output, I started coding. I know that Facebook chat messages are saved in JSON format, which is easily parsed via Perl. I did have a little bit of an issue parsing the time stamp associated with the chat messages, and I reached to Andrew Case, who provided me with some valuable insight. Apparently, the chat time stamps are in Unix epoch format, with milliseconds. The resulting 10.3 floating point format (ten digits followed by a decimal and three more digits) is multiplied by 1000 to get a 13 digit string. As such, the conversion of the time stamp into something readable was pretty straightforward, and Andrew was able to provide some valuable information and resources.
I had an initial script working pretty quickly, and got that script out the door to my friend in just over an hour...I then cleaned up the code a bit, added some comments and documentation, and had a cleaner version sent off about 90 minutes after I started writing code. The script (fb.pl) is posted here.
The script was run against over 1400 Facebook chat messages that had been exported via EnCase. The script accessed each file, with each file containing one chat message, and parsed out the pertinent data into CSV format. The results were available in minutes...or more accurately, "about a minute". How long would it have taken to do this by hand? More importantly, how boring would that have been, and how much else could you have accomplished instead of doing all of that by hand?
So how is this useful? Well, for me, I had an opportunity to work on something interesting, that helped someone else out. I didn't have to view all of the data...nor did I want to, to be honest. I just saw enough to allow me to write code that would parse the data. And I have a neat little piece of code that I can reuse in the future.
My friend got to work on something else while I was writing the code, and then once they had the code, got what could have been hours of tedious, boring work that they'd've had to have done by hand done in "about a minute". And they have code that they can reuse when similar issues pop up in the future.
Lessons
If you're faced with something that's a lot of a tedious, manual work, it's likely to be boring and result in mistakes...so automate it if you can. Computers are really good at doing stuff...particularly boring, repetitive stuff...really fast. People aren't. Oh, and the code can be reused later.
If you don't know how to automate something, or if it would take you a while to figure it out, try reaching out to another analyst. You'd be surprised at what some folks have already done, or what they're willing to do.
Get more done faster...by asking for assistance, you can offload something; in this case, that 'something' was developing an automated approach to processing large (potentially massive) amounts of data. Getting someone's help means that you can often focus on something else while they work on that problem.
Banging your head against the wall on a problem, or "chewing on it" in an attempt to force that problem into submission is a really good way to waste a lot of time. Sure, you get the joy of knowing you accomplished something yourself, but what's the likelihood that another analyst, perhaps even one you know, has already gone down that road, or something close to it? Or, maybe has an idea that help you get from point A to point B faster? After all, what do you have to loose?
Hopefully what this means is that at some point in the near future, my friend and I will be able sit down and share a moment over a nice micro-brew.
By the way, in case you were wondering...the image I included in this blog post has absolutely nothing to do with anything...I just thought it was funny! ;-)
I had an initial script working pretty quickly, and got that script out the door to my friend in just over an hour...I then cleaned up the code a bit, added some comments and documentation, and had a cleaner version sent off about 90 minutes after I started writing code. The script (fb.pl) is posted here.
The script was run against over 1400 Facebook chat messages that had been exported via EnCase. The script accessed each file, with each file containing one chat message, and parsed out the pertinent data into CSV format. The results were available in minutes...or more accurately, "about a minute". How long would it have taken to do this by hand? More importantly, how boring would that have been, and how much else could you have accomplished instead of doing all of that by hand?
So how is this useful? Well, for me, I had an opportunity to work on something interesting, that helped someone else out. I didn't have to view all of the data...nor did I want to, to be honest. I just saw enough to allow me to write code that would parse the data. And I have a neat little piece of code that I can reuse in the future.
My friend got to work on something else while I was writing the code, and then once they had the code, got what could have been hours of tedious, boring work that they'd've had to have done by hand done in "about a minute". And they have code that they can reuse when similar issues pop up in the future.
Lessons
If you're faced with something that's a lot of a tedious, manual work, it's likely to be boring and result in mistakes...so automate it if you can. Computers are really good at doing stuff...particularly boring, repetitive stuff...really fast. People aren't. Oh, and the code can be reused later.
If you don't know how to automate something, or if it would take you a while to figure it out, try reaching out to another analyst. You'd be surprised at what some folks have already done, or what they're willing to do.
Get more done faster...by asking for assistance, you can offload something; in this case, that 'something' was developing an automated approach to processing large (potentially massive) amounts of data. Getting someone's help means that you can often focus on something else while they work on that problem.
Banging your head against the wall on a problem, or "chewing on it" in an attempt to force that problem into submission is a really good way to waste a lot of time. Sure, you get the joy of knowing you accomplished something yourself, but what's the likelihood that another analyst, perhaps even one you know, has already gone down that road, or something close to it? Or, maybe has an idea that help you get from point A to point B faster? After all, what do you have to loose?
Hopefully what this means is that at some point in the near future, my friend and I will be able sit down and share a moment over a nice micro-brew.
By the way, in case you were wondering...the image I included in this blog post has absolutely nothing to do with anything...I just thought it was funny! ;-)
Thursday, February 23, 2012
A Little Something More Regarding IOCs...
I recently posted a little something on IOCs, and I wanted to take a moment to extend that, along the vein of what I was discussing, particularly the part where I said, "Engage with those with adjacent skill sets". I think that this is a particularly important undertaking, particularly when we're talking about IOCs, because we can get better, more valuable IOCs when we engage with those with adjacent skill sets, and understand what their needs are. This true for responders, DF analysts, malware analysts, and we can even include pen testers, as well.
First, a word on specialization. Many of us in the infosec world recognize the need and importance of understanding a general body of knowledge, but at the same time, many of us also gravitate toward a particular specialization, such as digital forensic analysis of mobile devices or Windows systems, web app assessments/pen testing, etc. Very often, we find this specialization to be extremely beneficial to us, not only in what we do, but in our careers, and often our hobbies, as well. What happens when we try to do too much...say, IR, DF, and pen testing? Well, we really don't become an expert at anything in particular, do we? Several years ago, I sat on a panel at the SANS Forensic Summit, and the question was asked about who you'd want to show up to respond to an incident...my answer was someone who responded to incidents, not someone who was doing a pen test last week, and pulling cable the week before that. Think about it...who do you want doing your brain surgery? A trained, experienced neurosurgeon, or someone who, up until 6 months ago, was driving trucks? My point is that due to how complex systems have become, who can really be an expert in everything?
Okay, so to tie that together, while it's good to specialize in something, it's also a really good idea to engage with those with other, ancillary, adjacent specializations. For example, as a digital forensic analyst, I've had some really outstanding successes when I've worked closely with an expert malware analyst (you know who you are, Sean!!). By working together with the malware analyst, and providing what they need to do their job better (i.e., context, specific information such as paths, etc.), and getting detailed information back from them, we were able to develop a great deal more (and more valuable) information for our customer, in less time, than if we'd each worked separately on the case, and even more so than if we'd worked solo, without the benefit of the other's skills.
Part of that success had to do with sharing IOCs between us. Well, we started by sharing the specific indicators associated with what was found...I had not found the indication of the infection until running the fourth AV scanner (a relatively obscure free AV scanner named 'a-squared'). From there, I referred to my timeline, and was able to determine why there seemed to be no Registry-based auto-start mechanisms for the malware. From there, I provided the information I had available to the malware analyst, including information about the target platform, where the malware was found, a copy of the malware itself, etc. After disabling WFP on his the analysis system, the malware guy got the infected files up and running, and pulled information out of memory that I was then able to use to further my analysis within the acquired image (i.e., domain name, etc.). Using this information, I targeted specific artifacts...for example, the malware analysts shared that once the malware DLL was in memory, it was no longer obfuscated, so he was able to parse out the PE headers of the file, including the import table. As the malware DLL imported functions from the WinInet API, it was reasonable to assume (and was verified through analysis) that the malware DLL itself was capable of off-system communications. This made it clear not only that additional malware was not required, but also told us exactly where we should be looking for artifacts. As such, in my analysis of the acquired image, I focused on the IE history for the user in question and the pagefile. I ran strings across the pagefile, looking for indications of the domain name we had, and then wrote a Perl script that would go into the pagefile at that offset for each hit of interest, and grab 100 bytes on either side of the hit. What we ended up getting was several web server responses to the malware's HTTP off-system communications, which included time stamps from the web server, as well as server directives telling the client to not cache anything.
Now, each of us focusing on our specialized areas of analysis, but treating each other like "customers", worked extremely well. We each had a wealth of information available to us and worked closely to determine was the other needed, and what was most valuable.
Addendum: While driving home from work in traffic today, I thought of something that might reveal a bit more about this exchange...
At the early stage of my analysis, I had an acquired image from a system, from which I'd created a timeline, and against which I had run four AV scans. The result of the last scan was where one file was identified as "malicious". Looking at that file within in the image, via FTK Imager, I could see that the file was obfuscated (by the contents of the import table), although I didn't know how it was obfuscated (packed, encrypted, both, etc.). And I only had the acquired image...I didn't have a memory dump. So before I sent it to the malware guy, I had to figure out how this thing was launched...after all, I couldn't just send him the file and ask him, "what can you tell me about this file?", because his answer would be "not much", or not much that I couldn't already figure out for myself (MD5, strings, etc.).
So, I developed some context around the file, by figuring out how it had been launched on the system...which turned out to be that a regular system DLL had been modified to load the malicious DLL. Ah, there's the context! So I could send both files to the malware guy. When I did, it turned out that the regular system DLL on the malware guy's analysis system was 'protected' by Windows File Protection (WFP), so he couldn't just copy the two files onto the system and reboot to get everything to work. So I told him which Registry key to use to just disable WFP for the installation process, and everything worked.
I should point out that many of the EXE samples of malware are run through dynamic analysis by the analyst copying the EXE to the desktop and double-clicking it. However, this was a DLL, so that wouldn't work. Using rundll32.exe might not work, either...figuring out any needed arguments would just take up a lot of time. So, by putting in a few more minutes (because that's all it really amounted to) of analysis, I was able to provide the malware guy with enough information to get the malware sample up and running on the test system.
Once the malware guy got things going on his end, he was able to provide me with information about Registry keys accessed by the malware (in this case, none), as well as more details regarding off-system communications. Because he saw HTTP traffic leaving the test system, this gave us some information as to where to look with respect to how it was doing this, which was confirmed by checking the import table of the DLL once it had been loaded into memory. The malware guy provided me with this information, which told me pretty much where to look for artifacts of the off-system communications.
Yes, 'strings' run against the now un-obfuscated DLL would have provided some information, but by parsing the import table, that information now had the benefit of additional context, which was further added to through the use of more detailed analysis of the malware. For example, the data stolen by the malware was never written to disk...once it was captured in memory, it was sent off the system via the HTTP communications. This was extremely valuable information, as it really narrowed down where we should expect to find artifacts of the data collected/collection process.
The point of all this is that rather than providing simply what was easiest, by collecting additional data/context about particular artifacts, we can provide useful information to someone else, which in turn increases the quality of the information (or intelligence) that we receive in turn, and very often, in a much quicker, more timely manner. In short, I help you to help me...
Now, back to our regularly scheduled program, already in progress...
Okay...so what? Consider this recent blog post...while it is very cool that 7Zip can be used to export the various sections of a PE file into different files, and you can then run 'strings' on those exported sections, one would think that parsing the PE headers would also be beneficial, and provide a modicum of context to the strings extracted from the .text section. Why does that matter? Well, consider this post...from my perspective as a host-based analyst, knowing that the string 'ClearEventLog' was found in the import table versus in the code section makes a huge difference in how I view and value that artifact.
Consider an email address that you found somewhere in an acquired image...wouldn't the relative value of that artifact depend on the context, such as whether or not the email address was associated with emails or not? And if the address were found to be in an email, wouldn't it's context...whether it was found in the To or From block, or within the body of the email...potentially have a significant impact on your exam?
My point is that sometimes what we may find to be interesting from our perspective may not be entirely useful to someone else, particularly someone with an adjacent skill set. Other times, something that we think is completely and totally trivial and not interesting at all may be enormously useful to someone else. A malware analyst may not find that a particular bit of malware that uses the Run key as a persistence mechanism as very interesting, but as a Windows analyst, that piece of information is extremely valuable to me, not only with respect to that particular sample, but also when correlated with other samples, as well as other threats.
So, some thoughts regarding IOCs:
1. Specific, targeted IOCs only really work well for specific samples of malware or specific incidents. By themselves, they may have very limited value. However, when combined/aggregated with other IOCs, they have much greater overall value, in that they will show trends from which more general IOCs can be derived.
2. You don't always have to create a new IOC...sometimes, updating one you already have works much better. Rather than having an IOC that looks for a specific file in a specific directory path (i.e., C:\Windows\ntshrui.dll), why not look for all files of a particular type in that directory, and potentially whitelist the good ones?
3. Working together with analysts with adjacent skill sets, and understanding what artifacts or indicators are valuable to them, produces better overall IOCs. A malware analyst may find an MD5 hash to be useful, but a DF analyst may find that the full path to the file itself, as well as PE headers from the file, are more useful. An malware analyst may find the output of 'strings' to be useful, but a DF analyst may need some sort of context around or associated with those strings.
4. No man, or analyst, is an island. As smart as each of may be, we're not as smart as several of us working together. Tired of the cliche's? Good. Working with other specialists...malware and memory analysts, host-based DF folks, network analysis folks...is a much better solution and produces a much better overall result than one guy trying to do it all himself.
First, a word on specialization. Many of us in the infosec world recognize the need and importance of understanding a general body of knowledge, but at the same time, many of us also gravitate toward a particular specialization, such as digital forensic analysis of mobile devices or Windows systems, web app assessments/pen testing, etc. Very often, we find this specialization to be extremely beneficial to us, not only in what we do, but in our careers, and often our hobbies, as well. What happens when we try to do too much...say, IR, DF, and pen testing? Well, we really don't become an expert at anything in particular, do we? Several years ago, I sat on a panel at the SANS Forensic Summit, and the question was asked about who you'd want to show up to respond to an incident...my answer was someone who responded to incidents, not someone who was doing a pen test last week, and pulling cable the week before that. Think about it...who do you want doing your brain surgery? A trained, experienced neurosurgeon, or someone who, up until 6 months ago, was driving trucks? My point is that due to how complex systems have become, who can really be an expert in everything?
Okay, so to tie that together, while it's good to specialize in something, it's also a really good idea to engage with those with other, ancillary, adjacent specializations. For example, as a digital forensic analyst, I've had some really outstanding successes when I've worked closely with an expert malware analyst (you know who you are, Sean!!). By working together with the malware analyst, and providing what they need to do their job better (i.e., context, specific information such as paths, etc.), and getting detailed information back from them, we were able to develop a great deal more (and more valuable) information for our customer, in less time, than if we'd each worked separately on the case, and even more so than if we'd worked solo, without the benefit of the other's skills.
Part of that success had to do with sharing IOCs between us. Well, we started by sharing the specific indicators associated with what was found...I had not found the indication of the infection until running the fourth AV scanner (a relatively obscure free AV scanner named 'a-squared'). From there, I referred to my timeline, and was able to determine why there seemed to be no Registry-based auto-start mechanisms for the malware. From there, I provided the information I had available to the malware analyst, including information about the target platform, where the malware was found, a copy of the malware itself, etc. After disabling WFP on his the analysis system, the malware guy got the infected files up and running, and pulled information out of memory that I was then able to use to further my analysis within the acquired image (i.e., domain name, etc.). Using this information, I targeted specific artifacts...for example, the malware analysts shared that once the malware DLL was in memory, it was no longer obfuscated, so he was able to parse out the PE headers of the file, including the import table. As the malware DLL imported functions from the WinInet API, it was reasonable to assume (and was verified through analysis) that the malware DLL itself was capable of off-system communications. This made it clear not only that additional malware was not required, but also told us exactly where we should be looking for artifacts. As such, in my analysis of the acquired image, I focused on the IE history for the user in question and the pagefile. I ran strings across the pagefile, looking for indications of the domain name we had, and then wrote a Perl script that would go into the pagefile at that offset for each hit of interest, and grab 100 bytes on either side of the hit. What we ended up getting was several web server responses to the malware's HTTP off-system communications, which included time stamps from the web server, as well as server directives telling the client to not cache anything.
Now, each of us focusing on our specialized areas of analysis, but treating each other like "customers", worked extremely well. We each had a wealth of information available to us and worked closely to determine was the other needed, and what was most valuable.
Addendum: While driving home from work in traffic today, I thought of something that might reveal a bit more about this exchange...
At the early stage of my analysis, I had an acquired image from a system, from which I'd created a timeline, and against which I had run four AV scans. The result of the last scan was where one file was identified as "malicious". Looking at that file within in the image, via FTK Imager, I could see that the file was obfuscated (by the contents of the import table), although I didn't know how it was obfuscated (packed, encrypted, both, etc.). And I only had the acquired image...I didn't have a memory dump. So before I sent it to the malware guy, I had to figure out how this thing was launched...after all, I couldn't just send him the file and ask him, "what can you tell me about this file?", because his answer would be "not much", or not much that I couldn't already figure out for myself (MD5, strings, etc.).
So, I developed some context around the file, by figuring out how it had been launched on the system...which turned out to be that a regular system DLL had been modified to load the malicious DLL. Ah, there's the context! So I could send both files to the malware guy. When I did, it turned out that the regular system DLL on the malware guy's analysis system was 'protected' by Windows File Protection (WFP), so he couldn't just copy the two files onto the system and reboot to get everything to work. So I told him which Registry key to use to just disable WFP for the installation process, and everything worked.
I should point out that many of the EXE samples of malware are run through dynamic analysis by the analyst copying the EXE to the desktop and double-clicking it. However, this was a DLL, so that wouldn't work. Using rundll32.exe might not work, either...figuring out any needed arguments would just take up a lot of time. So, by putting in a few more minutes (because that's all it really amounted to) of analysis, I was able to provide the malware guy with enough information to get the malware sample up and running on the test system.
Once the malware guy got things going on his end, he was able to provide me with information about Registry keys accessed by the malware (in this case, none), as well as more details regarding off-system communications. Because he saw HTTP traffic leaving the test system, this gave us some information as to where to look with respect to how it was doing this, which was confirmed by checking the import table of the DLL once it had been loaded into memory. The malware guy provided me with this information, which told me pretty much where to look for artifacts of the off-system communications.
Yes, 'strings' run against the now un-obfuscated DLL would have provided some information, but by parsing the import table, that information now had the benefit of additional context, which was further added to through the use of more detailed analysis of the malware. For example, the data stolen by the malware was never written to disk...once it was captured in memory, it was sent off the system via the HTTP communications. This was extremely valuable information, as it really narrowed down where we should expect to find artifacts of the data collected/collection process.
The point of all this is that rather than providing simply what was easiest, by collecting additional data/context about particular artifacts, we can provide useful information to someone else, which in turn increases the quality of the information (or intelligence) that we receive in turn, and very often, in a much quicker, more timely manner. In short, I help you to help me...
Now, back to our regularly scheduled program, already in progress...
Okay...so what? Consider this recent blog post...while it is very cool that 7Zip can be used to export the various sections of a PE file into different files, and you can then run 'strings' on those exported sections, one would think that parsing the PE headers would also be beneficial, and provide a modicum of context to the strings extracted from the .text section. Why does that matter? Well, consider this post...from my perspective as a host-based analyst, knowing that the string 'ClearEventLog' was found in the import table versus in the code section makes a huge difference in how I view and value that artifact.
Consider an email address that you found somewhere in an acquired image...wouldn't the relative value of that artifact depend on the context, such as whether or not the email address was associated with emails or not? And if the address were found to be in an email, wouldn't it's context...whether it was found in the To or From block, or within the body of the email...potentially have a significant impact on your exam?
My point is that sometimes what we may find to be interesting from our perspective may not be entirely useful to someone else, particularly someone with an adjacent skill set. Other times, something that we think is completely and totally trivial and not interesting at all may be enormously useful to someone else. A malware analyst may not find that a particular bit of malware that uses the Run key as a persistence mechanism as very interesting, but as a Windows analyst, that piece of information is extremely valuable to me, not only with respect to that particular sample, but also when correlated with other samples, as well as other threats.
So, some thoughts regarding IOCs:
1. Specific, targeted IOCs only really work well for specific samples of malware or specific incidents. By themselves, they may have very limited value. However, when combined/aggregated with other IOCs, they have much greater overall value, in that they will show trends from which more general IOCs can be derived.
2. You don't always have to create a new IOC...sometimes, updating one you already have works much better. Rather than having an IOC that looks for a specific file in a specific directory path (i.e., C:\Windows\ntshrui.dll), why not look for all files of a particular type in that directory, and potentially whitelist the good ones?
3. Working together with analysts with adjacent skill sets, and understanding what artifacts or indicators are valuable to them, produces better overall IOCs. A malware analyst may find an MD5 hash to be useful, but a DF analyst may find that the full path to the file itself, as well as PE headers from the file, are more useful. An malware analyst may find the output of 'strings' to be useful, but a DF analyst may need some sort of context around or associated with those strings.
4. No man, or analyst, is an island. As smart as each of may be, we're not as smart as several of us working together. Tired of the cliche's? Good. Working with other specialists...malware and memory analysts, host-based DF folks, network analysis folks...is a much better solution and produces a much better overall result than one guy trying to do it all himself.
Monday, February 20, 2012
A Little Something on IOCs...
Not long ago, I read Greg's blog post on using HBGary's DDNA to detect APT attackers in memory, and ran across an interesting statement near the end of the post, specifically, the first paragraph in the Using IOC’s effectively subsection (it's kind of long so I won't copy/paste it here...though I highly recommend that you take a look). I have to say, I agree with Greg's statements...IOCs can be effective tools, but like any tool, they are only as effective as how they are used. I think that IOCs have great potential in data reduction and providing an automated facility for removing the "low-hanging fruit" from analysis, thereby leaving the analyst to...you know...analyze. But like Greg says, if your IOCs are just lists of file names and MD5 hashes, then they really aren't all that effective.
Back when I was performing PCI forensic exams, one of the most frustrating things was the lists of "IOCs" we got from one of the major card brands; we'd get these lists of mostly file names and MD5 hashes, two of the most mutable aspects of IOCs, and we were told that we had to include these ever-expanding lists in searches across all acquired images. Okay, so let's say we found bp0.exe during an exam, but the hash was different from the one provided in the issued list...we noted that and sent it back in, and then the next list we saw would have the new hash added to it. However, the lack of sharing any real intel was frustrating, as having a more comprehensive intel model would have allowed all analyst firms to move beyond the relatively simple, "yes, you were compromised" and more toward, "this is how you were compromised, this is your window of compromise, and this is what you can do to prevent it in the future." For example, we'd get file names, but in most cases, not paths. We'd get MD5 hashes, but not fuzzy hashes, and Chris Pogue would push for fuzzy hashes. In most cases, we wouldn't even get things like Registry artifacts that would let us see when something had been installed and run, but then deleted.
So, per Greg's statements, one way to make IOCs more effective is to create them so that they're not just a simple blacklist. Rather than looking for a specific Registry value used for persistence (because file names and Registry value names can be random and change...), have the IOC either dump all of the values in the key for manual review, or correlate multiple keys and values in order to narrow the focus a bit. Again referring back to past PCI engagements, when looking for credit card numbers (CCNs) within an image, we had three checks...length, BIN, and Luhn check...that we would use, but we got a lot of false positives (such as MS GUIDs). However, adding additional checks for track 1 and 2 data not only narrowed down our criteria, but increased our confidence that what we'd found was actual useful data and NOT false positives. So, as Greg suggests, looking for more general things, or adding additional items to your IOCs, can be very effective.
The effectiveness of IOCs is increased though open source intel sharing, by having someone who discovers something develop an effective (and well-documented) IOC and sharing with their team. These IOCs can be even more effective if they're shared openly (even if it's within a relatively closed community), because then they're not only subject to a more open review, but they can also be expanded further.
The effectiveness of IOCs is obviated and completely lost when the folks using IOCs do nothing but consume them; that is, download the latest IOCs and run them without any review or understanding. Tools that use a plugin-based approach (Nessus comes to mind...) are only as effective as the effort put into the plugins, and what's actually reported. A recent InformationWeek article describes eight lessons learned from the recent Nortel revelation...number 6 is "conduct a thorough forensic analysis". If you suspect that you have something untoward going on in your infrastructure, and you run a list of IOCs and don't get anything definitive...maybe it's time to break out the toolkit and take things a step further. You may find something entirely new...or you may simply get peace of mind.
Let's take a look at a couple of tandem blog posts that addressed some malware analysis recently. I caught wind of this on Twitter...we all know how difficult it is to share anything on Twitter, because you have squeeze things down into 140 characters, or make multiple, abbreviated posts...and a lot gets lost that way. First, we have Keith's post on the Digital4rensics blog, and then there's the Digitalsec4u post on the New Age Security blog. Both address different components of the analysis of something that hit an infrastructure and was shared, in order to complete some analysis. You have to look at both of these blog posts together to pull out the IOCs; read the Digitalsec4u post first to see what hit the infrastructure, and what it "looked like" when it came in, and get the Initial Infection Vector. Then read Keith's post to begin getting a view of what happened once the original bit of malware was executed.
Now, I know from some perspectives, neither the malware that was analyzed nor the actual results are particularly "earth shattering", particularly from the perspective of these two gents who very graciously shared their analysis. However, there is considerable value in the data that has been posted and shared. For example, this malware came in as an email attachment, disguised to look like a plane ticket. We can see hashes on the original payload, and we know that these artifacts are easily mutable. We can also see that the malware is packed...that's something we can latch on to (IOC: search email attachment directories for packed executables). Moving over to Keith's post, we begin to see what happens when the original malware is executed. We can use this information to see if our IR (and DF) processes are sufficient to deal with this type of issue; assume that it wasn't detected and blocked by your in-place security mechanisms, how would you go about responding to this? Or, better yet, if part of it was blocked, would your current response and analysis process be suitable to determine that the follow-on stages hadn't actually executed? This is an extremely important question, and one that not a lot of responders and analysts have been trained to consider, or answer.
Some lessons from the two blog posts:
Engage with those with adjacent skill sets; the above two blog posts are great examples of malware analysts doing their thing, but there are a number of artifacts and other bits of information that would be extremely useful for responders and analysts. Keith's blog has some request URLs that network analysts can search for in proxy and firewall logs, but there's a question as to how these requests are made - does the malware use the WinInet APIs? If so, we would expect to see other artifacts on the system, wouldn't we? So, it's not unusual for an analyst to highlight or share what makes sense to them, but they have the information right there in front of them that would be useful to someone else, perhaps someone with an adjacent skill set (responder, DF analyst, network analyst, etc.), so sharing that other information with them would reduce the amount of time looking for these things.
When sharing that information, specificity of language is important. Does the malware create a Registry key...or does it add a value to an existing key? If it adds a value to the Run key...which one? The same is true for file and directory paths, as well as identifying the platform you're infecting during your analysis.
In short, being clear and concise in presenting your findings makes it much easier for someone to not only replicate your findings (taking variations in platform...WinXP vs Win7...into account), but to also use that information in an immediate response mode, and begin seeing if their systems are infected.
Okay, so why are these lessons important? There's a bit more to this than was mentioned in the blog posts; Keith mentioned that one of the bits of malware was identified by Microsoft (via VirusTotal) as PWS:Win32/Sypak.A...which is not just a password stealer, but it's a keystroke logger. This means that it just doesn't capture passwords...it can potentially capture everything, and this can be extremely detrimental to an organization.
Back when I was performing PCI forensic exams, one of the most frustrating things was the lists of "IOCs" we got from one of the major card brands; we'd get these lists of mostly file names and MD5 hashes, two of the most mutable aspects of IOCs, and we were told that we had to include these ever-expanding lists in searches across all acquired images. Okay, so let's say we found bp0.exe during an exam, but the hash was different from the one provided in the issued list...we noted that and sent it back in, and then the next list we saw would have the new hash added to it. However, the lack of sharing any real intel was frustrating, as having a more comprehensive intel model would have allowed all analyst firms to move beyond the relatively simple, "yes, you were compromised" and more toward, "this is how you were compromised, this is your window of compromise, and this is what you can do to prevent it in the future." For example, we'd get file names, but in most cases, not paths. We'd get MD5 hashes, but not fuzzy hashes, and Chris Pogue would push for fuzzy hashes. In most cases, we wouldn't even get things like Registry artifacts that would let us see when something had been installed and run, but then deleted.
So, per Greg's statements, one way to make IOCs more effective is to create them so that they're not just a simple blacklist. Rather than looking for a specific Registry value used for persistence (because file names and Registry value names can be random and change...), have the IOC either dump all of the values in the key for manual review, or correlate multiple keys and values in order to narrow the focus a bit. Again referring back to past PCI engagements, when looking for credit card numbers (CCNs) within an image, we had three checks...length, BIN, and Luhn check...that we would use, but we got a lot of false positives (such as MS GUIDs). However, adding additional checks for track 1 and 2 data not only narrowed down our criteria, but increased our confidence that what we'd found was actual useful data and NOT false positives. So, as Greg suggests, looking for more general things, or adding additional items to your IOCs, can be very effective.
The effectiveness of IOCs is increased though open source intel sharing, by having someone who discovers something develop an effective (and well-documented) IOC and sharing with their team. These IOCs can be even more effective if they're shared openly (even if it's within a relatively closed community), because then they're not only subject to a more open review, but they can also be expanded further.
The effectiveness of IOCs is obviated and completely lost when the folks using IOCs do nothing but consume them; that is, download the latest IOCs and run them without any review or understanding. Tools that use a plugin-based approach (Nessus comes to mind...) are only as effective as the effort put into the plugins, and what's actually reported. A recent InformationWeek article describes eight lessons learned from the recent Nortel revelation...number 6 is "conduct a thorough forensic analysis". If you suspect that you have something untoward going on in your infrastructure, and you run a list of IOCs and don't get anything definitive...maybe it's time to break out the toolkit and take things a step further. You may find something entirely new...or you may simply get peace of mind.
Let's take a look at a couple of tandem blog posts that addressed some malware analysis recently. I caught wind of this on Twitter...we all know how difficult it is to share anything on Twitter, because you have squeeze things down into 140 characters, or make multiple, abbreviated posts...and a lot gets lost that way. First, we have Keith's post on the Digital4rensics blog, and then there's the Digitalsec4u post on the New Age Security blog. Both address different components of the analysis of something that hit an infrastructure and was shared, in order to complete some analysis. You have to look at both of these blog posts together to pull out the IOCs; read the Digitalsec4u post first to see what hit the infrastructure, and what it "looked like" when it came in, and get the Initial Infection Vector. Then read Keith's post to begin getting a view of what happened once the original bit of malware was executed.
Now, I know from some perspectives, neither the malware that was analyzed nor the actual results are particularly "earth shattering", particularly from the perspective of these two gents who very graciously shared their analysis. However, there is considerable value in the data that has been posted and shared. For example, this malware came in as an email attachment, disguised to look like a plane ticket. We can see hashes on the original payload, and we know that these artifacts are easily mutable. We can also see that the malware is packed...that's something we can latch on to (IOC: search email attachment directories for packed executables). Moving over to Keith's post, we begin to see what happens when the original malware is executed. We can use this information to see if our IR (and DF) processes are sufficient to deal with this type of issue; assume that it wasn't detected and blocked by your in-place security mechanisms, how would you go about responding to this? Or, better yet, if part of it was blocked, would your current response and analysis process be suitable to determine that the follow-on stages hadn't actually executed? This is an extremely important question, and one that not a lot of responders and analysts have been trained to consider, or answer.
Some lessons from the two blog posts:
Engage with those with adjacent skill sets; the above two blog posts are great examples of malware analysts doing their thing, but there are a number of artifacts and other bits of information that would be extremely useful for responders and analysts. Keith's blog has some request URLs that network analysts can search for in proxy and firewall logs, but there's a question as to how these requests are made - does the malware use the WinInet APIs? If so, we would expect to see other artifacts on the system, wouldn't we? So, it's not unusual for an analyst to highlight or share what makes sense to them, but they have the information right there in front of them that would be useful to someone else, perhaps someone with an adjacent skill set (responder, DF analyst, network analyst, etc.), so sharing that other information with them would reduce the amount of time looking for these things.
When sharing that information, specificity of language is important. Does the malware create a Registry key...or does it add a value to an existing key? If it adds a value to the Run key...which one? The same is true for file and directory paths, as well as identifying the platform you're infecting during your analysis.
In short, being clear and concise in presenting your findings makes it much easier for someone to not only replicate your findings (taking variations in platform...WinXP vs Win7...into account), but to also use that information in an immediate response mode, and begin seeing if their systems are infected.
Okay, so why are these lessons important? There's a bit more to this than was mentioned in the blog posts; Keith mentioned that one of the bits of malware was identified by Microsoft (via VirusTotal) as PWS:Win32/Sypak.A...which is not just a password stealer, but it's a keystroke logger. This means that it just doesn't capture passwords...it can potentially capture everything, and this can be extremely detrimental to an organization.
Saturday, February 18, 2012
Sharing and Case Studies
There's been some discussion of late in various corners of the DFIR community regarding "sharing" amongst those of us in the community. Some of it has centered on sharing of threat intelligence and IOCs, and that's sort of spawned off into sharing "case studies". I ran across a couple of threads on one online forum (like this one...), where an interest in case studies was expressed, but as is usually the case, few are actually stepping forward to provide them.
My hope is that these discussions have formed a crack in the wall of silence, and that some of us can squeeze our fingers into that crack, and with the help of others in the community, pry it apart.
Andrew Case posted an excellent case study on the DFS blog, one that is truly inspiring. Andrew looked at what he wanted to do and used what was available to him to get it done.
Corey Harrell has posted a number of times to his blog regarding exploit artifacts, and has taken up a series of posts on accessing Volume Shadow Copies. Corey provided some excellent material which he graciously allowed me to incorporate into chapter 3 of WFAT3e, and he has since taken that several steps further. While not specifically related to cases Corey has worked, this is some excellent information that is of significant value to anyone who encounters Vista and Win7 systems.
Recently, Melia post on a "case experience" to her blog, where she had to address an issue of sploitation. I've had similar cases, and I've had issues where such a thing was just part of the case...and I think what Melia's post really points out is that Windows does a great job of illustrating Locard's Exchange Principle; that is, when the user or an application interacts with the operating system, there are very often artifacts of that interaction that survive attempts by the user to cover their tracks.
From a link in Melia's blog post, I found out about the Cheeky4n6Monkey blog, which has some excellent posts, including this one on creating a RegRipper plugin for CCleaner, which actually covers two topic areas: artifacts associated with running CCleaner, and writing a RegRipper plugin. The author correctly points out that I covered how to write RegRipper plugins in WRF.
There are even more examples available of how analysts have pursued real-world cases. Take a look at this post to the Mandiant blog by Nick Harbour, from July, 2010.
I know from experience (in the industry, writing books, etc.) that many of us really enjoy reading or hearing case studies, but the fact is that few of us actually share case studies, or just some portion of our experiences (I won't get into the "why"...). From recent experience, this is disheartening when you go to a conference where many of the presentation titles lead you to believe that case studies or experiences will be shared, but all you get during the presentations, and even out in the common areas between presentations, are blank stares.
No one of us is as smart as all of us. There are some of us who've seen a lot of things, but no one has seen or done everything. Sharing what we've seen through presentations and blog posts is a great way for us to learn, without having to have had the actual experiences.
My hope is that these discussions have formed a crack in the wall of silence, and that some of us can squeeze our fingers into that crack, and with the help of others in the community, pry it apart.
Andrew Case posted an excellent case study on the DFS blog, one that is truly inspiring. Andrew looked at what he wanted to do and used what was available to him to get it done.
Corey Harrell has posted a number of times to his blog regarding exploit artifacts, and has taken up a series of posts on accessing Volume Shadow Copies. Corey provided some excellent material which he graciously allowed me to incorporate into chapter 3 of WFAT3e, and he has since taken that several steps further. While not specifically related to cases Corey has worked, this is some excellent information that is of significant value to anyone who encounters Vista and Win7 systems.
Recently, Melia post on a "case experience" to her blog, where she had to address an issue of sploitation. I've had similar cases, and I've had issues where such a thing was just part of the case...and I think what Melia's post really points out is that Windows does a great job of illustrating Locard's Exchange Principle; that is, when the user or an application interacts with the operating system, there are very often artifacts of that interaction that survive attempts by the user to cover their tracks.
From a link in Melia's blog post, I found out about the Cheeky4n6Monkey blog, which has some excellent posts, including this one on creating a RegRipper plugin for CCleaner, which actually covers two topic areas: artifacts associated with running CCleaner, and writing a RegRipper plugin. The author correctly points out that I covered how to write RegRipper plugins in WRF.
There are even more examples available of how analysts have pursued real-world cases. Take a look at this post to the Mandiant blog by Nick Harbour, from July, 2010.
I know from experience (in the industry, writing books, etc.) that many of us really enjoy reading or hearing case studies, but the fact is that few of us actually share case studies, or just some portion of our experiences (I won't get into the "why"...). From recent experience, this is disheartening when you go to a conference where many of the presentation titles lead you to believe that case studies or experiences will be shared, but all you get during the presentations, and even out in the common areas between presentations, are blank stares.
No one of us is as smart as all of us. There are some of us who've seen a lot of things, but no one has seen or done everything. Sharing what we've seen through presentations and blog posts is a great way for us to learn, without having to have had the actual experiences.
Monday, March 01, 2010
Thoughts on posing questions, and sharing
I ran across a question on a list recently that I responded to when I saw it, but as time has passed, I've reconsidered my response somewhat. And whatnot.
The question I saw had to do with RegRipper, specifically my thoughts on meeting the needs of the community and creating new plugins. Basically, all I've ever asked for in that regard is a concise description of the need or issue, and a sample hive file. The person asking the question wanted to know if I seriously expected folks to provide hive files from live cases. My initial reaction was no, there are other ways to provide the necessary data. Such as setting up a test environment, replicating the issue, and sending me that hive file. However, I began to reconsider that response...if someone doesn't really know the difference between a Registry key and a value, and they have a question, how would they go about crafting the question? Once they do that, how would they go about discerning the responses they received, and figuring out which applied to what they were working on?
Seriously, there are a lot of things out there that require specific use of language, and specificity of language can be somewhat lacking in our community.
Taking that a step further, one of the problems I've seen for a number of years is that some questions that need to be asked simply don't get asked, because people in the community don't want to share information; apparently, "sharing information" has a number of different connotations. Some folks don't want it publicly known that they don't know something...even if asking the question means that they'll end up knowing the answer. I've seen this before...I didn't want to ask the question, because I didn't want to look dumb. To that, my response is usually along the lines of, so you don't ask the question, and we overcharge the customer for an inferior deliverable, our billing rate drops, AND you don't know the answer for the next time you need it. Really...which situation really makes you look dumb? Another one I see is that some folks don't ask questions publicly because they just don't want others to know that they had to ask...to which I usually suggest that if they had asked the question, they'd then know the answer, obviating the issue all together.
Others apparently don't ask questions because they're afraid that they'll have to give up sensitive information...information about a case that they're working on, etc. I understand that folks working CP cases don't want that stuff out...and to be honest, I don't either. I do want to help...and sometimes, due the "cop-nerd language barrier" sometimes the best and fastest way to help is to get the actual Registry hive or Event Log file. And guess what? Hive files don't (usually) contain graphics.
Like many folks, my desire to help comes from just that...a desire to help. If my helping makes it easier for an LE to be prepared to address the Trojan Defense, or better yet, to do so in a manner that gets a plea agreement, then that's good. I do NOT want to see the images, and I and others can help without seeing them.
Another issue is that some folks don't ask questions because they don't know enough about the situation to ask the question. This can be a particular issue in digital forensics, because there are certain things that really make a difference in how the respondent answers...such as, the file system, or even the version of the operating system. NTFS is different from FAT is different from ext2/3, and Windows XP has a number of differences from Windows 2000, as well as Vista.
Here's an example...some folks will ask questions such as, "how do I tell when a file was first created on a system?", without really realizing that the system in question, and perhaps even the document type, can greatly affect the answer. So sometimes the initial question is asked, but there may not be any response to (repeated) requests for clarification to the original question.
Does the version of Windows really matter, generally speaking? When you're dealing with any kind of IR or forensic analysis, the answer is most often going to be "yes".
So the big question is, if you have a question, do you want an answer to it? Are you willing to provide the necessary information such that someone can provide a succinct response? I know some folks who will not even attempt to answer a question that require an encyclopedic answer.
Before we go on, let me say that I complete understand and agree that we can't know everything. No one of us can know it all...that's where there's strength in a community of sharing. There's no way that you're going to know everything you need to know for every exam...there are going to be things that we don't remember (maybe from a training course a couple of years ago, or something you read once...), and there are going to be things that we just don't know.
So what can we, as a community, do? Well, one way to look at is that the question I have...well, someone else in the room or on the board may have the same question; they may not know it yet. So if that question gets asked, then others will be able to see the answers and then ask the next question, expanding that information. The point is that no one of us is as smart as all of us together.
Find someone you can trust, someone you're willing to share information with. If you need to, establish an NDA. Have community meetings in local areas. If you don't feel comfortable sharing with some folks because you don't know them...get to know them.
The other option is that you learn to do it yourself...and that's not always going to work. You may spend 8 months examining MacOSX systems, and suddenly have to examine a Windows 7 system. What're you going to do then? Sure, spending all weekend gettin' giggy wit' Google will likely net (no pun intended) you something, but at what point do you reach overload?
Over the years, I've met a number of folks with skills and abilities for which I have a great deal of respect, and some of those I've reached to for assistance when I've needed it. Conversely, I've done my best to respond to those folks who've reached to me with questions regarding areas I'm specifically interested in.
Anyway, I'll bring this rambling to a close...
Addendum: Sometimes a really good place to start with questions is to seek answers at the ForensicsWiki. This is also good place to post the answers once you get them.
The question I saw had to do with RegRipper, specifically my thoughts on meeting the needs of the community and creating new plugins. Basically, all I've ever asked for in that regard is a concise description of the need or issue, and a sample hive file. The person asking the question wanted to know if I seriously expected folks to provide hive files from live cases. My initial reaction was no, there are other ways to provide the necessary data. Such as setting up a test environment, replicating the issue, and sending me that hive file. However, I began to reconsider that response...if someone doesn't really know the difference between a Registry key and a value, and they have a question, how would they go about crafting the question? Once they do that, how would they go about discerning the responses they received, and figuring out which applied to what they were working on?
Seriously, there are a lot of things out there that require specific use of language, and specificity of language can be somewhat lacking in our community.
Taking that a step further, one of the problems I've seen for a number of years is that some questions that need to be asked simply don't get asked, because people in the community don't want to share information; apparently, "sharing information" has a number of different connotations. Some folks don't want it publicly known that they don't know something...even if asking the question means that they'll end up knowing the answer. I've seen this before...I didn't want to ask the question, because I didn't want to look dumb. To that, my response is usually along the lines of, so you don't ask the question, and we overcharge the customer for an inferior deliverable, our billing rate drops, AND you don't know the answer for the next time you need it. Really...which situation really makes you look dumb? Another one I see is that some folks don't ask questions publicly because they just don't want others to know that they had to ask...to which I usually suggest that if they had asked the question, they'd then know the answer, obviating the issue all together.
Others apparently don't ask questions because they're afraid that they'll have to give up sensitive information...information about a case that they're working on, etc. I understand that folks working CP cases don't want that stuff out...and to be honest, I don't either. I do want to help...and sometimes, due the "cop-nerd language barrier" sometimes the best and fastest way to help is to get the actual Registry hive or Event Log file. And guess what? Hive files don't (usually) contain graphics.
Like many folks, my desire to help comes from just that...a desire to help. If my helping makes it easier for an LE to be prepared to address the Trojan Defense, or better yet, to do so in a manner that gets a plea agreement, then that's good. I do NOT want to see the images, and I and others can help without seeing them.
Another issue is that some folks don't ask questions because they don't know enough about the situation to ask the question. This can be a particular issue in digital forensics, because there are certain things that really make a difference in how the respondent answers...such as, the file system, or even the version of the operating system. NTFS is different from FAT is different from ext2/3, and Windows XP has a number of differences from Windows 2000, as well as Vista.
Here's an example...some folks will ask questions such as, "how do I tell when a file was first created on a system?", without really realizing that the system in question, and perhaps even the document type, can greatly affect the answer. So sometimes the initial question is asked, but there may not be any response to (repeated) requests for clarification to the original question.
Does the version of Windows really matter, generally speaking? When you're dealing with any kind of IR or forensic analysis, the answer is most often going to be "yes".
So the big question is, if you have a question, do you want an answer to it? Are you willing to provide the necessary information such that someone can provide a succinct response? I know some folks who will not even attempt to answer a question that require an encyclopedic answer.
Before we go on, let me say that I complete understand and agree that we can't know everything. No one of us can know it all...that's where there's strength in a community of sharing. There's no way that you're going to know everything you need to know for every exam...there are going to be things that we don't remember (maybe from a training course a couple of years ago, or something you read once...), and there are going to be things that we just don't know.
So what can we, as a community, do? Well, one way to look at is that the question I have...well, someone else in the room or on the board may have the same question; they may not know it yet. So if that question gets asked, then others will be able to see the answers and then ask the next question, expanding that information. The point is that no one of us is as smart as all of us together.
Find someone you can trust, someone you're willing to share information with. If you need to, establish an NDA. Have community meetings in local areas. If you don't feel comfortable sharing with some folks because you don't know them...get to know them.
The other option is that you learn to do it yourself...and that's not always going to work. You may spend 8 months examining MacOSX systems, and suddenly have to examine a Windows 7 system. What're you going to do then? Sure, spending all weekend gettin' giggy wit' Google will likely net (no pun intended) you something, but at what point do you reach overload?
Over the years, I've met a number of folks with skills and abilities for which I have a great deal of respect, and some of those I've reached to for assistance when I've needed it. Conversely, I've done my best to respond to those folks who've reached to me with questions regarding areas I'm specifically interested in.
Anyway, I'll bring this rambling to a close...
Addendum: Sometimes a really good place to start with questions is to seek answers at the ForensicsWiki. This is also good place to post the answers once you get them.
Subscribe to:
Posts (Atom)