Stuff
WFAT3e
So far, there are two reviews of WFAT3e posted to Amazon. That was pretty quick, and I greatly appreciate the effort that went into making that review available.
If you've got a copy of WFAT3e and are considering writing a review, here's what I'd like to humbly ask...please consider doing more than just reiterating the table of contents. After all, this book isn't just the second edition with some new info added...this is a companion book that should be on your bookshelf right next to the second edition. In writing this edition, I took out stuff that hasn't really changed (PE file format, etc.) and instead included stuff specific to Windows 7, such as Volume Shadow Copies, and a bunch of new file formats. I added an entire chapter just on Timeline Analysis, as well as one on Malware Detection. In the first chapter, I went into more detail regarding what I consider to be core analysis concepts...so getting your thoughts and feedback on those would not only be interesting for me, but also be very valuable for other potential readers who look to your review to help them make up their minds.
Addendum: Keith's review is posted here. Thanks so much for sharing your review! Corey's review is posted here.
Registry Analysis
Speaking of books, I've received a couple of emails asking me when a second edition of Windows Registry Forensics would be available. While it's much too early to have a second edition at the moment, it's not too early to start thinking about it. So, I thought I throw this out to the community...is a second edition something that would be of interest?
If so, what would you want to see added or modified in this second edition?
DFIRSummit
The agenda for the SANS Forensic Summit 2012 has been posted and it looks like this year's summit is going to be another outstanding event for DFIR folks. I've attended all of the summits, which started in 2008, with the exception of last year's event. These are always really great events, combining quality material and presenters with some excellent networking opportunities.
This time around, I've been selected to give the second keynote presentation on Wed, 27 June, an honor that I greatly appreciate and am humbled by.
For my presentation, I plan to use my CfP material, something I put together that I call, "Intro to Windows 7 Forensic Analysis". I'll try to pack as much practical, 'you can use this right now' knowledge into the hour that I have available. Keep in mind that the keynote will be at 8am...for me, that's almost lunch time, but I'm aware that many are still deep in REM (get it...R.E.M.??) sleep at that time of the day.
This year's event has a number of notable DFIR luminaries on the agenda, and the presentations cover a range of topics, including Windows 8, Mac OSX, Android memory analysis, effects of "The Cloud" on the industry, and there's even a SANS 360 event on the agenda. Chris Pogue (@cpbeefcake) will be presenting "Sniper Forensics v3".
So, keep your eyes open for new developments regarding this event...if you're on Twitter, the hashtag is "#DFIRSummit".
IOCs
I've had a couple of posts recently on IOCs (most recent one here, earlier post here). Unfortunately, it doesn't look like they've gone over too well...there hasn't been much in the way of discussion. That's too bad...I can see how properly developed IOCs can be extremely useful, particularly when it comes to sharing threat intelligence.
Good IOCs can be shared by folks within the digital analysis community in order to share information. Do we really think that things like RAM scrapers and keystroke loggers are isolated only to PCI engagements? I hope not. In some cases, I don't think that keystroke loggers are even looked for, because they aren't "on the radar" for the particular analyst. This may be due to a number of factors...lack of experience, fatigue, too many cases piled up, etc.
Also, I can see some significant value in sharing IOCs across security specialties. Let's say that you're a malware analyst, and you find something interesting, and decide to share the file name, hash, and interesting output from 'strings'. Okay, that's great, but you've got a sample on your analysis system and an opportunity to share the data you've already collected with others, such as host- and network-based analysts. Don't think one sample may be too terribly interesting? How about if by adding that one sample to an aggregate across a number of samples, trends being to develop?
Something that may be a little bit more concrete for folks, and may turn into an actual IOC, popped up on ForensicArtifacts.com recently thanks to John Lukach. Apparently, you can run the iCloud Service that you find on iPhones and iPads on Windows...so, if you're working an issue that involves data exfiltration, this may be something that you'll want to look into.
Reporting
I read this post from the HackerAcademy this morning, and I have to say, I agree wholeheartedly! I started out in infosec performing vulnerability assessments and pen tests, and across the board, I'd rather work with someone who was 80-85% technical, but could produce a deliverable, than someone who was 100% technical, but couldn't (or wouldn't) write.
By itself, writing helps (or should help) us organize our thoughts. We can start out by writing up a quick analysis plan, and use that as a guide, adding reasons for why we deviated from that plan. From there, we should be keeping case notes, which have our analysis goals written out right at the top of the page, to keep us on track and on point throughout the analysis. Finally, when we get to the actual reporting phase, we should have a template that we use, so that by the time that we're finishing up our actual analysis, everything we've written thus far pretty much lets the report write itself.
When performing your analysis, if you don't document something, it didn't happen. When reporting, you have to keep in mind why you're being paid all the money by a customer...if they could do this work themselves, they wouldn't be paying you. So...do you give them a three page report (one of which is the cover sheet) that basically says, "we didn't find anything", or do you show them what you did?
Another aspect of reporting is to archive information about the work that's been done by your team. I was once on a team where our manager told us to put our reports up on a protected file server. Over time, I found that I was the only one doing this...after every engagement, part of my close-out procedures checklist was to put a copy of the report on the server in the proscribed manner, and securely wipe the data and report off of my analysis system. Since I wasn't the only one doing analysis work, I believe that a great deal of valuable corporate knowledge was lost because other analysts refused to share their experiences and findings. We don't all look at or tackle problems in the same way, and someone may have experiences that would greatly benefit your current efforts...if they'd shared them. Sharing those experiences by posting the reports to the server meant that you could view the final product without having the other analysts do any additional work.
A while (over 2 yrs) ago, I posted a sample report to the Files section of the Win4n6 group. This report was based on analysis of a sample image downloaded from the Internet. Of course, I can't be expected to post actual customer reports, and this was the best way I found to go from concept to practice. I hope that someone who reads it finds it useful.
So far, there are two reviews of WFAT3e posted to Amazon. That was pretty quick, and I greatly appreciate the effort that went into making that review available.
If you've got a copy of WFAT3e and are considering writing a review, here's what I'd like to humbly ask...please consider doing more than just reiterating the table of contents. After all, this book isn't just the second edition with some new info added...this is a companion book that should be on your bookshelf right next to the second edition. In writing this edition, I took out stuff that hasn't really changed (PE file format, etc.) and instead included stuff specific to Windows 7, such as Volume Shadow Copies, and a bunch of new file formats. I added an entire chapter just on Timeline Analysis, as well as one on Malware Detection. In the first chapter, I went into more detail regarding what I consider to be core analysis concepts...so getting your thoughts and feedback on those would not only be interesting for me, but also be very valuable for other potential readers who look to your review to help them make up their minds.
Addendum: Keith's review is posted here. Thanks so much for sharing your review! Corey's review is posted here.
Registry Analysis
Speaking of books, I've received a couple of emails asking me when a second edition of Windows Registry Forensics would be available. While it's much too early to have a second edition at the moment, it's not too early to start thinking about it. So, I thought I throw this out to the community...is a second edition something that would be of interest?
If so, what would you want to see added or modified in this second edition?
DFIRSummit
The agenda for the SANS Forensic Summit 2012 has been posted and it looks like this year's summit is going to be another outstanding event for DFIR folks. I've attended all of the summits, which started in 2008, with the exception of last year's event. These are always really great events, combining quality material and presenters with some excellent networking opportunities.
This time around, I've been selected to give the second keynote presentation on Wed, 27 June, an honor that I greatly appreciate and am humbled by.
For my presentation, I plan to use my CfP material, something I put together that I call, "Intro to Windows 7 Forensic Analysis". I'll try to pack as much practical, 'you can use this right now' knowledge into the hour that I have available. Keep in mind that the keynote will be at 8am...for me, that's almost lunch time, but I'm aware that many are still deep in REM (get it...R.E.M.??) sleep at that time of the day.
This year's event has a number of notable DFIR luminaries on the agenda, and the presentations cover a range of topics, including Windows 8, Mac OSX, Android memory analysis, effects of "The Cloud" on the industry, and there's even a SANS 360 event on the agenda. Chris Pogue (@cpbeefcake) will be presenting "Sniper Forensics v3".
So, keep your eyes open for new developments regarding this event...if you're on Twitter, the hashtag is "#DFIRSummit".
IOCs
I've had a couple of posts recently on IOCs (most recent one here, earlier post here). Unfortunately, it doesn't look like they've gone over too well...there hasn't been much in the way of discussion. That's too bad...I can see how properly developed IOCs can be extremely useful, particularly when it comes to sharing threat intelligence.
Good IOCs can be shared by folks within the digital analysis community in order to share information. Do we really think that things like RAM scrapers and keystroke loggers are isolated only to PCI engagements? I hope not. In some cases, I don't think that keystroke loggers are even looked for, because they aren't "on the radar" for the particular analyst. This may be due to a number of factors...lack of experience, fatigue, too many cases piled up, etc.
Also, I can see some significant value in sharing IOCs across security specialties. Let's say that you're a malware analyst, and you find something interesting, and decide to share the file name, hash, and interesting output from 'strings'. Okay, that's great, but you've got a sample on your analysis system and an opportunity to share the data you've already collected with others, such as host- and network-based analysts. Don't think one sample may be too terribly interesting? How about if by adding that one sample to an aggregate across a number of samples, trends being to develop?
Something that may be a little bit more concrete for folks, and may turn into an actual IOC, popped up on ForensicArtifacts.com recently thanks to John Lukach. Apparently, you can run the iCloud Service that you find on iPhones and iPads on Windows...so, if you're working an issue that involves data exfiltration, this may be something that you'll want to look into.
Reporting
I read this post from the HackerAcademy this morning, and I have to say, I agree wholeheartedly! I started out in infosec performing vulnerability assessments and pen tests, and across the board, I'd rather work with someone who was 80-85% technical, but could produce a deliverable, than someone who was 100% technical, but couldn't (or wouldn't) write.
By itself, writing helps (or should help) us organize our thoughts. We can start out by writing up a quick analysis plan, and use that as a guide, adding reasons for why we deviated from that plan. From there, we should be keeping case notes, which have our analysis goals written out right at the top of the page, to keep us on track and on point throughout the analysis. Finally, when we get to the actual reporting phase, we should have a template that we use, so that by the time that we're finishing up our actual analysis, everything we've written thus far pretty much lets the report write itself.
When performing your analysis, if you don't document something, it didn't happen. When reporting, you have to keep in mind why you're being paid all the money by a customer...if they could do this work themselves, they wouldn't be paying you. So...do you give them a three page report (one of which is the cover sheet) that basically says, "we didn't find anything", or do you show them what you did?
Another aspect of reporting is to archive information about the work that's been done by your team. I was once on a team where our manager told us to put our reports up on a protected file server. Over time, I found that I was the only one doing this...after every engagement, part of my close-out procedures checklist was to put a copy of the report on the server in the proscribed manner, and securely wipe the data and report off of my analysis system. Since I wasn't the only one doing analysis work, I believe that a great deal of valuable corporate knowledge was lost because other analysts refused to share their experiences and findings. We don't all look at or tackle problems in the same way, and someone may have experiences that would greatly benefit your current efforts...if they'd shared them. Sharing those experiences by posting the reports to the server meant that you could view the final product without having the other analysts do any additional work.
A while (over 2 yrs) ago, I posted a sample report to the Files section of the Win4n6 group. This report was based on analysis of a sample image downloaded from the Internet. Of course, I can't be expected to post actual customer reports, and this was the best way I found to go from concept to practice. I hope that someone who reads it finds it useful.