Updates and Links
ECSAP
I had a great time speaking on timeline analysis at an event last week...it was a great opportunity to get out in front of some folks and talk about this very important and valuable analysis technique. My impression was that most of the folks in the room hadn't really done this sort of analysis beyond perhaps entering some interpreted times and data into a spreadsheet.
One take-away for me from the conference speaking is that people like to get free stuff. In this case, I had one DiskLabs Find Evidence keyboard key left, and as I tend to do with conferences where I speak, I also gave away copies of my books...I gave away one copy of DFwOST and one of WRF (both of which were signed). I hope that the continuing promises of free stuff kept folks coming back into the room from breaks...
Along those lines, something I would offer back up to conference attendees is that speakers are people just like you, and they like to get free stuff, too...in particular, feedback. Did what they say make sense? Was the presentation material something that you feel you can use? A simple "yes" doesn't really constitute feedback. Some of us (not just me) have also written books or tools, which we may refer to...and getting feedback on those is always a bonus. But again..."cool" isn't really "feedback".
I can't speak for every presenter, but I value honest, considered feedback, even if it's negative, over a positive albeit empty statement. If what I talked about simply isn't useful, please...let me know. If it's too easy or too hard to understand...let me know. I think that most folks who present would welcome some honest feedback on what they covered.
Investigation Plans
Chris posted recently on the need to develop an investigation plan prior to doing any analysis. Chris even outlines an exercise to clarify that, and to keep it firmly planted in your mind while you conduct your analysis. I tend to do something very similar...I copy what I'm supposed to do (the goals) from the statement of work or contract to the top of the MSWord document I use for case notes, usually right below my description of the exhibits I've received. From there, I also write a description of my initial approach to the analysis...keyword searches I may want to run, as well as anything of note that I may have available, such as a time frame to work with (i.e., "online banking fraud was found to have begun on 20 March, so begin timeline analysis of the system prior to that date...").
Analysis plans are not set in stone...they are not rigid scripts that you need to follow lock-step, beginning to end. We all know that no plan survives first contact...the idea of an analysis plan is to get us started and keep us focused on the end goal, what we hope to achieve and what question(s) we need to answer for our customer. Too many times, we won't have a plan and we'll find something "interesting" and begin running ourselves down that rabbit hole, and by the time we take a breath to look around, the original goals of the exam are nowhere in sight, but we've consumed considerable time getting there.
Timelines
Having presented recently on the topic of timelines, and working on some code to more fully exploit Windows 7 Jump Lists as forensic resources, the creation and use of timelines have been on my mind a lot recently. I prepared and delivered a 2-day, hands-on course in timelines in June, and recently (ECSAP) presented a 2-hr compressed version of the class...which really doesn't do the subject justice (next time I'll push for at least a 4 hr slot). One of the things I've been thinking about is how useful timelines can be from both an investigative and an analytic perspective, and how a timeline can be used to answer a wide range of questions.
One example involves artifacts from the use of USB devices on Windows systems; I've seen a number of questions in forums and lists in which the original poster (OP) identifies an anomaly that is either interesting, or needs to be explained as part of the examination...something appears odd with respect to the observed artifacts. Often the question is, "what could have caused this?", and the answer may be found by developing a timeline of system activity, and identifying surrounding events and context to the observed artifacts.
Malware
Here's a great write-up on the Malware FreakShow 3 presentation provided by two TrustWave SpiderLabs researchers at DefCon19. The presentation addresses malware found on Windows-based point-of-sale ("POS"...take that any way you like...) devices.
Tools
Need to find Facebook artifacts? Take a look over on the TrustedSignal blog...there's a post indicating that a Python script has been updated and is available. You never know when you're going to need something like this...
Resources and Links
Ken's (re)view of GFIRST...what I really like about this post is the amount of his perspective that Ken encapsulates in his post, giving his views and insights of what he saw and experienced. Too many times in the community when someone talks about an event they attended or a book they read, the review is very mechanical..."the speaker talked about..." or "the book contains eight chapters; chapter 1 covers...". I think this is odd, in a way, because when I talk to folks about what they want to see in a presentation or book, very often when they're looking for is the author's insights...so, in a way, this sort of goes back to what I was saying in the ECSAP section of this post.
Here's an interesting post regarding not just a trick used by malware to confuse a potential victim, but the post also describes the use of MoonSol's DumpIt and the Volatility Framework.
The DFS guys posted their materials from GFIRST and OMFW...thanks to Andrew and Golden for doing that. There are a couple of great slide decks available; if you want to see how they investigated a data exfil incident (speaking of analysis plans), take a look at their slide pack from GFIRST...it's like reading their case notes from an exam. You'll have to excuse a misspelling or two (slide 19 mentions the setup.api log file; spelled correctly on slide 40), but for the most part, their examination of the USB history, et al, from an XP system is a very good view into an actual investigation, and well worth writing into a process or checklist.
A couple of thoughts from the presentation:
slide 38 - instead of writing a "wrapper script" to import the information into Excel, it might be easier to modify the usbstor.pl plugin (use of a "wrapper script" mentioned again in slide 79)
slide 40 - the LastWrite times of the USBStor subkeys are not used to determine the last time the devices were plugged into the system; this is further indicated by the USB Analysis Process illustrated in slide 43
slide 90 - path should read HKLM\System\CurrentControlSet\Services\lanmanserver\Shares
Speaking of OMFW, gleeda posted to her blog and included links to her, MHL, and Moyix's slides.
DFwOST
Richard Bejtlich posted his impressions (not a full-on review) of DFwOST. Thanks for the vote of confidence on a second edition, Richard...also, I do agree with what he mentioned with respect to the images, but as with WRF, there's not a lot that the authors can do about what the publisher or printer does with images.
I had a great time speaking on timeline analysis at an event last week...it was a great opportunity to get out in front of some folks and talk about this very important and valuable analysis technique. My impression was that most of the folks in the room hadn't really done this sort of analysis beyond perhaps entering some interpreted times and data into a spreadsheet.
Along those lines, something I would offer back up to conference attendees is that speakers are people just like you, and they like to get free stuff, too...in particular, feedback. Did what they say make sense? Was the presentation material something that you feel you can use? A simple "yes" doesn't really constitute feedback. Some of us (not just me) have also written books or tools, which we may refer to...and getting feedback on those is always a bonus. But again..."cool" isn't really "feedback".
I can't speak for every presenter, but I value honest, considered feedback, even if it's negative, over a positive albeit empty statement. If what I talked about simply isn't useful, please...let me know. If it's too easy or too hard to understand...let me know. I think that most folks who present would welcome some honest feedback on what they covered.
Investigation Plans
Chris posted recently on the need to develop an investigation plan prior to doing any analysis. Chris even outlines an exercise to clarify that, and to keep it firmly planted in your mind while you conduct your analysis. I tend to do something very similar...I copy what I'm supposed to do (the goals) from the statement of work or contract to the top of the MSWord document I use for case notes, usually right below my description of the exhibits I've received. From there, I also write a description of my initial approach to the analysis...keyword searches I may want to run, as well as anything of note that I may have available, such as a time frame to work with (i.e., "online banking fraud was found to have begun on 20 March, so begin timeline analysis of the system prior to that date...").
Analysis plans are not set in stone...they are not rigid scripts that you need to follow lock-step, beginning to end. We all know that no plan survives first contact...the idea of an analysis plan is to get us started and keep us focused on the end goal, what we hope to achieve and what question(s) we need to answer for our customer. Too many times, we won't have a plan and we'll find something "interesting" and begin running ourselves down that rabbit hole, and by the time we take a breath to look around, the original goals of the exam are nowhere in sight, but we've consumed considerable time getting there.
Timelines
Having presented recently on the topic of timelines, and working on some code to more fully exploit Windows 7 Jump Lists as forensic resources, the creation and use of timelines have been on my mind a lot recently. I prepared and delivered a 2-day, hands-on course in timelines in June, and recently (ECSAP) presented a 2-hr compressed version of the class...which really doesn't do the subject justice (next time I'll push for at least a 4 hr slot). One of the things I've been thinking about is how useful timelines can be from both an investigative and an analytic perspective, and how a timeline can be used to answer a wide range of questions.
One example involves artifacts from the use of USB devices on Windows systems; I've seen a number of questions in forums and lists in which the original poster (OP) identifies an anomaly that is either interesting, or needs to be explained as part of the examination...something appears odd with respect to the observed artifacts. Often the question is, "what could have caused this?", and the answer may be found by developing a timeline of system activity, and identifying surrounding events and context to the observed artifacts.
Malware
Here's a great write-up on the Malware FreakShow 3 presentation provided by two TrustWave SpiderLabs researchers at DefCon19. The presentation addresses malware found on Windows-based point-of-sale ("POS"...take that any way you like...) devices.
Tools
Need to find Facebook artifacts? Take a look over on the TrustedSignal blog...there's a post indicating that a Python script has been updated and is available. You never know when you're going to need something like this...
Resources and Links
Ken's (re)view of GFIRST...what I really like about this post is the amount of his perspective that Ken encapsulates in his post, giving his views and insights of what he saw and experienced. Too many times in the community when someone talks about an event they attended or a book they read, the review is very mechanical..."the speaker talked about..." or "the book contains eight chapters; chapter 1 covers...". I think this is odd, in a way, because when I talk to folks about what they want to see in a presentation or book, very often when they're looking for is the author's insights...so, in a way, this sort of goes back to what I was saying in the ECSAP section of this post.
Here's an interesting post regarding not just a trick used by malware to confuse a potential victim, but the post also describes the use of MoonSol's DumpIt and the Volatility Framework.
The DFS guys posted their materials from GFIRST and OMFW...thanks to Andrew and Golden for doing that. There are a couple of great slide decks available; if you want to see how they investigated a data exfil incident (speaking of analysis plans), take a look at their slide pack from GFIRST...it's like reading their case notes from an exam. You'll have to excuse a misspelling or two (slide 19 mentions the setup.api log file; spelled correctly on slide 40), but for the most part, their examination of the USB history, et al, from an XP system is a very good view into an actual investigation, and well worth writing into a process or checklist.
A couple of thoughts from the presentation:
slide 38 - instead of writing a "wrapper script" to import the information into Excel, it might be easier to modify the usbstor.pl plugin (use of a "wrapper script" mentioned again in slide 79)
slide 40 - the LastWrite times of the USBStor subkeys are not used to determine the last time the devices were plugged into the system; this is further indicated by the USB Analysis Process illustrated in slide 43
slide 90 - path should read HKLM\System\CurrentControlSet\Services\lanmanserver\Shares
Speaking of OMFW, gleeda posted to her blog and included links to her, MHL, and Moyix's slides.
DFwOST
Richard Bejtlich posted his impressions (not a full-on review) of DFwOST. Thanks for the vote of confidence on a second edition, Richard...also, I do agree with what he mentioned with respect to the images, but as with WRF, there's not a lot that the authors can do about what the publisher or printer does with images.