Links and Stuff

Practicals
I love stuff that is practical...stuff you can look at, follow along on, and by the end of the hour/day, have a new skill. I received an email this morning from my Twitter account telling me that Jaime Blasco was following me...I checked out his profile and found a link to something he'd written up on analyzing malicious PDF documents, using pdfid.py from Didier Stevens. This is really good stuff, as it can help an analyst narrow down what is perhaps the most difficult question to answer...how was a system infected or compromised? Many times, it's relatively simple to tell that a system had been infected or compromised, but how (and when) that happened can often remain a mystery. In some cases, know what had infected the system can lead the analyst in investigative directions, but most often it seems to lead to speculation. Practicals like what Jaime presented demonstrate how an analyst can narrow down the infection/compromise vector, particularly since we're seeing a great deal of malware that gets on a system as a secondary or tertiary download.

Training
Speaking of practicals and training, Julia King has some great tips on budget cuts and training in a recent ComputerWorld article. Over the years, I've seen folks invest in training that really wasn't useful...immediately or otherwise...to them. This is not to say that the instruction was bad...not at all, there are some excellent training providers out there. However, I've seen people go to courses that teach them how to perform digital forensics using Linux platforms, on Linux systems...and their infrastructure is all Windows. This is simply a matter of bad corporate planning and decision making, and perhaps a lack of availability of the appropriate training when training budgets are available. Training should be specific to meet your needs, and the skills should be used immediately upon the team member's return.

Addendum: For the record, the above statement (i.e., "I've seen people go to courses that teach them how to perform digital forensics using Linux platforms, on Linux systems...") is simply an example that harkens back to an HTCIA presentation I was giving, and in the next classroom was a course similar to the one described. The "people" referred to, in this case, were attendees of the course who commented that the training was very good, but they mostly acquired and analyzed Windows systems. Nothing disparaging was said about anyone, nor about any training provider. Thanks.

IR Planning
With respect to incident response planning, here's a great quote from Julia King's article mentioned above (the quote is from a CISO):
Someday, something bad is going to happen to your company. A laptop may get stolen or data gets stolen or a virus gets inserted into your network. Before you ever get to that point...

See what he says? He's aware that it's not a matter of if an incident occurs, but when. Further the quoted CISO advocates taking steps to be prepared for when an incident does occur.

Reporting
Keith Ferrell over at DarkReading has picked up on the RAM scraper thing previously mentioned in The Register by Dan Goodin. Keith's article has a list of eight things to do to improve the situation specific to RAM scrapers, as well as concerning malware, in general. The biggest thing that's missing, however, is a change in corporate culture. Perhaps the reason why security appears so lax on these systems is because there's no real corporate direction regarding information security.

I mean, think about it. Have you ever analyzed an image acquired from a server...one of the ones, say, in a rack in the data center...and found web browser history and maybe even email files?

Tools
Speaking of servers in data centers, have you seen F-Response TACTICAL? Be sure to check out the Forensic4Cast review of TACTICAL.

Geoff Chappell has a really good site with a lot of great information available. He's done a great deal of detailed research, and has provided some of that free of charge. When I first ran across his site, I found an excellent explanation of the bootstat.dat file found on Vista and above systems, and recently completed a parser for the file. Here's an example of the output:

C:\Perl\forensics\timeline>bsparse.pl -f d:\cases\vista\bootstat.dat
Timestamp : 41995 sec
Entry Size : 64 bytes
Sev Code : 1
Version : 2
Event ID : 0x1
System Time: Fri Jun 19 11:39:41 2009 UTC

Timestamp : 41995 sec
Entry Size : 120 bytes
Sev Code : 1
Version : 2
Event ID : 0x11
Type : 0x0
Path : \Windows\system32\winload.exe

And yes, it also does TLN output:

C:\Perl\forensics\timeline>bsparse.pl -f d:\cases\vista\bootstat.dat -t -s MYSYSTEM
1245411581|BOOTSTAT|MYSYSTEM||Bootstat.dat log file init event

Okay, at this point, you're probably wondering...beyond an academic exercise in binary parsing using Perl, how is this helpful? Well, according to Geoff's site, the bootstat.dat file is the BootManager log file. Right there, that should grab you...anything that's a "log file" might be useful in forensic analysis. A log file initialization event has a time stamp associated with it (as illustrated above), which can be used to correlate additional events, such as from Windows Event Logs (.evtx files), file system metadata, etc. For example, the LastShutdownTime from the Registry would ideally be followed by a bootstat.dat log file initialization event...right?

This is another example of data that is available to a knowledgeable analyst...data that can be used to build a more complete picture of what's going on with respect the system, and the goals of the analysis. And we're not talking hours and hours of work here...we're talking about a few simple tools and a documented process. In fact, collecting data and constructing a timeline from that data can be part of an intake procedure.

Other Stuff
There's another CyberSpeak podcast up and available! Thanks to Ovie and Bret for turning out these podcasts!