Exploit Artifacts
There was an interesting blog post on the MMPC site recently, regarding an increase in attacks against the Help and Support Center vulnerability. While the post talks about an increase in attacks through the use of signatures, one thing I'm not seeing is any discussion of the artifacts of the exploit. I'm not talking about a secondary or tertiary download...those can change, and I don't want people to think, "hey, if you're infected with this malware, you were hit with the hcp:// exploit...". Look at it from a compartmentalized perspective...exploit A succeeds and leads to malware B being downloaded onto the system. If malware B can be anything...how do we go about determining the Initial Infection Vector? After all, isn't that what customers ask us? Okay, raise your hand if your typical answer is something like, "...we were unable to determine that...".
I spoke briefly to Troy Larson at the recent SANS Forensic Summit about this, and he expressed some interest in developing some kind of...something...to address this issue. I tend to think that there's a great benefit to this sort of thing, and that a number of folks would benefit from this, including LE.
Awards
The Forensic 4Cast Awards were...uh...awarded during the recent SANS Forensic Summit, and it appears that WFA 2/e received the award for "Best Forensics Book". Thanks to everyone who voted for the book...I greatly appreciate it!
Summit Follow-up
Chris and Richard posted their thoughts on the recent SANS Forensic Summit. In his blog post, Richard said:
I heard Harlan Carvey say something like "we need to provide fewer Lego pieces and more buildings." Correct me if I misheard Harlan. I think his point was this: there is a tendency for speakers, especially technical thought and practice leaders like Harlan, to present material and expect the audience to take the next few logical steps to apply the lessons in practice. It's like "I found this in the registry! Q.E.D." I think as more people become involved in forensics and IR, we forever depart the realm of experts and enter more of a mass-market environment where more hand-holding is required?
Yes, Richard, you heard right...but please indulge me while I explain my thinking here...
In the space of a little more than a month, I attended four events...the TSK/Open Source conference, the FIRST conference, a seminar that I presented, and the SANS Summit. In each of these cases, while someone was speaking (myself included) I noticed a lot of blank stares. In fact, at the Summit, Carole Newell stated at one point during Troy Larson's presentation that she had no idea what he was talking about. I think that we all need to get a bit better at sharing information and making it easier for the right folks to get (understand) what's going on.
First, I don't think for an instant that, from a business perspective, the field of incident responders and analysts is saturated. There will always be more victims (i.e., folks needing help) than there are folks or organizations qualified and able to really assist them.
Second, one of the biggest issues I've seen during my time as a responder is that regardless of how many "experts" speak at conferences or directly to organizations, those organizations that do get hit/compromised are woefully unprepared. Hey, in addition to having smoke alarms, I keep fire extinguishers in specific areas of my house because I see the need to immediate, emergency response. I'm not going to wait for the fire department to arrive, because even with their immediate response, I can do something to contain the damage and losses. My point is that if we can get the folks who are on-site on-board, maybe we'll have fewer intrusions and data breaches that are (a) third-party notification weeks after the fact, and (b) actually have some preserved data available when we (responders) show up.
If we, as "experts", were to do a better job of bringing this stuff home and making it understandable, achievable and useful to others, maybe we'd see the needle move just a little bit in the good guy's favor when it comes to investigating intrusions and targeted malware. I think we'd get better responsiveness from the folks already on-site (the real _first_ responders) and ultimately be able to do a better job of addressing incidents and breaches overall.
Tools
As part of a recent forensic challenge, Wesley McGrew created pcapline.py to help answer the questions of the challenge. Rather than focusing on the tool itself, what I found interesting was that Wesley was faced with a problem/challenge, and chose to create something to help him solve it. And then provide it to others. This is a great example of the I have a problem and created something to solve it...and others might see the same problem as well approach to analysis.
Speaking of tools, Jesse is looking to update md5deep, and has posted some comments about the new design of the tool. More than anything else, I got a lot out of just reading the post and thinking about what he was saying. Admittedly, I haven't had to do much hashing in a while, but when I was doing PCI forensic assessments, this was a requirement. I remember looking at the list and thinking to myself that there had to be a better way to do this stuff...we'd get lists of file names, and lists of hashes...many times, separate lists. "Here, search for this hash..."...but nothing else. No file name, path or size, and no context whatsoever. Why does this matter? Well, there were also time constraints on how long you had before you had to get your report in, so anything that would intelligently speed up the "analysis" without sacrificing accuracy would be helpful.
I also think that Jesse is one of the few real innovators in the community, and has some pretty strong arguments (whether he's aware of it or not) for moving to the new format he mentioned as the default output for md5deep. It's much faster to check the size of the file first...like he says, if the file size is different, you're gonna get a different hash. As disk sizes increase, and our databases of hashes increase, we're going to have to find smart ways to conduct our searches and analysis, and I think that Jesse's got a couple listed right there in his post.
New Attack?
Many times when I've been working an engagement, the customer wants to know if they were specifically targeted...did the intruder specifically target them based on data and/or resources, or was the malware specifically designed for their infrastructure? When you think about it, these are valid concerns. Brian Krebs posted recently on an issue where that's already been determined to be the case...evidently, there's an issue with how Explorer on Windows 7 processes shortcut files, and the malware in question apparently targets specific SCADA systems.
At this point, I don't which is more concerning...that someone knows enough about Seimens systems to write malware for them, or that they know that SCADA systems are now running Windows 7...or both?
When I read about this issue, my first thoughts went back to the Exploit Artifacts section above...what does this "look like" to a forensic examiner?
Hidden Files
Not new at all, but here's a good post from the AggressiveVirusDefense blog that provides a number of techniques that you can use to look for "hidden" files. Sometimes "hidden" really isn't...it's just a matter of perception.
DLL Search Order as a Persistence Mechanism
During the SANS Forensic Summit, Nick Harbour mentioned the use of MS's DLL Search Order as a persistence mechanism. Now he's got a very good post up on the M-unition blog...I won't bother trying to summarize it, as it won't do the post justice. Just check it out. It's an excellent read.
Thursday, July 15, 2010
Friday, July 09, 2010
SANS Forensic Summit Take-Aways
I attended the SANS Forensic Summit yesterday...I won't be attending today due to meetings and work, but I wanted to provide some follow-up, thoughts, etc.
The day started off with the conference intro from Rob Lee, and then a keynote discussion from Chris Pogue of TrustWave and Major Carole Newell, Commander of Headquarters Division the Broken Arrow Police Dept. This was more of a discussion and less of a presentation, and focused on communications between private sector forensic consultants and (local) LE. Chris had volunteered to provide his services, pro bono, to the department, and Major Newell took him up on his offer, and they both talked about how successful that relationship has been. After all, Chris's work has helped put bad people in jail...and that's the overall goal, isn't it? Private sector analysts supporting LE has been a topic of discussion in several venues, and it was heartening to hear Maj Newell chime in and provide her opinion on the subject, validating the belief that this is something that needs to happen.
There were a number of excellent presentations and panels during the day. During the Malware Reverse Engineering panel, Nick Harbour of Mandiant mentioned seeing the MS DLL Search Order being employed as a malware persistence mechanism. I got a lot from Troy Larson's and Jesse Kornblum's presentations, and sat next to Mike Murr while he tweeted using the #forensicsummit tag to keep folks apprised of the latest comments, happenings, and shenanigans.
Having presented and been on a panel, it was great opportunity to share my thoughts and experiences and get comments and feedback not only from other panelists, but also from the attendees.
One of the things I really like about this conference is the folks that it brings together. I got to reconnect with friends, and talk to respected peers that I haven't seen in a while (Chris Pogue, Matt Shannon, Jesse Kornblum, Troy Larson, Richard Bejtlich), or have never met face-to-face (Dave Nardoni, Lee Whitfield, Mark McKinnon). This provides a great opportunity for sharing and discussing what we're all seeing out there, as well as just catching up. Also, like I said, it's great to discuss things with other folks in the industry...I think that a lot of times, if we're only engaging with specific individuals time and again, we tend to loose site of certain aspects of what we do, and what it means to others...other responders, as well as customers.
If someone asked me to name one thing that I would recommend as a change to the conference, that would be the venue. While some folks live and/or work close to downtown DC and it's easy to get to the hotel where the conference is held, there are a number of locations west of DC that are easily accessible from Dulles Airport (and folks from Arlington and Alexandria will be going against traffic to get there).
Other than that, I think the biggest takeaways, for me, were:
1. We need to share better. I thought I was one of the few who thought this, but from seeing the tweets on the conference and talking to folks who are there, it's a pretty common thread. Sharing between LE and the private sector is a challenge, but as Maj Newell said, it's one that everyone (except the bad guys) benefits from.
2. When giving presentations, I need to spend less time talking about what's cool and spend more time on a Mission Guide (a la Matt Shannon) approach to the material. Throwing legos on the table and expecting every analyst to 'get it' and build the same structure is a waste of time...the best way to demonstrate the usefulness and value of a tool or technique is to demonstrate how it's used.
Thanks to Rob and SANS for putting on another great conference!
Follow-ups
Foremost on Windows (Cygwin build)
The day started off with the conference intro from Rob Lee, and then a keynote discussion from Chris Pogue of TrustWave and Major Carole Newell, Commander of Headquarters Division the Broken Arrow Police Dept. This was more of a discussion and less of a presentation, and focused on communications between private sector forensic consultants and (local) LE. Chris had volunteered to provide his services, pro bono, to the department, and Major Newell took him up on his offer, and they both talked about how successful that relationship has been. After all, Chris's work has helped put bad people in jail...and that's the overall goal, isn't it? Private sector analysts supporting LE has been a topic of discussion in several venues, and it was heartening to hear Maj Newell chime in and provide her opinion on the subject, validating the belief that this is something that needs to happen.
There were a number of excellent presentations and panels during the day. During the Malware Reverse Engineering panel, Nick Harbour of Mandiant mentioned seeing the MS DLL Search Order being employed as a malware persistence mechanism. I got a lot from Troy Larson's and Jesse Kornblum's presentations, and sat next to Mike Murr while he tweeted using the #forensicsummit tag to keep folks apprised of the latest comments, happenings, and shenanigans.
Having presented and been on a panel, it was great opportunity to share my thoughts and experiences and get comments and feedback not only from other panelists, but also from the attendees.
One of the things I really like about this conference is the folks that it brings together. I got to reconnect with friends, and talk to respected peers that I haven't seen in a while (Chris Pogue, Matt Shannon, Jesse Kornblum, Troy Larson, Richard Bejtlich), or have never met face-to-face (Dave Nardoni, Lee Whitfield, Mark McKinnon). This provides a great opportunity for sharing and discussing what we're all seeing out there, as well as just catching up. Also, like I said, it's great to discuss things with other folks in the industry...I think that a lot of times, if we're only engaging with specific individuals time and again, we tend to loose site of certain aspects of what we do, and what it means to others...other responders, as well as customers.
If someone asked me to name one thing that I would recommend as a change to the conference, that would be the venue. While some folks live and/or work close to downtown DC and it's easy to get to the hotel where the conference is held, there are a number of locations west of DC that are easily accessible from Dulles Airport (and folks from Arlington and Alexandria will be going against traffic to get there).
Other than that, I think the biggest takeaways, for me, were:
1. We need to share better. I thought I was one of the few who thought this, but from seeing the tweets on the conference and talking to folks who are there, it's a pretty common thread. Sharing between LE and the private sector is a challenge, but as Maj Newell said, it's one that everyone (except the bad guys) benefits from.
2. When giving presentations, I need to spend less time talking about what's cool and spend more time on a Mission Guide (a la Matt Shannon) approach to the material. Throwing legos on the table and expecting every analyst to 'get it' and build the same structure is a waste of time...the best way to demonstrate the usefulness and value of a tool or technique is to demonstrate how it's used.
Thanks to Rob and SANS for putting on another great conference!
Follow-ups
Foremost on Windows (Cygwin build)
Wednesday, July 07, 2010
More Timeline Stuff
I'll be at the SANS Forensic Summit tomorrow, giving a presentation on Registry and Timeline Analysis in the morning, and then participating on a panel in the afternoon. Over all, it looks like this will be another excellent conference, due to the folks attending, their presentations, and opportunities for networking.
I talk (and blog) a lot about timelines, as this is a very powerful technique that I, and others, have found to be very useful. I've given presentations on the subject (including a seminar last week), written articles about it, and used the technique to great effect on a number of investigations. In many instances, this technique has allowed me to "see" things that would not normally be readily apparent through a commercial forensic analysis tool, nor via any other technique.
One of the aspects of Windows systems is that there a wide range of data sources that provide time stamped events and indicators. I mean, the number of locations within a Windows system that provides this sort of information is simply incredible.
To meet my own needs, I've updated my toolkit to include a couple of additional tools. For one, I've created a script that directly parses the IE index.dat files, rather than going through a third-party tool (pasco, Web Historian, etc.). This just cuts down on the steps required, and the libmsiecf tools, mentioned in Cory's Going Commando presentation, does not appear to be readily available to run on Windows systems.
Parsing EVT files is relatively straightforward using tools such as evtparse.pl, and Andreas provides a set of Perl-based tools to parse EVTX (Event Logs from Vista and above) files. As an alternative, I wanted to write something that could easily parse the output of LogParser (free from MS), when run against EVT or EVTX files, using a command such as the following:
logparser -i:evt -o:csv "SELECT * FROM D:\Case\File\SysEvent.EVT" > output.csv
Keep in mind that LogParser uses the native API on the system to parse the EVT/EVTX files, so if you're going to parse EVTX files extracted from a Vista or Windows 2008 or Windows 7 system, you should do so on a Windows 7 system or VM. The output from the LogParser command is easily read and output to a TLN format, and the output from the script I wrote is identical to that of evtparse.pl. This can be very useful, as LogParser can be installed on and run from a DVD or thumb drive, and used in live IR (change "D:\Case\File\SysEvent.EVT" to "System" or "Application"), as well as run against files extracted from acquired images (or files accessible via a mounted image). However, keep in mind that LogParser uses the native API, so if sysevent.evt won't open in the Event Viewer because it is reportedly "corrupted" (which has been reported for EVT files from XP and 2003), then using evtparse.pl would be the preferable approach.
The next tool I'm considering working on is one to parse the MFT and extract the time stamps from the $FILE_NAME attribute into TLN format. This would undoubtedly provide some insight into the truth about what happened on a system, particularly where some sort of timestomping activity has occurred (a la Clampi). This will take some work, as the full paths need to be reassembled, but it should be useful nonetheless.
I talk (and blog) a lot about timelines, as this is a very powerful technique that I, and others, have found to be very useful. I've given presentations on the subject (including a seminar last week), written articles about it, and used the technique to great effect on a number of investigations. In many instances, this technique has allowed me to "see" things that would not normally be readily apparent through a commercial forensic analysis tool, nor via any other technique.
One of the aspects of Windows systems is that there a wide range of data sources that provide time stamped events and indicators. I mean, the number of locations within a Windows system that provides this sort of information is simply incredible.
To meet my own needs, I've updated my toolkit to include a couple of additional tools. For one, I've created a script that directly parses the IE index.dat files, rather than going through a third-party tool (pasco, Web Historian, etc.). This just cuts down on the steps required, and the libmsiecf tools, mentioned in Cory's Going Commando presentation, does not appear to be readily available to run on Windows systems.
Parsing EVT files is relatively straightforward using tools such as evtparse.pl, and Andreas provides a set of Perl-based tools to parse EVTX (Event Logs from Vista and above) files. As an alternative, I wanted to write something that could easily parse the output of LogParser (free from MS), when run against EVT or EVTX files, using a command such as the following:
logparser -i:evt -o:csv "SELECT * FROM D:\Case\File\SysEvent.EVT" > output.csv
Keep in mind that LogParser uses the native API on the system to parse the EVT/EVTX files, so if you're going to parse EVTX files extracted from a Vista or Windows 2008 or Windows 7 system, you should do so on a Windows 7 system or VM. The output from the LogParser command is easily read and output to a TLN format, and the output from the script I wrote is identical to that of evtparse.pl. This can be very useful, as LogParser can be installed on and run from a DVD or thumb drive, and used in live IR (change "D:\Case\File\SysEvent.EVT" to "System" or "Application"), as well as run against files extracted from acquired images (or files accessible via a mounted image). However, keep in mind that LogParser uses the native API, so if sysevent.evt won't open in the Event Viewer because it is reportedly "corrupted" (which has been reported for EVT files from XP and 2003), then using evtparse.pl would be the preferable approach.
The next tool I'm considering working on is one to parse the MFT and extract the time stamps from the $FILE_NAME attribute into TLN format. This would undoubtedly provide some insight into the truth about what happened on a system, particularly where some sort of timestomping activity has occurred (a la Clampi). This will take some work, as the full paths need to be reassembled, but it should be useful nonetheless.
Tuesday, July 06, 2010
Links
Malware in PDFs
As a responder and forensic analyst, one of the things I'm usually very interested in (in part, because customers want to know...) is determining how some malware (or someone) was first able to get on a system, or into an infrastructure...what was the Initial Infection Vector? I've posted about this before, and the SANS ISC had an interesting post yesterday, as well, regarding malware in PDF files. This is but one IIV, but
Does this really matter beyond simply determining the IIV for malware or an intrusion? I'd say...yes, it does. But why is that? Well, consider this...this likely started small, with someone getting into the infrastructure, and then progressed from there.
PDF files are one way in...Brian Krebs pointed out another IIV recently, which apparently uses the hcp:// protocol to take advantage of an issue in the HextoNum function and allow an attacker to run arbitrary commands. MS's solution/workaround for the time being is to simply delete a Registry key. More information on exploiting the vulnerability can be seen here (the fact that the vulnerability is actively being exploited is mentioned here)...this is a very interesting read, and I would be interested to see what artifacts there may be to the use of an exploit as described in the post. Don's mentioned other artifacts associated with exploiting compiled HelpHTML files, in particular how CHM functionality can be turned into a malware dropper. But this is a bit different, so I'd be interested to see what analysts may be able to find out.
Also, if anyone knows of a tool or process for parsing hh.dat files, please let me know.
Free Tools
For those interested, here's a list of free forensic tools at ForensicControl.com. I've seen where folks have looked for this sort of thing, and the disadvantage of having lists like this out there is that...well...they're they're out there, and not in one centralized location. I know some folks have really liked the list of network security tools posted at InSecure.org, and it doesn't take much to create something like that at other sites. For example, consider posting something on the ForensicsWiki.
Speaking of tools, Claus has a great post from the 4th that mentions some updates to various tools, including ImDisk, Network Monitor, and some nice remote control utilities. If you're analyzing Windows 2008 or Windows 7 systems, you might want to take a look at AppCrashView from Nirsoft...I've been able to find a good deal of corroborating data in Dr. Watson logs on Windows XP/2003 systems, and this looks like it might be just as useful, if not more so.
Shadow Analyzer
There's been some press lately about a tool called "Shadow Analyzer", developed by Lee Whitfield and Mark McKinnon, which is to be used to access files in Volume Shadow Copies. I also see that this has been talked about on the CyberCrime101 podcast...should be a good listen!
On that note, ShadowExplorer is at version 0.7.
Parsing NTFS Journal Files
Seth recently posted a Python script for parsing NTFS Journal Transaction Log files (ie, $USNJRNL:$J files). I don't know about others but I've been doing a lot of a parsing of NTFS-related files, whether it's the MFT itself, or running $LogFile through BinText.
I'm sure that one of the things that would help with folks adopting tools like this, particularly those that may require Python or Perl being installed, is an explanation or examples of how the information can be useful to an examiner/analyst. So, if folks do find that these tools are useful, post something that lets others know why/how you used it, and what you found that supported your examination goals.
As a responder and forensic analyst, one of the things I'm usually very interested in (in part, because customers want to know...) is determining how some malware (or someone) was first able to get on a system, or into an infrastructure...what was the Initial Infection Vector? I've posted about this before, and the SANS ISC had an interesting post yesterday, as well, regarding malware in PDF files. This is but one IIV, but
Does this really matter beyond simply determining the IIV for malware or an intrusion? I'd say...yes, it does. But why is that? Well, consider this...this likely started small, with someone getting into the infrastructure, and then progressed from there.
PDF files are one way in...Brian Krebs pointed out another IIV recently, which apparently uses the hcp:// protocol to take advantage of an issue in the HextoNum function and allow an attacker to run arbitrary commands. MS's solution/workaround for the time being is to simply delete a Registry key. More information on exploiting the vulnerability can be seen here (the fact that the vulnerability is actively being exploited is mentioned here)...this is a very interesting read, and I would be interested to see what artifacts there may be to the use of an exploit as described in the post. Don's mentioned other artifacts associated with exploiting compiled HelpHTML files, in particular how CHM functionality can be turned into a malware dropper. But this is a bit different, so I'd be interested to see what analysts may be able to find out.
Also, if anyone knows of a tool or process for parsing hh.dat files, please let me know.
Free Tools
For those interested, here's a list of free forensic tools at ForensicControl.com. I've seen where folks have looked for this sort of thing, and the disadvantage of having lists like this out there is that...well...they're they're out there, and not in one centralized location. I know some folks have really liked the list of network security tools posted at InSecure.org, and it doesn't take much to create something like that at other sites. For example, consider posting something on the ForensicsWiki.
Speaking of tools, Claus has a great post from the 4th that mentions some updates to various tools, including ImDisk, Network Monitor, and some nice remote control utilities. If you're analyzing Windows 2008 or Windows 7 systems, you might want to take a look at AppCrashView from Nirsoft...I've been able to find a good deal of corroborating data in Dr. Watson logs on Windows XP/2003 systems, and this looks like it might be just as useful, if not more so.
Shadow Analyzer
There's been some press lately about a tool called "Shadow Analyzer", developed by Lee Whitfield and Mark McKinnon, which is to be used to access files in Volume Shadow Copies. I also see that this has been talked about on the CyberCrime101 podcast...should be a good listen!
On that note, ShadowExplorer is at version 0.7.
Parsing NTFS Journal Files
Seth recently posted a Python script for parsing NTFS Journal Transaction Log files (ie, $USNJRNL:$J files). I don't know about others but I've been doing a lot of a parsing of NTFS-related files, whether it's the MFT itself, or running $LogFile through BinText.
I'm sure that one of the things that would help with folks adopting tools like this, particularly those that may require Python or Perl being installed, is an explanation or examples of how the information can be useful to an examiner/analyst. So, if folks do find that these tools are useful, post something that lets others know why/how you used it, and what you found that supported your examination goals.
Saturday, July 03, 2010
Skillz Follow-up
Based on some of the events of the week, and in light of a follow-up post from Eric, I wanted to follow-up on my last blog post.
Earlier this week, I spent an entire day talking with a great group of folks on the other side of the country...a whole day dedicated to just talking about forensics! Some of what we talked about was malware (specifically, 'bot) related, and as part of that, we (of course) talked about some of the issues related to malware characteristics and timeline analysis. One of the aspects that ties all of these topics together is timestomping...when some malware gets installed, the file times (more appropriately, the $STANDARD_INFORMATION attributes within the MFT) are purposely modified. MS provides open APIs (GetFileTime/SetFileTime) that allow for this, and in some cases, the file times for the malware are copied from a legitimate system file.
So, tying this back to "skillz"...in my previous post, I'd mentioned modifying my own code to extract the information I wanted from the MFT. Interestingly, Eric's post addressed the issue of having the information available, and I tend to agree with the first comment to his post...too many times, some GUI analysis tools get over-crowded and there's just too much stuff around to really make sense of things. Rather than having a commercial analysis app into which I can load an image and have it tell me everything that's wrong, I tend to rely on the goals for the analysis that I work out with the customer...even if it means that I would use separate tools. I don't always need information from the MFT...but sometimes I might. So do I want to pay for a commercial application that's going to attempt to keep up with all of the possible wrong stuff that's out there, or can I use a core set of open-source tools that allow me to get the information I need, when I need it, because I know what I'm looking for?
So, what does the output of my code look like? Check out the image...does this make sense to folks? How about to folks familiar with the MFT? Sure, it makes sense to me...and because the code is open source, I can open the Perl script in an editor or Notepad and see what some of the information means.
For example, on the first line, we see:
132315 FILE 2 1 0x38 4 1
What does that mean? The first number is the count, or number of the MFT record. The word "FILE" is the signature...the other possible entry is "BAAD". The number "2" is the sequence number, and the "1" is the link count. Where did I get this? From the code, and it's documentation. I can add further comments to the code, if need be, that describe what various pieces of information mean or refer to, or I can modify the output so that everything's explained right there in the output.
Or, because this stuff is open-source, another options is to just move everything to CSV output, so that it can be opened up as a spreadsheet.
Again, because this is open-source, another option that can be added to the output is to add the offset within the MFT where the entry is found...that's not really necessary, as that offset can be easily computed from the file count, and that may even be intuitively obvious to folks who understand the format of the MFT (and as such may not be necessary for the output).
Now, back to the image. The "0x0010" attribute is the $STANDARD_INFORMATION attribute, and the "0x0030" attribute is the $FILE_NAME attribute. Note the differences in the time stamps. Yet another option available...again, because this is open-source code...is to convert the output, or just the $FILE_NAME attribute information, to the five-field TLN format.
So, one way to approach the issue of analysis is to say, hey, I paid for this GUI application and it should include X, Y, and Z in the output. As you can imagine, after a while, you're going to have one crowded UI, or you're going to have so many layers that you're going to loose track of where everything is located, or how to access it. Another way to approach your analysis is to start with your goals, and go from there...identify what you need, and go get it. Does this mean that you have to be a programmer? Not at all. It just means that you have to have a personal or professional network of friends in the industry...a network that you contribute to and can go to get information, etc.
Earlier this week, I spent an entire day talking with a great group of folks on the other side of the country...a whole day dedicated to just talking about forensics! Some of what we talked about was malware (specifically, 'bot) related, and as part of that, we (of course) talked about some of the issues related to malware characteristics and timeline analysis. One of the aspects that ties all of these topics together is timestomping...when some malware gets installed, the file times (more appropriately, the $STANDARD_INFORMATION attributes within the MFT) are purposely modified. MS provides open APIs (GetFileTime/SetFileTime) that allow for this, and in some cases, the file times for the malware are copied from a legitimate system file.
So, tying this back to "skillz"...in my previous post, I'd mentioned modifying my own code to extract the information I wanted from the MFT. Interestingly, Eric's post addressed the issue of having the information available, and I tend to agree with the first comment to his post...too many times, some GUI analysis tools get over-crowded and there's just too much stuff around to really make sense of things. Rather than having a commercial analysis app into which I can load an image and have it tell me everything that's wrong, I tend to rely on the goals for the analysis that I work out with the customer...even if it means that I would use separate tools. I don't always need information from the MFT...but sometimes I might. So do I want to pay for a commercial application that's going to attempt to keep up with all of the possible wrong stuff that's out there, or can I use a core set of open-source tools that allow me to get the information I need, when I need it, because I know what I'm looking for?
So, what does the output of my code look like? Check out the image...does this make sense to folks? How about to folks familiar with the MFT? Sure, it makes sense to me...and because the code is open source, I can open the Perl script in an editor or Notepad and see what some of the information means.
For example, on the first line, we see:132315 FILE 2 1 0x38 4 1
What does that mean? The first number is the count, or number of the MFT record. The word "FILE" is the signature...the other possible entry is "BAAD". The number "2" is the sequence number, and the "1" is the link count. Where did I get this? From the code, and it's documentation. I can add further comments to the code, if need be, that describe what various pieces of information mean or refer to, or I can modify the output so that everything's explained right there in the output.
Or, because this stuff is open-source, another options is to just move everything to CSV output, so that it can be opened up as a spreadsheet.
Again, because this is open-source, another option that can be added to the output is to add the offset within the MFT where the entry is found...that's not really necessary, as that offset can be easily computed from the file count, and that may even be intuitively obvious to folks who understand the format of the MFT (and as such may not be necessary for the output).
Now, back to the image. The "0x0010" attribute is the $STANDARD_INFORMATION attribute, and the "0x0030" attribute is the $FILE_NAME attribute. Note the differences in the time stamps. Yet another option available...again, because this is open-source code...is to convert the output, or just the $FILE_NAME attribute information, to the five-field TLN format.
So, one way to approach the issue of analysis is to say, hey, I paid for this GUI application and it should include X, Y, and Z in the output. As you can imagine, after a while, you're going to have one crowded UI, or you're going to have so many layers that you're going to loose track of where everything is located, or how to access it. Another way to approach your analysis is to start with your goals, and go from there...identify what you need, and go get it. Does this mean that you have to be a programmer? Not at all. It just means that you have to have a personal or professional network of friends in the industry...a network that you contribute to and can go to get information, etc.
Monday, June 28, 2010
Skillz
Remember that scene from Napoleon Dynamite where he talks about having "skillz"? Well, analysts have to have skillz, right?I was working on a malware exam recently...samples had already been provided to another analyst for reverse engineering, and it was my job to analyze acquired images and answer a couple of questions. We knew the name of the malware, and when I was reviewing information about it at various sites (to prepare my analysis plan), I found that when the malware files are installed, their MAC times are copied from kernel32.dll. Okay, no problem, right? I'll just parse the MFT and get the time stamps from the $FILE_NAME attribute.
So I received the images and began my case in-processing. I then got to the point where I extracted the MFT from the image, and the first thing I did was run David Kovar's analyzemft.py against it. I got concerned after I ran it for over an hour, and all I got was a 9Kb file. I hit Ctrl-C in the command prompt and killed the process. I then ran Mark Menz's MFTRipperBE against the file and when I opened the output .csv file and ran a search for the file name, Excel told me that it couldn't find the string. I even tried opening the .csv file in an editor and ran the same search, with the same results. Nada.
Fortunately, as part of my in-processing, I had verified the file structure with FTK Imager, and then created a ProDiscover v6.5 project and navigated to the appropriate directory. From there, I could select the file within the Content View of the project and see the $FILE_NAME attribute times in the viewer.
I was a bit curious about the issue I'd had with the first two tools, so I ran my Perl code for parsing the MFT and found an issue with part of the processing. I don't know if this is the same issue that analyzemft.py encountered, but I made a couple of quick adjustments to my Perl script, and I was able to fairly quickly get the information I needed. I can see that the file has $STANDARD_INFORMATION and $FILE_NAME attributes, as well as as data attribute, that the file is allocated (from the flags), and that the MFT sequence number is 2. Pretty cool.
The points of this post are:
1. If you run a tool and do not find the output that you expect, there's likely a reason for it. Validate your findings with other tools or processes, and document what you do. I've said (and written in my books) that the absence of an artifact where you would expect to find one is itself an artifact.
2. Analysts need to have an understanding of what they're looking at and for, as well as some troubleshooting skills, particularly when it comes to running tools. Note that I did not say "programming" skills. Not everyone can, or wants to, program. However, if you don't have the skills, develop relationships with folks who do. But if you're going to ask someone for help, you need to be able to provide enough information that they can help you.
3. Have multiple tools available to validate your findings, should you need to do so. I ran three tools to get the same piece of information, of which I had documented the need in my analysis plan prior to receiving the data. One tool hung, another completed without providing the information, and I was able to get what I needed from the third, and then validate it with a fourth. And to be honest, it didn't take me days to accomplish that.
4. The GUI tool that provided the information doesn't differentiate between "MFT Entry Modified" and "File Modified"...I just have two time stamps from the $FILE_NAME attribute called "Modified". So I tweaked my own code to print out the time stamps in MACB format, along with the offset of the MFT entry within the MFT itself. Now, everything I need is documented, so if need be, it can be validated by others.
Tuesday, June 22, 2010
Links and what not
Case Notes
Chris posted on writing and maintaining case notes a bit ago, using Case Notes. One of the things that is sorely overlooked many times is note taking and documenting what you're doing during an examination.
This is perhaps one of the most overlooked aspects of what we (IR/DF folks) do...or perhaps more appropriately, need to be doing. Many times, so little of what we do is documented, and it needs to be, for a number of reasons. One that's mentioned many times is, how are you going to remember the details of what you did 6 months later? Which tool version did you use? Not to pick on EnCase, but have you been to the user forum? Spend a little time there and you'll see why the version of the tool makes a difference.
Another aspect that few really talk about is process improvement...how do you improve upon something if you're not documenting it? As forensics nerds, we really don't think about it too much, but there are a lot of folks out there who have processes and procedures...EMTs, for example. Let's say you're helping someone with some analysis, and you've worked out an analysis plan with them. Now, let's say that they didn't follow it...they told you that...but they can't remember what it was they did do. How do you validate the results? How can you tell that what they did was correct or sufficient?
A good example is when a customer suspects that they have malware on a system, and all you have to work with is an acquired image. How do you go about finding "the bad stuff"? Well, one way is to mount the image read-only and scan it with AV. Oh, but wait...did you check to see which AV, if any, was already installed on the system? Might not be a good idea to run that, because apparently it didn't work in the first place. So what do/did you run? Which version? When was it updated? What else did you do? You will not ever reach 100% certainty, but with a documented process you can get close.
When you document what you do, one of the side effects is that you can improve upon that process. Hey, two months ago, here's what I did...that was the last time that I had a malware case. Okay, great...what've I learned...or better yet, what have other folks learned since then, and how can we improve this process? Another nice side effect is that if you document what you did, the report (another part of documentation that we all hate...) almost writes itself.
In short, if you didn't document what you did...it didn't happen.
Raw2vmdk
Raw2vmdk is a Java-based, platform independent tool for mounting raw images as VMWare vmdk disks. This is similar to LiveView, and in fact, raw2vmdk reportedly uses some of the same Java classes as LiveView. However, raw2vmdk is a command line tool; thanks for JD for taking the time to try it out and describe it in a blog post.
MFT $FILE_NAME Attributes
Eric posted to the Fistful of Dongles blog, asking about tools that can be used to extract/retrieve $FILE_NAME attributes from the MFT. I mentioned two tools in my comment that have been around and available for some time, and another commenter mentioned the use of EnScripts.
Tool Updates
Autoruns was updated on 15 June; perhaps the most notable update is the -z switch, which specifies an offline Windows system to scan. I really like Autoruns (and it's CLI companion, autorunsc.exe), as it does a great job of going through and collecting information about entries in startup locations, particularly the Registry. The drawback of the tool is that there isn't much of an explanation as to why some areas are queried, leaving it up to the investigator to figure it out. This is pretty unfortunate, given the amount of expertise that goes into developing and maintaining a valuable tool like this, and usually means that a great deal of the information that the tool collects is simply overlooked.
If you're interested in USB device histories on your system, check out usbhistory.exe. The web page provides a very good explanation of how the tool works and were it goes to get it's information. Overall, if this is information that you're interested in, this would be a very good tool to add to a batch file that collects information from a live system.
USB Devices
Speaking of USB device history, there's a topic I keep seeing time and time again in the lists that has to do with when a USB device had last been connected to a system. In almost all cases, the question that is posed indicates that there has been some issue determining when devices had been attached, as the subkeys beneath the Enum\USBStor key all have the same LastWrite times.
While there is clearly some process that is modifying these subkeys so that the LastWrite times are updated, these are not the keys we're interested in when it comes to determining when the devices were last attached to the system. I addressed this in WFA 2/e, starting on pg 209, and Rob Lee has covered it in his guides for profiling USB devices on various versions of Windows.
Chris posted on writing and maintaining case notes a bit ago, using Case Notes. One of the things that is sorely overlooked many times is note taking and documenting what you're doing during an examination.
This is perhaps one of the most overlooked aspects of what we (IR/DF folks) do...or perhaps more appropriately, need to be doing. Many times, so little of what we do is documented, and it needs to be, for a number of reasons. One that's mentioned many times is, how are you going to remember the details of what you did 6 months later? Which tool version did you use? Not to pick on EnCase, but have you been to the user forum? Spend a little time there and you'll see why the version of the tool makes a difference.
Another aspect that few really talk about is process improvement...how do you improve upon something if you're not documenting it? As forensics nerds, we really don't think about it too much, but there are a lot of folks out there who have processes and procedures...EMTs, for example. Let's say you're helping someone with some analysis, and you've worked out an analysis plan with them. Now, let's say that they didn't follow it...they told you that...but they can't remember what it was they did do. How do you validate the results? How can you tell that what they did was correct or sufficient?
A good example is when a customer suspects that they have malware on a system, and all you have to work with is an acquired image. How do you go about finding "the bad stuff"? Well, one way is to mount the image read-only and scan it with AV. Oh, but wait...did you check to see which AV, if any, was already installed on the system? Might not be a good idea to run that, because apparently it didn't work in the first place. So what do/did you run? Which version? When was it updated? What else did you do? You will not ever reach 100% certainty, but with a documented process you can get close.
When you document what you do, one of the side effects is that you can improve upon that process. Hey, two months ago, here's what I did...that was the last time that I had a malware case. Okay, great...what've I learned...or better yet, what have other folks learned since then, and how can we improve this process? Another nice side effect is that if you document what you did, the report (another part of documentation that we all hate...) almost writes itself.
In short, if you didn't document what you did...it didn't happen.
Raw2vmdk
Raw2vmdk is a Java-based, platform independent tool for mounting raw images as VMWare vmdk disks. This is similar to LiveView, and in fact, raw2vmdk reportedly uses some of the same Java classes as LiveView. However, raw2vmdk is a command line tool; thanks for JD for taking the time to try it out and describe it in a blog post.
MFT $FILE_NAME Attributes
Eric posted to the Fistful of Dongles blog, asking about tools that can be used to extract/retrieve $FILE_NAME attributes from the MFT. I mentioned two tools in my comment that have been around and available for some time, and another commenter mentioned the use of EnScripts.
Tool Updates
Autoruns was updated on 15 June; perhaps the most notable update is the -z switch, which specifies an offline Windows system to scan. I really like Autoruns (and it's CLI companion, autorunsc.exe), as it does a great job of going through and collecting information about entries in startup locations, particularly the Registry. The drawback of the tool is that there isn't much of an explanation as to why some areas are queried, leaving it up to the investigator to figure it out. This is pretty unfortunate, given the amount of expertise that goes into developing and maintaining a valuable tool like this, and usually means that a great deal of the information that the tool collects is simply overlooked.
If you're interested in USB device histories on your system, check out usbhistory.exe. The web page provides a very good explanation of how the tool works and were it goes to get it's information. Overall, if this is information that you're interested in, this would be a very good tool to add to a batch file that collects information from a live system.
USB Devices
Speaking of USB device history, there's a topic I keep seeing time and time again in the lists that has to do with when a USB device had last been connected to a system. In almost all cases, the question that is posed indicates that there has been some issue determining when devices had been attached, as the subkeys beneath the Enum\USBStor key all have the same LastWrite times.
While there is clearly some process that is modifying these subkeys so that the LastWrite times are updated, these are not the keys we're interested in when it comes to determining when the devices were last attached to the system. I addressed this in WFA 2/e, starting on pg 209, and Rob Lee has covered it in his guides for profiling USB devices on various versions of Windows.
Sunday, June 20, 2010
Who's on...uh, at...FIRST?
I attended the FIRST conference in Miami last week. My employer is not a member of FIRST, but we were a sponsor, and we hosted the "Geek Bar"...a nice room with two Wiis set up, a smoothie bar (also with coffee and tea), and places to sit and relax. One of my roles at the conference was to be at the Geek Bar to answer questions and help sign folks up for the NAP tour on Thursday, as well as mingle with folks at the conference. As such, I did not get to attend all of the presentations...some were going on during my shift at the Geek Bar, for example.
Note: Comments made in this blog are my own thoughts and opinions, and do not necessarily reflect or speak for my employer.
Dave Aitel's presentation hit the nail on the head...defenders are behind and continue to learn from the attacker. Okay, not all defenders learn from the attacker...some do, others, well, not so much. Besides Dave's really cool presentation, I think that what he said was as important as what he didn't say. I mean, Dave was really kind of cheerful for what, on the surface, could be a "doom-and-gloom" message, but someone mentioned after the presentation that Dave did not provide a roadmap to fixing/correcting the situation. I'd suggest that the same things that have been said for the past 25 years, the same core principles still apply...they simply need to be used. My big take-away from this presentation was that we cannot say that defensive tactics, or the tactics, techniques, and strategies used by the defenders have failed, because in most cases, they haven't been implemented properly, or at all.
I really liked Heather Adkins' presentation regarding Aurora and Google, and I think that overall it was very well received. It was clear that she couldn't provide every bit of information associated with the incident, and I think she did a great job of heading off some questions by pointing out what was already out there publicly and could be easily searched for...via Google.
Vitaly Kamluk's (Kaspersky/Japan) presentation on botnets reiterated Dave's presentation a bit, albeit not in so many words. Essentially, part of the presentation was spent talking about the evolution of botnet infrastructures, going through one-to-many, many-to-one, C2, P2P, and a C2/P2P hybrid.
Unfortunately, I missed Steven Adair's presentation, something I wanted to see. However, I flew to Miami on the same flight as Steven, one row behind and to the side of his seat, so I got to see a lot of the presentation development in action! I mean, really...young guy opens up Wireshark on one of two laptops he's got open...who wouldn't watch?
Jason Larsen (researcher from Idaho National Labs) a good talk on Home Area Networks (HANs). He mentioned that he'd found a way to modify firmware on power meters to do such things as turn on the cellular networking of some of these devices. Imagine the havok that would insue if home power meters suddenly all started transmitting on cellular network frequencies. How about if the transmitting were on emergency services frequencies?
The Mandiant crew was in the hizz-ouse, and I saw Kris Harms at the mic not once, but twice! Once for the Mandiant webcast, and once for the presentation on Friday. I noticed that some parts of both of Mandiant's presentations were from previous presentations...talking to Kris, they were still seeing similar techniques, even as long as two years later. I didn't get a chance to discuss this with Kris much more, to dig into things like, were customers against which these techniques used detecting the incident, or was the call to Mandiant the result of an external third party calling the victim organization?
Richard Bejtlich took a different approach to his presentation...no PPT! If you're read his blog, you know that he's been talking about this recently, so I wasn't too terribly surprised (actually, I was very interested to see where it would go) when he started his time at the mic by asking members of the audience for questions. He'd had a handout prior to kicking things off, and his presentation was very interesting because of how he spent the time.
There were also a number of presentations on cloud computing, including one by our own Robert Rounsavall, and another on Fri morning by Chris Day. It's interesting to see some folks get up and talk about "cloud computing" and how security, IR, and forensics need to be addressed, and then for others to get up and basically say, "hey, we have it figured out."
Take Aways from FIRST
My take aways from FIRST came from two sources...listening to and thinking about the presentations, and talking to other attendees about their thoughts on what they heard.
As Dave Aitel said, defenders are steps behind the attackers, and continue to learn from them. Kris Harms said that from what they've seen at Mandiant, considerable research is being placed into malware persistence mechanisms...but when talking about these to some attendees, particularly those involved in incident response in some way within their organizations, there were a lot of blank stares. A lot of what was said by some was affirmed by others, and in turn, affirmed my experiences as well as those of other responders.
I guess the biggest take away is that there are two different focuses with respect to business. Organizations conducting business most often focus on business and not so much on securing the information that is their business. The bad guys have a business model, as well, that is also driven by revenue...they are out to get your information, or access to your systems, and they are often better at using your infrastructure than you are. The drive or motivation of business is to do business, and at this point, security is such a culture change that its no wonder that victims find out about so many intrusions and data breaches after the fact, due to third party notification. The road map, the solutions, to addressing this have been around for a very long time, and nothing will change until organizations start adopting those security principles as part of their culture. Security is ineffective if it's "bolted on"...it has to be part of what businesses do...just like billing and collections, shipping and product fulfillment, etc. Incident responders have watched the evolution of intruder's tactics over the years, and organizations that fall victim to these attacks are often stagnant and rooted in archaic cultures.
Overall, FIRST was a good experience, and a good chance to hear what others were experiencing and thinking, both in and out of the presentation forum.
Note: Comments made in this blog are my own thoughts and opinions, and do not necessarily reflect or speak for my employer.
Dave Aitel's presentation hit the nail on the head...defenders are behind and continue to learn from the attacker. Okay, not all defenders learn from the attacker...some do, others, well, not so much. Besides Dave's really cool presentation, I think that what he said was as important as what he didn't say. I mean, Dave was really kind of cheerful for what, on the surface, could be a "doom-and-gloom" message, but someone mentioned after the presentation that Dave did not provide a roadmap to fixing/correcting the situation. I'd suggest that the same things that have been said for the past 25 years, the same core principles still apply...they simply need to be used. My big take-away from this presentation was that we cannot say that defensive tactics, or the tactics, techniques, and strategies used by the defenders have failed, because in most cases, they haven't been implemented properly, or at all.
I really liked Heather Adkins' presentation regarding Aurora and Google, and I think that overall it was very well received. It was clear that she couldn't provide every bit of information associated with the incident, and I think she did a great job of heading off some questions by pointing out what was already out there publicly and could be easily searched for...via Google.
Vitaly Kamluk's (Kaspersky/Japan) presentation on botnets reiterated Dave's presentation a bit, albeit not in so many words. Essentially, part of the presentation was spent talking about the evolution of botnet infrastructures, going through one-to-many, many-to-one, C2, P2P, and a C2/P2P hybrid.
Unfortunately, I missed Steven Adair's presentation, something I wanted to see. However, I flew to Miami on the same flight as Steven, one row behind and to the side of his seat, so I got to see a lot of the presentation development in action! I mean, really...young guy opens up Wireshark on one of two laptops he's got open...who wouldn't watch?
Jason Larsen (researcher from Idaho National Labs) a good talk on Home Area Networks (HANs). He mentioned that he'd found a way to modify firmware on power meters to do such things as turn on the cellular networking of some of these devices. Imagine the havok that would insue if home power meters suddenly all started transmitting on cellular network frequencies. How about if the transmitting were on emergency services frequencies?
The Mandiant crew was in the hizz-ouse, and I saw Kris Harms at the mic not once, but twice! Once for the Mandiant webcast, and once for the presentation on Friday. I noticed that some parts of both of Mandiant's presentations were from previous presentations...talking to Kris, they were still seeing similar techniques, even as long as two years later. I didn't get a chance to discuss this with Kris much more, to dig into things like, were customers against which these techniques used detecting the incident, or was the call to Mandiant the result of an external third party calling the victim organization?
Richard Bejtlich took a different approach to his presentation...no PPT! If you're read his blog, you know that he's been talking about this recently, so I wasn't too terribly surprised (actually, I was very interested to see where it would go) when he started his time at the mic by asking members of the audience for questions. He'd had a handout prior to kicking things off, and his presentation was very interesting because of how he spent the time.
There were also a number of presentations on cloud computing, including one by our own Robert Rounsavall, and another on Fri morning by Chris Day. It's interesting to see some folks get up and talk about "cloud computing" and how security, IR, and forensics need to be addressed, and then for others to get up and basically say, "hey, we have it figured out."
Take Aways from FIRST
My take aways from FIRST came from two sources...listening to and thinking about the presentations, and talking to other attendees about their thoughts on what they heard.
As Dave Aitel said, defenders are steps behind the attackers, and continue to learn from them. Kris Harms said that from what they've seen at Mandiant, considerable research is being placed into malware persistence mechanisms...but when talking about these to some attendees, particularly those involved in incident response in some way within their organizations, there were a lot of blank stares. A lot of what was said by some was affirmed by others, and in turn, affirmed my experiences as well as those of other responders.
I guess the biggest take away is that there are two different focuses with respect to business. Organizations conducting business most often focus on business and not so much on securing the information that is their business. The bad guys have a business model, as well, that is also driven by revenue...they are out to get your information, or access to your systems, and they are often better at using your infrastructure than you are. The drive or motivation of business is to do business, and at this point, security is such a culture change that its no wonder that victims find out about so many intrusions and data breaches after the fact, due to third party notification. The road map, the solutions, to addressing this have been around for a very long time, and nothing will change until organizations start adopting those security principles as part of their culture. Security is ineffective if it's "bolted on"...it has to be part of what businesses do...just like billing and collections, shipping and product fulfillment, etc. Incident responders have watched the evolution of intruder's tactics over the years, and organizations that fall victim to these attacks are often stagnant and rooted in archaic cultures.
Overall, FIRST was a good experience, and a good chance to hear what others were experiencing and thinking, both in and out of the presentation forum.
Thursday, June 10, 2010
Linkz
Analysis
This post from the Digital Detective site discusses how to manually identify the time zone of a system from the image. This information is maintained in the Registry, and RegRipper has a plugin for this (as part of the default distro).
Plugins
I saw this post recently on the SANS ISC blog, which has to do with software restriction policies on a system. I thought...hey, that's pretty cool, AND there's a Registry key listed. From there it was a simple matter to research the MS site and see what other information I could find, and I began to see the possible value of the data derived from the DefaultLevel value (called a "key" in the blog post) to an analyst. In a matter of minutes, I had a functioning RegRipper plugin.
Interestingly enough, the more I research this, the more I see the CodeIdentifiers key being of some level of importance, not only to forensic analysts, but also to system administrators. After all, if it weren't, why would so many bits of malware be modifying or deleting entries beneath this key?
This post from the Digital Detective site discusses how to manually identify the time zone of a system from the image. This information is maintained in the Registry, and RegRipper has a plugin for this (as part of the default distro).
Plugins
I saw this post recently on the SANS ISC blog, which has to do with software restriction policies on a system. I thought...hey, that's pretty cool, AND there's a Registry key listed. From there it was a simple matter to research the MS site and see what other information I could find, and I began to see the possible value of the data derived from the DefaultLevel value (called a "key" in the blog post) to an analyst. In a matter of minutes, I had a functioning RegRipper plugin.
Interestingly enough, the more I research this, the more I see the CodeIdentifiers key being of some level of importance, not only to forensic analysts, but also to system administrators. After all, if it weren't, why would so many bits of malware be modifying or deleting entries beneath this key?
TSK/Open Source Conference
I have to say, when someone who's attended conferences sets out to create a conference, things tend to turn out pretty well. Aaron's OMFW (2008) turned out that way, and Brian's Open Source conference (9 June) was another excellent example.There were seven presentations, all of high caliber (well, six of high caliber, and mine! ;-) ) and two time-slots for open discussion. I like the shorter talks (unless there's some kind of hands-on component), but that also requires the presenters to develop their presentations to meet the time constraint. For example, Cory had some great stuff (I know, because I was sitting next to him during earlier presentations when he developed it!) in his presentation, but had to skip over portions due to time.
Rather than walking through each presentation individually, I wanted to cover the highlights of the conference as a whole. In that regard, there were a couple of points that were brought up with respect to open source overall:
Tool Interoperability - Open source tools need to be able to interoperate better. During my presentation, I mentioned several times that due to the output provided by some tools and the format that I need, I use Perl as the "glue". Maybe there's a better way to do this.
Tool Storehouse - There are a number of open source (and free) tools out there that are very useful and very powerful...but they're out there and not accessible from a single location. It's difficult to keep up with so many things in forensics and IR, following blogs and lists...it can be too much. Having a centralized location where someone can go and search for information, kind of like an encyclopedia, would be more beneficial...maybe something like the Forensics Wiki.
Talking to a number of the other folks attending the conference, it was clear that everyone was at a different level. Some folks develop tools, other use and modify that tools, still others use the tools and submit bug reports or feature requests, and other simply use the tools. One of the benefits of these conferences is that all of these folks can meet, share thoughts and opinions, and discuss the direction of either individual tools, or open source in general. Some folks are very comfortable sharing ideas with a larger audience, and others do so on a more individual basis...conferences like this provide an environment conducive to both.
I think one of the biggest things to come out of the conference is that open source tools come from a range of different areas. Some come from academic research projects, others start as a need that one person has. Regardless of where they come from, they require work...a lot of work. Take memory acquisition and analysis...lots of folks have put a lot of effort into developing what's currently available, and if anyone feels that what's available right now isn't sufficient, then support the work that being done. I think AW covered that very well; the best way to get your needs met is to communicate them, and then support those who are doing the work. Learn to code. Don't code? Can you write documentation? How else can you provide support? Loaning hardware? Providing samples for analysis? There's a great deal that can be done. We all have to remember that for most of this, the work is hard, such as providing a layer of abstraction for a very technical and highly fluid area of analysis (i.e., memory) or providing an easily accessible library for something else. It's hard work, and very often done on someone's own time, using their own resources. I completely agree with AW...folks that do those things should get recognition for their good works. As such, organizations (and individuals) that rely heavily on open source (and free) tools for their work should be offering some kind of support back to the developer, particularly if they want some additional capabilities.
On the organizational side of things...rather than operational...it's always good to see a conference where some of the things that you don't like about conferences are improved upon. For example, the attendee's badge wallet had the complete schedule listed on a small card right there in the back of the wallet. That way, you weren't always looking around for the schedule. Also, there were plenty of snacks, although I haven't yet been to an event like this where the coffee was any good. ;-(
Overall, this was a great conference, with lots of great information shared. One of the best things about conferences is that they bring folks together...folks that may "know" each other on the Internet or via email, but haven't actually met, or haven't seen each other in a while. Great content generates some great conversations, and the folks that share end up sharing some great ideas. I'm really hoping to get an invite to the next one...which means I should keep working with open source tools and "going commando"...
Monday, June 07, 2010
Anti-forensics
The term "anti-forensics" is used sometimes to describe efforts attackers use in order to foil or frustrate the attempts of the good guys to discover what happened, when it happened, and how it happened. Many times, what comes to mind when someone uses the term "anti-forensics" are things like steganography, rootkits, and timestomp.
Richard Bejtlich went so far as to make a distinction between the terms "anti-forensics" and "counterforensics". On Wikipedia, the term "anti-computer forensics" is used to refer tocountermeasures against forensic analysis, while "counterforensics" refers to attacks directed against forensic tools. For additional clarification on the terms, see W. Matthew Hartley's paper on the topic here; the paper is three pages long, and makes a clear distinction between the two terms.
In short, from Hartley's paper, anti-forensics refers to techniques and technologies that "invalidate factual information for judicial review", whereas counterforensics refers to tools and techniques that "target...specific forensic technologies to directly prevent the investigator from analyzing collected evidence". Hartley's paper gives some very good examples to illustrate the differences between these two terms, so I strongly suggest reading the three pages.
Very often, we use these terms (in some manner) to describe what an attacker or intruder may do, but one thing that's not discussed often is how this applies to responder's actions, or inaction, as the case may be. In that regard, there are a couple of things that organizations and responders need to keep in mind:
1. You can not just grab the disk and expect to get what you need. Live response, including memory acquisition, is becoming more and more important, particularly in the face of questions brought on by legislative and regulatory compliance. Too many times, a response team (consultants, not on-site staff) will be called in and during the course of response, but provided with goals. Then, after the fact, the victim organization will start with questions such as, "...was data exfiltrated?" and "...how much data was exfiltrated?" Fortunately, consulting responders have faced these questions often enough that they can often head them off at the pass, but what do you do when the victim organization has already taken systems offline before calling for help? Would it have been beneficial to the overall response if they'd captured memory, and perhaps some volatile data, first?
2. Temporal Proximity - lots of stuff happens on Windows systems, particularly since Windows XP was released, that have an antiforensics effect...and much of it happens without any interaction from a user or administrator. Let's say that a bad guy gets into a system, uploads a couple of tools, runs them, copies data off of the system, then deletes everything and leaves. While the system is just sitting there, there are limited defrags going on, System Restore Points and Volume Shadow Copies are being created and removed, operating system and application updates are being installed, etc. It won't be long before, due to a lack of responsiveness, all you're left with is an entry in an index file pointing to a file name. Once that happens, and you're unable to determine how many records were exposed, you will very likely have to report and notify on ALL records. Ouch!
The point is that intruders very often don't have to use any fancy or sophisticated techniques to remain undetected on a system or within a network infrastructure. What tends to happen is that responders and analysts may have only so much time (8 hrs, 16 hrs, etc.) to spend on investigating the incident, so as long as the intruder uses a technique that takes just a bit longer than that to investigate, they're good. There's no real need to use counter- or anti-forensics techniques. Very often, though, it's not so much the actions of the intruder, but the inaction of the closest responders that have the greatest impact on an investigation.
Thoughts?
Resources
Anti-forensics.com
Antiforensics.net
ForensicsWiki: Anti-forensics
Adrien's Occult Computing presentation
CSOOnline article: The Rise of Anti-Forensics
Lance Mueller: Detecting Timestamp Changing Utilities
Richard Bejtlich went so far as to make a distinction between the terms "anti-forensics" and "counterforensics". On Wikipedia, the term "anti-computer forensics" is used to refer tocountermeasures against forensic analysis, while "counterforensics" refers to attacks directed against forensic tools. For additional clarification on the terms, see W. Matthew Hartley's paper on the topic here; the paper is three pages long, and makes a clear distinction between the two terms.
In short, from Hartley's paper, anti-forensics refers to techniques and technologies that "invalidate factual information for judicial review", whereas counterforensics refers to tools and techniques that "target...specific forensic technologies to directly prevent the investigator from analyzing collected evidence". Hartley's paper gives some very good examples to illustrate the differences between these two terms, so I strongly suggest reading the three pages.
Very often, we use these terms (in some manner) to describe what an attacker or intruder may do, but one thing that's not discussed often is how this applies to responder's actions, or inaction, as the case may be. In that regard, there are a couple of things that organizations and responders need to keep in mind:
1. You can not just grab the disk and expect to get what you need. Live response, including memory acquisition, is becoming more and more important, particularly in the face of questions brought on by legislative and regulatory compliance. Too many times, a response team (consultants, not on-site staff) will be called in and during the course of response, but provided with goals. Then, after the fact, the victim organization will start with questions such as, "...was data exfiltrated?" and "...how much data was exfiltrated?" Fortunately, consulting responders have faced these questions often enough that they can often head them off at the pass, but what do you do when the victim organization has already taken systems offline before calling for help? Would it have been beneficial to the overall response if they'd captured memory, and perhaps some volatile data, first?
2. Temporal Proximity - lots of stuff happens on Windows systems, particularly since Windows XP was released, that have an antiforensics effect...and much of it happens without any interaction from a user or administrator. Let's say that a bad guy gets into a system, uploads a couple of tools, runs them, copies data off of the system, then deletes everything and leaves. While the system is just sitting there, there are limited defrags going on, System Restore Points and Volume Shadow Copies are being created and removed, operating system and application updates are being installed, etc. It won't be long before, due to a lack of responsiveness, all you're left with is an entry in an index file pointing to a file name. Once that happens, and you're unable to determine how many records were exposed, you will very likely have to report and notify on ALL records. Ouch!
The point is that intruders very often don't have to use any fancy or sophisticated techniques to remain undetected on a system or within a network infrastructure. What tends to happen is that responders and analysts may have only so much time (8 hrs, 16 hrs, etc.) to spend on investigating the incident, so as long as the intruder uses a technique that takes just a bit longer than that to investigate, they're good. There's no real need to use counter- or anti-forensics techniques. Very often, though, it's not so much the actions of the intruder, but the inaction of the closest responders that have the greatest impact on an investigation.
Thoughts?
Resources
Anti-forensics.com
Antiforensics.net
ForensicsWiki: Anti-forensics
Adrien's Occult Computing presentation
CSOOnline article: The Rise of Anti-Forensics
Lance Mueller: Detecting Timestamp Changing Utilities
Thursday, June 03, 2010
Book Review
I recently had an opportunity to read through Handbook of Digital Forensics and Investigation (ISBN-10: 0123742676), edited by Eoghan Casey.
One of the first things you notice about the book...aside from the heft and sense that you actually have something in your hands...is the fact that the book actually has 16 authors listed! 16! Many of the names listed are very prominent in the field of digital forensics, so one can only imagine the chore of not only keeping everyone on schedule, but getting the book into an overall flow.
Something I really like about the Handbook is that it starts off with basic, core principles. Digital forensics is one of those areas where folks usually want to dive right into the cool stuff (imaging systems, finding "evidence", running tools, etc.), but as with other similar areas, you're only going to get so far that way. These core principles are presented in an easy-to-understand manner, with little sidebars that illustrate or reinforce various points. Many of these principles are topics that are misunderstood, or talked about but not practiced in the wider community, and having luminaries such as Eoghan and Curtis and others present them in this sort of format brings them home again.
Some of those sidebars I mentioned, in my copy of the Handbook, are heavily highlighted, and the book itself has a number of notes in the margins of several chapters. One of the highlighted gems is in a "Practitioner's Tip" sidebar on page 23, where it says, "...apply the scientific method, seek peer review...". This one struck home, because too often in the community we see where statements are made that are assumptions, not based on supporting fact. IMHO, I think that is is a result of not seeking peer review, not engaging with others, and not having someone who's able to ask the simple question, "why?"
Another aspect of the Handbook that I found very useful was that when a technique or something specific about some data was discussed, several times, there were illustrations using not just commercial forensic analysis applications, but also free and open-source tools. For example, page 55 has an illustration of the use of the SQLite command line utility to examine the contents of the Skype main.db database file. My sense is that the overall approach to the Handbook is to move practitioners away from over reliance on a specific commercial application, and toward an understanding that hey, there are other riches to be discovered if you disconnect the dongle and think for a minute.
I'll admit that I didn't spend as much time on some chapters as I did on others. Chapters 1 and 2 were very interesting for me, but chapter 3 got into electronic discovery. While this really isn't something I do a lot of, parts of the chapter (prioritizing systems, processing data from tapes, etc.) caught my eye. The pace picked back up again with chapter 4, Intrusion Investigation, particularly where there was discussion of "fact versus speculation" and "Reporting Audiences". In my experience, these are just two of the areas where any investigation can easily veer off course. Of course, without question, I spent a great deal of time in chapter 5, Windows Forensic Analysis! However, that doesn't mean that the other chapters don't have a great deal of valuable information.
The real value of the Handbook is that it did not focus on any one platform, or on any one commercial product. Analysis of Windows, as well as *nix/Linux, Mac, and embedded systems are addressed, as was the network (including mobile networks). There was no singular focus on one commercial product, something you see in other books; instead, a combination of commercial, free, and open-source tools were used to illustrate various points. In one instance, three commercial applications were shown side-by-side to illustrate a point about deleted files. Even some of my own tools (RegRipper, wmd.pl, etc.) were mentioned!
Overall, I think that the book is an excellent handbook, and it definitely has a prominent place on my bookshelf. No one of us knows everything there is to know, and I even found little gems in the chapter on Windows forensic analysis. For anyone who doesn't spend much time in that area, or analyzing Macs, those chapters will be a veritable goldmine...and you're very likely to find something new, even if you are very experienced in those areas. The Handbook is going to be something that I refer back to time and again, for a long time to come. Thanks to Eoghan, and thanks to all of the authors who put in the time and effort to produce this excellent work.
Resources
Richard Bejtlich's review @TaoSecurity
One of the first things you notice about the book...aside from the heft and sense that you actually have something in your hands...is the fact that the book actually has 16 authors listed! 16! Many of the names listed are very prominent in the field of digital forensics, so one can only imagine the chore of not only keeping everyone on schedule, but getting the book into an overall flow.
Something I really like about the Handbook is that it starts off with basic, core principles. Digital forensics is one of those areas where folks usually want to dive right into the cool stuff (imaging systems, finding "evidence", running tools, etc.), but as with other similar areas, you're only going to get so far that way. These core principles are presented in an easy-to-understand manner, with little sidebars that illustrate or reinforce various points. Many of these principles are topics that are misunderstood, or talked about but not practiced in the wider community, and having luminaries such as Eoghan and Curtis and others present them in this sort of format brings them home again.
Some of those sidebars I mentioned, in my copy of the Handbook, are heavily highlighted, and the book itself has a number of notes in the margins of several chapters. One of the highlighted gems is in a "Practitioner's Tip" sidebar on page 23, where it says, "...apply the scientific method, seek peer review...". This one struck home, because too often in the community we see where statements are made that are assumptions, not based on supporting fact. IMHO, I think that is is a result of not seeking peer review, not engaging with others, and not having someone who's able to ask the simple question, "why?"
Another aspect of the Handbook that I found very useful was that when a technique or something specific about some data was discussed, several times, there were illustrations using not just commercial forensic analysis applications, but also free and open-source tools. For example, page 55 has an illustration of the use of the SQLite command line utility to examine the contents of the Skype main.db database file. My sense is that the overall approach to the Handbook is to move practitioners away from over reliance on a specific commercial application, and toward an understanding that hey, there are other riches to be discovered if you disconnect the dongle and think for a minute.
I'll admit that I didn't spend as much time on some chapters as I did on others. Chapters 1 and 2 were very interesting for me, but chapter 3 got into electronic discovery. While this really isn't something I do a lot of, parts of the chapter (prioritizing systems, processing data from tapes, etc.) caught my eye. The pace picked back up again with chapter 4, Intrusion Investigation, particularly where there was discussion of "fact versus speculation" and "Reporting Audiences". In my experience, these are just two of the areas where any investigation can easily veer off course. Of course, without question, I spent a great deal of time in chapter 5, Windows Forensic Analysis! However, that doesn't mean that the other chapters don't have a great deal of valuable information.
The real value of the Handbook is that it did not focus on any one platform, or on any one commercial product. Analysis of Windows, as well as *nix/Linux, Mac, and embedded systems are addressed, as was the network (including mobile networks). There was no singular focus on one commercial product, something you see in other books; instead, a combination of commercial, free, and open-source tools were used to illustrate various points. In one instance, three commercial applications were shown side-by-side to illustrate a point about deleted files. Even some of my own tools (RegRipper, wmd.pl, etc.) were mentioned!
Overall, I think that the book is an excellent handbook, and it definitely has a prominent place on my bookshelf. No one of us knows everything there is to know, and I even found little gems in the chapter on Windows forensic analysis. For anyone who doesn't spend much time in that area, or analyzing Macs, those chapters will be a veritable goldmine...and you're very likely to find something new, even if you are very experienced in those areas. The Handbook is going to be something that I refer back to time and again, for a long time to come. Thanks to Eoghan, and thanks to all of the authors who put in the time and effort to produce this excellent work.
Resources
Richard Bejtlich's review @TaoSecurity
Stuffz
Tool Updates
Paraben recently sent out an email about an updated version of their P2eXplorer tool being available. This is the product that allows you to mount acquired images for viewing, mounting a variety of images as physical disks.
ImDisk is available for 32- and 64-bit versions of Windows, including Windows 2008. I've got an idea for trying it out on Windows 7...we'll have to see how it works.
The TSK tools are up to version 3.1.2. Be sure to update your stuff.
eZine
There's a new issue of Hakin9 magazine available...it's free now, which is kind of cool.
WindowsRipper
Matt posted about how he and Adam used RegRipper to create WindowsRipper. It's an interesting project and I have to say, I really like it when folks find ways to achieve their needs and get the tools to meet their goals, rather than the other way around. Great job, guys...I'm looking forward to seeing where this goes. Let me know what I can do to help.
WinFE
Speaking of RegRipper, it appears that RegRipper is included in WinFE! Brett Shavers set up the WinFE site (he's also the guy who set up the RegRipper site), and the list of tools includes RegRipper!
Podcasts
I was interviewed last night by the guys from the Securabit podcast (episode 58). Thanks, guys, for a great time..."hanging out" on Skype with a bunch of former sailors...truly a dream come true! ;-) I enjoy having the opportunity to talk nerdy with folks, as forensics is not just a job, it's an adventure!
Check out Chris Pogue's "Sniper Forensics" interview on the CyberJungle podcast. It's episode 141, and the hosts start mentioning SANS (as a lead-in to Chris's interview) at about 58:26 into the podcast. Chris talked about his sniper forensics, as well as the 4-step Alexiou Principle that he uses as a basis for analysis. Chris will be giving his "Sniper Forensics" presentation at the SANS Forensic Summit in July.
Paraben recently sent out an email about an updated version of their P2eXplorer tool being available. This is the product that allows you to mount acquired images for viewing, mounting a variety of images as physical disks.
ImDisk is available for 32- and 64-bit versions of Windows, including Windows 2008. I've got an idea for trying it out on Windows 7...we'll have to see how it works.
The TSK tools are up to version 3.1.2. Be sure to update your stuff.
eZine
There's a new issue of Hakin9 magazine available...it's free now, which is kind of cool.
WindowsRipper
Matt posted about how he and Adam used RegRipper to create WindowsRipper. It's an interesting project and I have to say, I really like it when folks find ways to achieve their needs and get the tools to meet their goals, rather than the other way around. Great job, guys...I'm looking forward to seeing where this goes. Let me know what I can do to help.
WinFE
Speaking of RegRipper, it appears that RegRipper is included in WinFE! Brett Shavers set up the WinFE site (he's also the guy who set up the RegRipper site), and the list of tools includes RegRipper!
Podcasts
I was interviewed last night by the guys from the Securabit podcast (episode 58). Thanks, guys, for a great time..."hanging out" on Skype with a bunch of former sailors...truly a dream come true! ;-) I enjoy having the opportunity to talk nerdy with folks, as forensics is not just a job, it's an adventure!
Check out Chris Pogue's "Sniper Forensics" interview on the CyberJungle podcast. It's episode 141, and the hosts start mentioning SANS (as a lead-in to Chris's interview) at about 58:26 into the podcast. Chris talked about his sniper forensics, as well as the 4-step Alexiou Principle that he uses as a basis for analysis. Chris will be giving his "Sniper Forensics" presentation at the SANS Forensic Summit in July.
Wednesday, June 02, 2010
Timelines
With a couple of upcoming presentations that address timelines (TSK/Open Source Conference, SANS Forensic Summit, etc.), I thought that it might be a good idea to revisit some of my thoughts and ideas behind timelines.
For me, timeline analysis as a very powerful tool, something that can be (and has been) used to great effect, if it makes sense to do so. Not all of us are always going to have investigations that are going to benefit from a timeline analysis, but for those cases where a timeline would be beneficial, they have proven to be an extremely valuable analysis step. However, creating a timeline isn't necessarily a point-and-click proposition.
I find creating the timelines to be extremely easy, based on the tools I've provided (in the Files section of the Win4n6 Yahoo group). For my uses, I prefer the modular nature of the tools, in part because I don't always have everything I'd like to have available to me. In instances where I'm doing some IR or triage work, I may only have selected files and a directory listing available, rather than access to a complete image. Or sometimes, I use the tools to create micro- or nano-timelines, using just the Event Logs, or just the Security Event Log...or even just specific event IDs from the Security Event Log. Having the raw data available and NOT being hemmed in by a commercial forensic analysis application means that I can use the tools to meet the goals of my analysis, not the other way around. See how that works? The goals of the analysis define what I look for, what I look at, and what tools I use...not the tool. The tool is just that...a tool. The tools I've provided are flexible enough to be able to be used to create a full timeline, or to create these smaller versions of timelines, which also serve a very important role in analysis.
As an example, evtparse.pl parses an Event Log (.evt, NOT .evtx) file (or all .evt files in a given directory) into the five-field TLN format I like to use. Evtparse.pl is also a CLI tool, meaning that the output goes to STDOUT and needs to be redirected to a file. But that also means that I can look for specific event IDs, using something like this:
C:\tools> evtparse.pl -e secevent.evt -t | find "Security/528" > sec_528.txt
Another option is to simply run the tool across the entire set of Event Logs and then use other native tools to narrow down what I want:
C:\tools>evtparse.pl -d f:\case\evtfiles -t > evt_events.txt
C:\tools>type evt_events.txt | find "Security/528" > sec_528.txt
Pretty simple, pretty straightforward...and, I wouldn't be able to do something like that with a GUI tool. I know that the CLI tool seems more cumbersome to some folks, but for others, it's immensely more flexible.
One thing I'm not a huge proponent of when it comes to creating timelines is collecting all possible data automagically. I know that some folks have said that they would just like to be able to point a tool at an image (maybe a mounted image), push a button, and let it collect all of the information. From my perspective, I see that as too much, simply because you don't really want everything that's available, because you'll end up having a huge timeline with way too much noise and not enough signal.
Here's an example...a bit ago, I was doing some work with respect to a SQL injection issue. I was relatively sure that the issue was SQLi, so I started going through the web server logs and found what I was looking for. SQLi analysis of web server logs is somewhat iterative, as there are things that you search for initially, then you get source IP addresses of the requests, then you start to see things specific to the injection, and each time, you go back and search the logs again. In short, I'd narrowed down the entries to what I needed and was able to discard 99% of the requests, as they were normally occurring web traffic. I then created a timeline using the web server log excerpts and the file system metadata, and I had everything I needed to tell a complete story about what happened, when it started, and what was the source of the intrusion. In fact, looking at the timeline was a lot like looking at a .bash_history file, but with time stamps!
Now, imagine what I would have if I'd run a tool that had run through the file system and collected everything possible. File system metadata, Event Logs, Registry key LastWrite times, .lnk files, all of the web server logs, etc...the amount of data would have been completely overwhelming, possibly to the point of hiding or obscuring what I was looking for, let alone crashing any tool for viewing the data.
The fact is, based on the goals of your analysis, you won't need all of that other data...more to the point, all of that data would have made your analysis and producing an answer much more difficult. I'd much rather take a reasoned approach to the data that I'm adding to a timeline, particularly as it can grow to be quite a bit of information. In one instance, I was looking at a system which had apparently been involved in an incident, but had not been responded to in some time (i.e., it had simply been left in service and used). I was looking for indications of tools being run, so the first thing I did was view the audit settings on the system via RegRipper, and found that auditing was not enabled. Then I created a micro-timeline of just the available Prefetch files, and that proved equally fruitless, as apparently the original .pf files had been deleted and lost.
In another instance, I was looking for indications that someone had logged into a system. Reviewing the audit configuration, I saw that what was being audited had been set shortly after the system had been installed, and logins were not being audited. At that point, it didn't make sense to add the Security Event Log information to the timeline.
I do not see the benefit of running regtime.pl to collect all of the Registry key LastWrite times. Again, I know that some folks feel that they need to have everything, but from a forensic analysis perspective, I don't subscribe to that line of thinking...I'm not saying it's wrong, I'm simply saying that I don't follow that line of reasoning. The reason for this is threefold; first, there's no real context to the data you're looking at if you just grab the Registry key LastWrite times. A key was modified...how does that help you without context? Second, you're going to get a lot of noise...particularly due to the lack of context. Looking at a bunch of key LastWrite times, how will you be able to tell if the modification was a result of user or system action? Third, there is a great deal of pertinent time-based information within the data of Registry values (MRU lists, UserAssist subkeys, etc.), all of which is missed if you just run a tool like regtime.pl.
A lot of what we do with respect to IR and DF work is about justifying our reasoning. Many times when I've done work, I've been asked, "why did you do that?"...not so much to second guess what I was doing, but to see if I had a valid reason for doing it. The days of backing up a truck to the loading dock of an organization and imaging everything are long past. There are engagements where you have a limited time to get answers, so some form of triage is necessary to justify which systems and/or data (i.e., network logs, packet captures, etc.) you're going to acquire. There are also times where if you grab too many of the wrong systems, you're going to be spending a great deal of time and effort justifying that to the customer when it comes to billing. The same is true when you scale down to analyzing a single system and creating a timeline. You can take the "put in everything and then figure it out" approach, or you can take an iterative approach, adding layers of data as they make sense to do so. Sometimes previewing that data prior to adding it, performing a little pre-analysis, can also be revealing.
Finally, don't get me wrong...I'm not saying that there's just one way to create a timeline...there isn't. I'm just sharing my thoughts and reasoning behind how I approach doing it, as this has been extremely successful for me through a number of incidents.
Resources
log2timeline
Cutaway's SysComboTimeline tools
For me, timeline analysis as a very powerful tool, something that can be (and has been) used to great effect, if it makes sense to do so. Not all of us are always going to have investigations that are going to benefit from a timeline analysis, but for those cases where a timeline would be beneficial, they have proven to be an extremely valuable analysis step. However, creating a timeline isn't necessarily a point-and-click proposition.
I find creating the timelines to be extremely easy, based on the tools I've provided (in the Files section of the Win4n6 Yahoo group). For my uses, I prefer the modular nature of the tools, in part because I don't always have everything I'd like to have available to me. In instances where I'm doing some IR or triage work, I may only have selected files and a directory listing available, rather than access to a complete image. Or sometimes, I use the tools to create micro- or nano-timelines, using just the Event Logs, or just the Security Event Log...or even just specific event IDs from the Security Event Log. Having the raw data available and NOT being hemmed in by a commercial forensic analysis application means that I can use the tools to meet the goals of my analysis, not the other way around. See how that works? The goals of the analysis define what I look for, what I look at, and what tools I use...not the tool. The tool is just that...a tool. The tools I've provided are flexible enough to be able to be used to create a full timeline, or to create these smaller versions of timelines, which also serve a very important role in analysis.
As an example, evtparse.pl parses an Event Log (.evt, NOT .evtx) file (or all .evt files in a given directory) into the five-field TLN format I like to use. Evtparse.pl is also a CLI tool, meaning that the output goes to STDOUT and needs to be redirected to a file. But that also means that I can look for specific event IDs, using something like this:
C:\tools> evtparse.pl -e secevent.evt -t | find "Security/528" > sec_528.txt
Another option is to simply run the tool across the entire set of Event Logs and then use other native tools to narrow down what I want:
C:\tools>evtparse.pl -d f:\case\evtfiles -t > evt_events.txt
C:\tools>type evt_events.txt | find "Security/528" > sec_528.txt
Pretty simple, pretty straightforward...and, I wouldn't be able to do something like that with a GUI tool. I know that the CLI tool seems more cumbersome to some folks, but for others, it's immensely more flexible.
One thing I'm not a huge proponent of when it comes to creating timelines is collecting all possible data automagically. I know that some folks have said that they would just like to be able to point a tool at an image (maybe a mounted image), push a button, and let it collect all of the information. From my perspective, I see that as too much, simply because you don't really want everything that's available, because you'll end up having a huge timeline with way too much noise and not enough signal.
Here's an example...a bit ago, I was doing some work with respect to a SQL injection issue. I was relatively sure that the issue was SQLi, so I started going through the web server logs and found what I was looking for. SQLi analysis of web server logs is somewhat iterative, as there are things that you search for initially, then you get source IP addresses of the requests, then you start to see things specific to the injection, and each time, you go back and search the logs again. In short, I'd narrowed down the entries to what I needed and was able to discard 99% of the requests, as they were normally occurring web traffic. I then created a timeline using the web server log excerpts and the file system metadata, and I had everything I needed to tell a complete story about what happened, when it started, and what was the source of the intrusion. In fact, looking at the timeline was a lot like looking at a .bash_history file, but with time stamps!
Now, imagine what I would have if I'd run a tool that had run through the file system and collected everything possible. File system metadata, Event Logs, Registry key LastWrite times, .lnk files, all of the web server logs, etc...the amount of data would have been completely overwhelming, possibly to the point of hiding or obscuring what I was looking for, let alone crashing any tool for viewing the data.
The fact is, based on the goals of your analysis, you won't need all of that other data...more to the point, all of that data would have made your analysis and producing an answer much more difficult. I'd much rather take a reasoned approach to the data that I'm adding to a timeline, particularly as it can grow to be quite a bit of information. In one instance, I was looking at a system which had apparently been involved in an incident, but had not been responded to in some time (i.e., it had simply been left in service and used). I was looking for indications of tools being run, so the first thing I did was view the audit settings on the system via RegRipper, and found that auditing was not enabled. Then I created a micro-timeline of just the available Prefetch files, and that proved equally fruitless, as apparently the original .pf files had been deleted and lost.
In another instance, I was looking for indications that someone had logged into a system. Reviewing the audit configuration, I saw that what was being audited had been set shortly after the system had been installed, and logins were not being audited. At that point, it didn't make sense to add the Security Event Log information to the timeline.
I do not see the benefit of running regtime.pl to collect all of the Registry key LastWrite times. Again, I know that some folks feel that they need to have everything, but from a forensic analysis perspective, I don't subscribe to that line of thinking...I'm not saying it's wrong, I'm simply saying that I don't follow that line of reasoning. The reason for this is threefold; first, there's no real context to the data you're looking at if you just grab the Registry key LastWrite times. A key was modified...how does that help you without context? Second, you're going to get a lot of noise...particularly due to the lack of context. Looking at a bunch of key LastWrite times, how will you be able to tell if the modification was a result of user or system action? Third, there is a great deal of pertinent time-based information within the data of Registry values (MRU lists, UserAssist subkeys, etc.), all of which is missed if you just run a tool like regtime.pl.
A lot of what we do with respect to IR and DF work is about justifying our reasoning. Many times when I've done work, I've been asked, "why did you do that?"...not so much to second guess what I was doing, but to see if I had a valid reason for doing it. The days of backing up a truck to the loading dock of an organization and imaging everything are long past. There are engagements where you have a limited time to get answers, so some form of triage is necessary to justify which systems and/or data (i.e., network logs, packet captures, etc.) you're going to acquire. There are also times where if you grab too many of the wrong systems, you're going to be spending a great deal of time and effort justifying that to the customer when it comes to billing. The same is true when you scale down to analyzing a single system and creating a timeline. You can take the "put in everything and then figure it out" approach, or you can take an iterative approach, adding layers of data as they make sense to do so. Sometimes previewing that data prior to adding it, performing a little pre-analysis, can also be revealing.
Finally, don't get me wrong...I'm not saying that there's just one way to create a timeline...there isn't. I'm just sharing my thoughts and reasoning behind how I approach doing it, as this has been extremely successful for me through a number of incidents.
Resources
log2timeline
Cutaway's SysComboTimeline tools
Saturday, May 29, 2010
Some more stuff...
Registry
I've been working on a book on forensic analysis of the Windows Registry, and I was adding something to my outline the other day when I ran across Chris's blog post on how to crack passwords using files from an acquired image. Nothing quite like freeware to get the job done, eh? I guess one of the issues is that there's a "cost" associated with everything...you either pay a lot of $$ for a commercial package, or you "pay" by having to learn something that doesn't include pushing the "find all evidence" button. Kind of makes me wish for Forensicator Pro! ;-)
This is pretty cool stuff, particularly when you use it in conjunction with the samparse plugin, and this information about User Account Analysis. I know I keep referring back to that post, but hey...there are a LOT of analysts out there who think that the "Password Not Required" flag in the SAM means that the account doesn't have a password, and that's not the case at all.
Two things about this: first, some things (like this) bear repeating...again and again. Second, this is why we need to engage and be part of the larger community. Sitting in an office somewhere with no interaction with others in the community leads to misconceptions and bad assumptions.
Contacts and Sharing
Speaking of communities and sharing, Grayson had an interesting post that caught my eye, with respect to sharing. Evidently, he recently found out about a group that meets in Helena to discuss security, hacking, etc. This is a great way to network professionally, share information...and apparently, to just get out and have a sandwich!
Speaking Engagements
I've blogged recently about some upcoming speaking engagements, conferences where I and others will be speaking or presenting. My next two presentations (TSK/Open Source and the SANS Forensic Summit) will cover creating timelines, and using them for forensic analysis. The content of these presentations will be slightly different, due to time available, audience, etc. However, they both address timelines in forensic analysis because I really feel that they're important, and I'm just not seeing them being used often enough, particularly where it's glaringly obvious that a timeline would be an immensely powerful solution.
Yes, I know of folks who are using SIFT and log2timeline...I've seen a number of comments over in the Win4n6 Yahoo group. That's some real awesome sauce. I've written articles for Hakin9, including this one, which walks the reader through using my tools to create a timeline. I've done analysis of SQL injection attacks where a timeline consisting of the web server logs and the file system metadata basically gave me a .bash_history file with time stamps. I've created and used timelines to map activity across multiple systems and time zones, and found answers to questions that could only be seen in a timeline.
So, at this point, for those of you who are not creating timelines regularly, what is the biggest impediment or obstacle for you? Is it lack of knowledge, lack of access to tools...what?
Podcasts
Speaking of speaking engagements...I'm scheduled to be on with the guys from the Securabit podcast on 2 June. I'm a big fan of Ovie and Bret's CyberSpeak podcast and these kinds of things are always interesting. Most recently, I listened to the interview that included Dr. Eric Cole...whom I once worked with when he was at Teligent (I was with a consulting firm), albeit only for a couple of weeks.
I've also been on Lee Whitfield's Forensic4Cast podcast. Lee and Simon are swinging the Forensic4Cast Awards 2010, which they started last year...if you're planning to be at the SANS Forensic Summit this July (and even if you're not), be sure to enter a nomination and vote. You can view the 2009 awards here.
CaseNotes
There's an updated version of CaseNotes available...you do keep case notes, right? Chris blogged on it, as well as the importance of keeping case notes.
I've been working on a book on forensic analysis of the Windows Registry, and I was adding something to my outline the other day when I ran across Chris's blog post on how to crack passwords using files from an acquired image. Nothing quite like freeware to get the job done, eh? I guess one of the issues is that there's a "cost" associated with everything...you either pay a lot of $$ for a commercial package, or you "pay" by having to learn something that doesn't include pushing the "find all evidence" button. Kind of makes me wish for Forensicator Pro! ;-)
This is pretty cool stuff, particularly when you use it in conjunction with the samparse plugin, and this information about User Account Analysis. I know I keep referring back to that post, but hey...there are a LOT of analysts out there who think that the "Password Not Required" flag in the SAM means that the account doesn't have a password, and that's not the case at all.
Two things about this: first, some things (like this) bear repeating...again and again. Second, this is why we need to engage and be part of the larger community. Sitting in an office somewhere with no interaction with others in the community leads to misconceptions and bad assumptions.
Contacts and Sharing
Speaking of communities and sharing, Grayson had an interesting post that caught my eye, with respect to sharing. Evidently, he recently found out about a group that meets in Helena to discuss security, hacking, etc. This is a great way to network professionally, share information...and apparently, to just get out and have a sandwich!
Speaking Engagements
I've blogged recently about some upcoming speaking engagements, conferences where I and others will be speaking or presenting. My next two presentations (TSK/Open Source and the SANS Forensic Summit) will cover creating timelines, and using them for forensic analysis. The content of these presentations will be slightly different, due to time available, audience, etc. However, they both address timelines in forensic analysis because I really feel that they're important, and I'm just not seeing them being used often enough, particularly where it's glaringly obvious that a timeline would be an immensely powerful solution.
Yes, I know of folks who are using SIFT and log2timeline...I've seen a number of comments over in the Win4n6 Yahoo group. That's some real awesome sauce. I've written articles for Hakin9, including this one, which walks the reader through using my tools to create a timeline. I've done analysis of SQL injection attacks where a timeline consisting of the web server logs and the file system metadata basically gave me a .bash_history file with time stamps. I've created and used timelines to map activity across multiple systems and time zones, and found answers to questions that could only be seen in a timeline.
So, at this point, for those of you who are not creating timelines regularly, what is the biggest impediment or obstacle for you? Is it lack of knowledge, lack of access to tools...what?
Podcasts
Speaking of speaking engagements...I'm scheduled to be on with the guys from the Securabit podcast on 2 June. I'm a big fan of Ovie and Bret's CyberSpeak podcast and these kinds of things are always interesting. Most recently, I listened to the interview that included Dr. Eric Cole...whom I once worked with when he was at Teligent (I was with a consulting firm), albeit only for a couple of weeks.
I've also been on Lee Whitfield's Forensic4Cast podcast. Lee and Simon are swinging the Forensic4Cast Awards 2010, which they started last year...if you're planning to be at the SANS Forensic Summit this July (and even if you're not), be sure to enter a nomination and vote. You can view the 2009 awards here.
CaseNotes
There's an updated version of CaseNotes available...you do keep case notes, right? Chris blogged on it, as well as the importance of keeping case notes.
Wednesday, May 26, 2010
More links...
WFA 2/e Book Review
Peter Sheffield posted a review of WFA 2/e over on the SANS Forensic Blog. What can I say, besides, "Thanks, Peter!" I really appreciate it when folks let me know what they think of the book, or the tools, but I appreciate it even more when they do so publicly, like what Peter did. Such things really help the sales of the book. More importantly, it's beneficial for me to see that others in the community have found the work and effort put into the books to be useful or valuable.
Quote
I received the following quote from Chris Perkins, CISSP, ACE (Hujarl), Digital Forensic Investigator, along with his authorization to share it:
Some years ago while at a tech conference I ran across your first edition of the Windows Forensics Analysis book. On my return flight I read it cover to cover, and read the Registry Analysis chapter twice! I had an interest in the forensic space previous to this experience with my work as a security analyst, but your book spurred my interest even further and helped drive me towards my current career.
Fast forward to today and I am still referencing that great book frequently in my work as a Digital Forensic Investigator. It is well worn and dog-eared throughout.
In addition, your RegRipper tool is used constantly in my investigations, especially in Intellectual Property work. The beauty of the tool is its quick, clean text reports and flexibility for additional plug-ins based on specific needs. It can be verified directly with other tools and methods, which is very necessary process to validate the data.
Thanks so much for the great work!
Thanks, Chris, for your words, as well as for allowing me to share your comments publicly.
MS goes Open Source
Microsoft recently released a tool for viewing the content structure of PST files called the PST Data Structure View Tool, or pstviewtool. MS has also released the PST file format SDK. These releases follow MS's release of the .pst structure specification earlier this year, and make it easier for programmers to access the contents of PST files without having to have OutLook or Exchange installed.
Date Formats
Working on writing recently, I've been trying to figure out where a good place is to fit in a discussion or even just state, "here are date formats used by MS". The Old New Thing blog has a very good post on time stamp formats. One that isn't mentioned in the post is the 128-bit SYSTEMTIME format; this one is used in Scheduled Task .job files, as well as in several Registry keys that have to do with wireless access on Vista and above. Please don't think that that's a complete or comprehensive list of where the date format is used in Windows...it's only two places that I'm aware of, and there are likely others.
Metadata
I've recently seen and received a number of questions about Office 97-2003 metadata date formats, what the date values refer to (GMT vs. local system time), and where they're located in the binary format. Well, MS was nice enough to publish the formats, which you can use to verify findings from other tools. Click on the link in the "Date Formats" section above, and you'll see that the OLE date format is different from other formats, particularly the more recent Office (2007, 2010) formats.
User Account Analysis
The issue of user account analysis comes up time and again, and I thought that this would be worth repeating. I've seen the question of the "password not required" flag and what it means come up in various forums, most recently in the new RegRipper forums. I understand that this can be a bit tough to grasp, so I'd like to post it again.
With respect to the "password not required" flag in the output of the samparse.pl plugin, what I got from someone at MS is as follows:
That specifies that the password-length and complexity policy settings do not apply to this user. If you do not set a password then you should be able to enable the account and logon with just the user account. If you set a password for the account, then you will need to provide that password at logon. Setting this flag on an existing account with a password does not allow you to logon to the account without the password.
I hope that helps those of you doing analysis.
CyberSpeak
Ovie (sans Bret) has posted another CyberSpeak podcast...check it out!
TSK/Open Source Conference
Just a reminder about the TSK/Open Source Digital Forensics Conference coming up on 9 June! Check out the presentations!
SANS Forensic Summit
The SANS Forensic Summit is coming up, 8/9 July! Check it out!
Peter Sheffield posted a review of WFA 2/e over on the SANS Forensic Blog. What can I say, besides, "Thanks, Peter!" I really appreciate it when folks let me know what they think of the book, or the tools, but I appreciate it even more when they do so publicly, like what Peter did. Such things really help the sales of the book. More importantly, it's beneficial for me to see that others in the community have found the work and effort put into the books to be useful or valuable.
Quote
I received the following quote from Chris Perkins, CISSP, ACE (Hujarl), Digital Forensic Investigator, along with his authorization to share it:
Some years ago while at a tech conference I ran across your first edition of the Windows Forensics Analysis book. On my return flight I read it cover to cover, and read the Registry Analysis chapter twice! I had an interest in the forensic space previous to this experience with my work as a security analyst, but your book spurred my interest even further and helped drive me towards my current career.
Fast forward to today and I am still referencing that great book frequently in my work as a Digital Forensic Investigator. It is well worn and dog-eared throughout.
In addition, your RegRipper tool is used constantly in my investigations, especially in Intellectual Property work. The beauty of the tool is its quick, clean text reports and flexibility for additional plug-ins based on specific needs. It can be verified directly with other tools and methods, which is very necessary process to validate the data.
Thanks so much for the great work!
Thanks, Chris, for your words, as well as for allowing me to share your comments publicly.
MS goes Open Source
Microsoft recently released a tool for viewing the content structure of PST files called the PST Data Structure View Tool, or pstviewtool. MS has also released the PST file format SDK. These releases follow MS's release of the .pst structure specification earlier this year, and make it easier for programmers to access the contents of PST files without having to have OutLook or Exchange installed.
Date Formats
Working on writing recently, I've been trying to figure out where a good place is to fit in a discussion or even just state, "here are date formats used by MS". The Old New Thing blog has a very good post on time stamp formats. One that isn't mentioned in the post is the 128-bit SYSTEMTIME format; this one is used in Scheduled Task .job files, as well as in several Registry keys that have to do with wireless access on Vista and above. Please don't think that that's a complete or comprehensive list of where the date format is used in Windows...it's only two places that I'm aware of, and there are likely others.
Metadata
I've recently seen and received a number of questions about Office 97-2003 metadata date formats, what the date values refer to (GMT vs. local system time), and where they're located in the binary format. Well, MS was nice enough to publish the formats, which you can use to verify findings from other tools. Click on the link in the "Date Formats" section above, and you'll see that the OLE date format is different from other formats, particularly the more recent Office (2007, 2010) formats.
User Account Analysis
The issue of user account analysis comes up time and again, and I thought that this would be worth repeating. I've seen the question of the "password not required" flag and what it means come up in various forums, most recently in the new RegRipper forums. I understand that this can be a bit tough to grasp, so I'd like to post it again.
With respect to the "password not required" flag in the output of the samparse.pl plugin, what I got from someone at MS is as follows:
That specifies that the password-length and complexity policy settings do not apply to this user. If you do not set a password then you should be able to enable the account and logon with just the user account. If you set a password for the account, then you will need to provide that password at logon. Setting this flag on an existing account with a password does not allow you to logon to the account without the password.
I hope that helps those of you doing analysis.
CyberSpeak
Ovie (sans Bret) has posted another CyberSpeak podcast...check it out!
TSK/Open Source Conference
Just a reminder about the TSK/Open Source Digital Forensics Conference coming up on 9 June! Check out the presentations!
SANS Forensic Summit
The SANS Forensic Summit is coming up, 8/9 July! Check it out!
Friday, May 21, 2010
Analysis Tips
I wanted to throw out a couple of things that I've run across...
MFT
I've worked a number of incidents where malware has been placed on a system and it's MAC times 'stomped', either through something similar to timestomp, or through copying the times from a legitimate file. In such cases, extracting $FILE_NAME attribute times for the file from the MFT have been essential for establishing accuracy in a timeline. Once this has been done, everything has fallen into place, including aligning the time with other data sources in the timeline (Scheduled Task log, Event Logs, etc.).
$LogFile
In a number of instances, this NTFS metadata file has been a gold mine. I worked on an exam last year where we thought that the intruder had figured out the admin password for a web-based CMS. I had a live image of the drive, and found the contents of the password file in $LogFile, which clearly demonstrated that the admin password was blank. BinText worked great for this.
$I30
This index file appears in directories when you're using FTK Imager, and in a number of instances, has been indispensable. During a recent exam where, due to lack of temporal proximity, I found the directory used by an intruder, but it was apparently empty. The $I30 file contained references to the artifacts in question.
Thoughts on Analysis
When working on an engagement...IR, forensic analysis, etc...we often loose site of what the term "analysis" means. We're supposed to be the experts, and the "customer" is relying on use to extract, review, and distill that extremely technical data into something that they can understand and use. Running through gigabytes of IIS logs and dumping out the entries that appear to indicate SQL injection and giving those to the customer from them to research and interpret is NOT analysis.
Let me break it down so you can put this on a t-shirt:
Run tool + dump output != analysis
Make sense?
MFT
I've worked a number of incidents where malware has been placed on a system and it's MAC times 'stomped', either through something similar to timestomp, or through copying the times from a legitimate file. In such cases, extracting $FILE_NAME attribute times for the file from the MFT have been essential for establishing accuracy in a timeline. Once this has been done, everything has fallen into place, including aligning the time with other data sources in the timeline (Scheduled Task log, Event Logs, etc.).
$LogFile
In a number of instances, this NTFS metadata file has been a gold mine. I worked on an exam last year where we thought that the intruder had figured out the admin password for a web-based CMS. I had a live image of the drive, and found the contents of the password file in $LogFile, which clearly demonstrated that the admin password was blank. BinText worked great for this.
$I30
This index file appears in directories when you're using FTK Imager, and in a number of instances, has been indispensable. During a recent exam where, due to lack of temporal proximity, I found the directory used by an intruder, but it was apparently empty. The $I30 file contained references to the artifacts in question.
Thoughts on Analysis
When working on an engagement...IR, forensic analysis, etc...we often loose site of what the term "analysis" means. We're supposed to be the experts, and the "customer" is relying on use to extract, review, and distill that extremely technical data into something that they can understand and use. Running through gigabytes of IIS logs and dumping out the entries that appear to indicate SQL injection and giving those to the customer from them to research and interpret is NOT analysis.
Let me break it down so you can put this on a t-shirt:
Run tool + dump output != analysis
Make sense?
Temporal Proximity
A couple of years ago, I heard someone...a really smart someone...talk about "temporal proximity". I know that sounds Star Trek-y, but the reference was to initiating response activities as close to an incident as possible.
Several of the industry reports indicate that the majority of incidents that the vendors have responded to have been the result of third-party notification to the victim. That alone indicates a number of things, the lack of temporal proximity (perhaps a better description would be "temporal dispersion") being one of them.
Why is this so important? Well, a lot of good...no, strike that...a lot of critical information can exist in memory, making it very volatile. Processes complete, network connections terminate. The longer you wait, the more this happens...and the system is more likely to be rebooted.
Some intruders get on systems, run tools, and them leave with data. When they do so, they may delete their toolkits. I've seen batch files that include the "del" command for just that purpose. Well, the more temporal dispersion you have from the incident, the less likely you are to recover the deleted files...in case you haven't heard, Windows (especially XP) has it's own built-in antiforensics measures.
Okay, you're probably wondering what I'm talking about...so I'll tell you. For Windows systems, even if you don't interact with the system, stuff still happens, particularly with XP. Just let an XP system sit for a couple of days, and you'll see. Restore Points are created every 24 hours, and if the disk space available for the RPs is getting short, others will be deleted. A limited defrag is run every three days. And this is just for an XP system that sits there with no network connectivity and no one interacting with it. Now, add to that things like Windows software and application updates...you know, the stuff that just kind of happens automatically with a network connected system. Even with minimal auditing enabled, stuff still gets logged to the Event Log...more so on Vista and Windows 7, simply because there are so many more logs.
Now, add to the mix that no one within your infrastructure is aware of an incident (intruder, malware, etc.), and systems remain up, functioning, operational and in use. I've been on engagements where we collected data from a system and then three days later collected the same data...and you'd swear that they were two different systems. Prefetch files had been deleted, deleted files had been overwritten by OS and application updates, applications and tools being run, etc.
In order to achieve temporal proximity, you need a couple of things. First, visibility...if you don't have visibility into your infrastructure, how will you know when something occurs? You can't really expect to know when something goes wrong or changes if you're not monitoring, right?
Second, you need a plan. What's you're IR plan? Acquire memory and disk, and then take the system offline? Or panic and not do anything at all until someone who has no idea what's going on makes a decision? I can't tell you the number of times I've responded and found out that the incident had been detected a month prior, and the infected/compromised system had been left up the entire time.
Me: "You know the intruder has been siphoning data off of this system for the past month, right?"
Them: "We didn't know what to do."
This happens more than you'd care to know, and not just to one vertical...not just PCI, but to many, many types of victims.
One final note...Marines in training learn what are referred to as "immediate actions". These are simple tasks that you use to clear a jammed weapon. They're simple when you're on the range, on a bright, sunny day after a good night's sleep. You can ask a range coach if you're doing it right. But we're trained on this over and over because you never need it in those conditions...when you're going to need that reaction to be programmed is during an assault, at 2:30am, after you've gone without sleep for two or more days and maybe haven't eaten in as long. And it's raining. And it's cold.
Are your IT assets critical to your business? If I were to back up a truck and take all of your computers...all desktops, laptops, servers, etc...how would that affect your business? It would disappear, wouldn't it? Well, if IT assets are so critical to your business, why not protect them? The bad guys aren't coming into your organization and walking out with boxes full of papers...they're coming into your network and stealing data that way. And they're successful because in many cases, they have greater visibility into your infrastructure than you do.
Several of the industry reports indicate that the majority of incidents that the vendors have responded to have been the result of third-party notification to the victim. That alone indicates a number of things, the lack of temporal proximity (perhaps a better description would be "temporal dispersion") being one of them.
Why is this so important? Well, a lot of good...no, strike that...a lot of critical information can exist in memory, making it very volatile. Processes complete, network connections terminate. The longer you wait, the more this happens...and the system is more likely to be rebooted.
Some intruders get on systems, run tools, and them leave with data. When they do so, they may delete their toolkits. I've seen batch files that include the "del" command for just that purpose. Well, the more temporal dispersion you have from the incident, the less likely you are to recover the deleted files...in case you haven't heard, Windows (especially XP) has it's own built-in antiforensics measures.
Okay, you're probably wondering what I'm talking about...so I'll tell you. For Windows systems, even if you don't interact with the system, stuff still happens, particularly with XP. Just let an XP system sit for a couple of days, and you'll see. Restore Points are created every 24 hours, and if the disk space available for the RPs is getting short, others will be deleted. A limited defrag is run every three days. And this is just for an XP system that sits there with no network connectivity and no one interacting with it. Now, add to that things like Windows software and application updates...you know, the stuff that just kind of happens automatically with a network connected system. Even with minimal auditing enabled, stuff still gets logged to the Event Log...more so on Vista and Windows 7, simply because there are so many more logs.
Now, add to the mix that no one within your infrastructure is aware of an incident (intruder, malware, etc.), and systems remain up, functioning, operational and in use. I've been on engagements where we collected data from a system and then three days later collected the same data...and you'd swear that they were two different systems. Prefetch files had been deleted, deleted files had been overwritten by OS and application updates, applications and tools being run, etc.
In order to achieve temporal proximity, you need a couple of things. First, visibility...if you don't have visibility into your infrastructure, how will you know when something occurs? You can't really expect to know when something goes wrong or changes if you're not monitoring, right?
Second, you need a plan. What's you're IR plan? Acquire memory and disk, and then take the system offline? Or panic and not do anything at all until someone who has no idea what's going on makes a decision? I can't tell you the number of times I've responded and found out that the incident had been detected a month prior, and the infected/compromised system had been left up the entire time.
Me: "You know the intruder has been siphoning data off of this system for the past month, right?"
Them: "We didn't know what to do."
This happens more than you'd care to know, and not just to one vertical...not just PCI, but to many, many types of victims.
One final note...Marines in training learn what are referred to as "immediate actions". These are simple tasks that you use to clear a jammed weapon. They're simple when you're on the range, on a bright, sunny day after a good night's sleep. You can ask a range coach if you're doing it right. But we're trained on this over and over because you never need it in those conditions...when you're going to need that reaction to be programmed is during an assault, at 2:30am, after you've gone without sleep for two or more days and maybe haven't eaten in as long. And it's raining. And it's cold.
Are your IT assets critical to your business? If I were to back up a truck and take all of your computers...all desktops, laptops, servers, etc...how would that affect your business? It would disappear, wouldn't it? Well, if IT assets are so critical to your business, why not protect them? The bad guys aren't coming into your organization and walking out with boxes full of papers...they're coming into your network and stealing data that way. And they're successful because in many cases, they have greater visibility into your infrastructure than you do.
Friday, May 14, 2010
Linkity linkity
RegRipper.net
Brett updated RegRipper.net recently...take a look. I received some emails recently regarding "404 Not Found" messages for some stuff linked at the original site, and then received a couple of messages from Brett.
Brett's done a great job of maintaining the site, but for the site to really be of value, it takes more than folks in the community coming by to grab RegRipper and that's it. It takes contributions...thoughts, ideas, communication, etc. One particular project that's benefited from a very active community is Volatility.
Here's an interesting post from the Binary Intelligence blog, explaining how Matt went about modifying the current RegRipper to meet his own needs! Great job, Matt!
64-bit Software hives
Speaking of the Registry, does anyone have Software hives from well-used 64-bit systems that they're willing to share, for research purposes?
ProDiscover
Chris Brown recently released v6.5 of ProDiscover. Chris very graciously provided me with a license back when PD was at version 3, and I've used the framework ever since. Chris added Perl as the scripting language for PD, in the form of ProScripting, a while back and that proved to be very beneficial. Most times my case notes will start with something like, "Created a case project in ProDiscover v6.0, added the image, and populated the Registry and Internet History Views." This is a great way to get an initial view of things, particularly if you suspect malware has infected the system. One of the things I look for first is the Default User with a web browsing history.
Mutexes
When conducting IR or analyzing live IR data, I tend to lean toward a little Least Frequency of Occurrence (LFO) analysis as an approach to malware detection on systems. Most times, what I do is grab the output of handle.exe and run it through a Perl script (handle.pl, posted to the Files section of the Win4n6 Yahoo group) to get a list of the mutants/mutexes that are unique or appear least frequently on the system.
When it comes to LFO analysis, some folks seem to think that means just running a tool, like handle.exe, or just running a script that locates all of those mutexes that are unique and appear only once in the output of handle. But that's not analysis...that's just running a tool and getting data. Due to the way malware authors use mutexes, you have to look for something odd and out of place, so comparing the names with each other is one way to conduct LFO analysis. Another way to address this if you're looking at multiple systems is to compare your findings between systems. Let's say that you have some systems you know to not be infected, and others that you suspect may be infected...conducting LFO analysis on each system and comparing the output across all systems may provide some interesting findings.
My point is that running a tool and dumping the output into a report is NOT analysis, folks.
In addition to handle.exe, I ran across this post on Jamie Blasco's blog today that listed two tools, one of which that would be of use during IR...enumeratemutex.exe. While this would enumerate the mutexes for you and allow you to do a really quick LFO analysis, it wouldn't necessarily allow you to tie the mutex to a specific process. However, it can be a good check.
TSK Open Source Conference
June 9th is the date for Brian Carrier's first TSK and Open Source Forensics Conference, right in my own backyard (well, almost...that would be kind of cool though...).
I'll be giving a presentation on using open source tools to create timelines for analysis.
Cory's apparently doing a presentation entitled Commando Forensics...is it wrong of me to want to go see Cory talk about doing forensics commando? I have to admit that there's a certain horrifying fascination there...but is it really so wrong? ;-)
The venue isn't far from a Dogfish Head Ale House, and Vintage 51 is close, as well. Look to one of those venues for the conference pre-party (I'm kind of proactive and not into after-parties...) the evening before.
SANS Forensic Summit
The SANS What Works in Forensics and Incident Response summit is coming up this summer in Washington, DC.
The agenda looks like another good one this year. Jesse will be talking about fuzzy hashing, Troy will be talking about Windows 7, and Richard will be presenting on the CIRT-level response to APT. Between the presentations and panels, this looks like it will be another great opportunity.
I'll be giving a workshop on adding pertinent Registry data to a timeline (can you see a trend developing here, with my presentation at the TSK conference?), and how doing so can really help develop context to and confidence in the data you're looking at.
Looks like I'm on a panel again this time around...those are always a good time. Troy Larson will be there...everyone should come on by and check out his Sharky lazer pointer. No, that's not a euphemism for anything.
Giggity.
Brett updated RegRipper.net recently...take a look. I received some emails recently regarding "404 Not Found" messages for some stuff linked at the original site, and then received a couple of messages from Brett.
Brett's done a great job of maintaining the site, but for the site to really be of value, it takes more than folks in the community coming by to grab RegRipper and that's it. It takes contributions...thoughts, ideas, communication, etc. One particular project that's benefited from a very active community is Volatility.
Here's an interesting post from the Binary Intelligence blog, explaining how Matt went about modifying the current RegRipper to meet his own needs! Great job, Matt!
64-bit Software hives
Speaking of the Registry, does anyone have Software hives from well-used 64-bit systems that they're willing to share, for research purposes?
ProDiscover
Chris Brown recently released v6.5 of ProDiscover. Chris very graciously provided me with a license back when PD was at version 3, and I've used the framework ever since. Chris added Perl as the scripting language for PD, in the form of ProScripting, a while back and that proved to be very beneficial. Most times my case notes will start with something like, "Created a case project in ProDiscover v6.0, added the image, and populated the Registry and Internet History Views." This is a great way to get an initial view of things, particularly if you suspect malware has infected the system. One of the things I look for first is the Default User with a web browsing history.
Mutexes
When conducting IR or analyzing live IR data, I tend to lean toward a little Least Frequency of Occurrence (LFO) analysis as an approach to malware detection on systems. Most times, what I do is grab the output of handle.exe and run it through a Perl script (handle.pl, posted to the Files section of the Win4n6 Yahoo group) to get a list of the mutants/mutexes that are unique or appear least frequently on the system.
When it comes to LFO analysis, some folks seem to think that means just running a tool, like handle.exe, or just running a script that locates all of those mutexes that are unique and appear only once in the output of handle. But that's not analysis...that's just running a tool and getting data. Due to the way malware authors use mutexes, you have to look for something odd and out of place, so comparing the names with each other is one way to conduct LFO analysis. Another way to address this if you're looking at multiple systems is to compare your findings between systems. Let's say that you have some systems you know to not be infected, and others that you suspect may be infected...conducting LFO analysis on each system and comparing the output across all systems may provide some interesting findings.
My point is that running a tool and dumping the output into a report is NOT analysis, folks.
In addition to handle.exe, I ran across this post on Jamie Blasco's blog today that listed two tools, one of which that would be of use during IR...enumeratemutex.exe. While this would enumerate the mutexes for you and allow you to do a really quick LFO analysis, it wouldn't necessarily allow you to tie the mutex to a specific process. However, it can be a good check.
TSK Open Source Conference
June 9th is the date for Brian Carrier's first TSK and Open Source Forensics Conference, right in my own backyard (well, almost...that would be kind of cool though...).
I'll be giving a presentation on using open source tools to create timelines for analysis.
Cory's apparently doing a presentation entitled Commando Forensics...is it wrong of me to want to go see Cory talk about doing forensics commando? I have to admit that there's a certain horrifying fascination there...but is it really so wrong? ;-)
The venue isn't far from a Dogfish Head Ale House, and Vintage 51 is close, as well. Look to one of those venues for the conference pre-party (I'm kind of proactive and not into after-parties...) the evening before.
SANS Forensic Summit
The SANS What Works in Forensics and Incident Response summit is coming up this summer in Washington, DC.
The agenda looks like another good one this year. Jesse will be talking about fuzzy hashing, Troy will be talking about Windows 7, and Richard will be presenting on the CIRT-level response to APT. Between the presentations and panels, this looks like it will be another great opportunity.
I'll be giving a workshop on adding pertinent Registry data to a timeline (can you see a trend developing here, with my presentation at the TSK conference?), and how doing so can really help develop context to and confidence in the data you're looking at.
Looks like I'm on a panel again this time around...those are always a good time. Troy Larson will be there...everyone should come on by and check out his Sharky lazer pointer. No, that's not a euphemism for anything.
Giggity.
Subscribe to:
Posts (Atom)