Links and Stuff

VMWare Tip
Jimmy Weg shared a tip over on the Win4n6 group that may be useful to others.  Jimmy pointed out that on a sidebar on pg. 102 of Windows Registry Forensics, I mention trying several times to interrupt the VMWare boot process so that I can access the BIOS.  Jimmy suggests making this a bit easier by adding bios.bootDelay="4000" to the settings.ini file in order to create a 4 second delay. 

MarkG added a suggestion for using the VMWare host menu to select Power on to BIOS rather than simply booting the VM.

Thanks to both Jimmy and Mark...these tips may be very helpful to someone performing research, or attempting to use the techniques described near pg. 102 in WRF.

Sniper Forensics
Chris has posted another installment of his Sniper Forensics series over on the SpiderLabs Anterior blog.  This one is called Part IV: Finding Evil.

Chris and I worked together on the IBM team a while ago.  Chris moved on to TrustWave, and before I left IBM, the team submitted a letter to Visa and dropped off of the PCI QIRA list.  So, while I worked PCI response engagements for about 3 yrs (which included the associated certification and annual re-certification), I haven't worked these engagements in a while, and Chris and his team continue to work them on a pretty regular basis.  As such, there's a good deal that Chris and his team sees on a regular basis that I no longer see.

In this installment of the Sniper Forensics series, Chris discussed looking at systems which were part of a payment processing system; however, it appears that while the systems processed card holder data (CHD), they were apparently known (or thought) to NOT have been breached when Chris was called in to "investigate".  As Chris said in his post, we all tend to get analysis engagements like this..."I think this system may have malware or may have been breached, but I'm not sure".  In many cases, there are no definitive facts to point at, like a pop-up on the Desktop, AV detecting something, etc., and as such, it behooves us to have a thorough, documented process for addressing these types of engagements.

In short, the process used in this engagement appeared to be to acquire the necessary data (memory, volatile data, images, logs) based on scoping, and then perform analysis based on this data.  Rightly so, Chris draws on his past experience, as well as the customer specifications ("2.  What are you hoping that I don't find?") to determine what to look for in memory (as well as on the disk), which appears to have consisted of four specific types or artifacts of processes, and the checks are based on known items that the team had seen on previous engagements (process name variations, etc.).

Chris also described examining his timeline, going back 6 months to look at file "birth" dates ("B" in the "MACB" timeline listing) on files.  In his post, Chris didn't mention where the 6 month time frame originated, but he does say that the installation date for the system was in 2009.

One thing I wasn't clear on is this statement...

Searching the timeline also helped me to identify potential dump files.  I know most modern RAM dumpers obfuscate the output files by either using some basic encryption or even just encoding (like with an XOR).  It doesn't have to be fancy – just put the stolen data in some format that a regex won't identify.

I think it would be interesting to know (if it's not TrustWave company proprietary IP...) how someone would go about searching their timeline for files that Chris describes in that statement.  I think it's great that company's such as TrustWave are sharing information in the manner that they are, and my hope would be that, in cases such as this, that sharing would go just a bit further.

Some thoughts...
Reading through the post, it's clear that the scope was rather limited...and to be honest, this is often the case, as the customer will many times limit the scope.  This seems to have been the case here, as one of the scoping questions appears to have been, "2.  What are you hoping that I don't find?"  However, limiting the analysis in this manner can potentially be very dangerous, as the analyst may miss things that are different from those specifications.

One example that comes to mind is a RAM dumper, which is something Chris mentioned (item 1 in his list) in the post.  I have seen these before...the ones I saw were a combination of tools what would be run by a service, and that service would have a random sleep() time (some had a specific time that they slept after system start); what this means is that the back-office point of sale (POS) payment processing system would be booted, and the "bad stuff" would sit and wait for a specific process's virtual memory to accumulate CHD.  At some point, it would "wake up", dump process virtual memory, and "scrape" track data out.  Due to some very specific artifacts associated with the variant I was familiar with, we were able to easily determine the window of exposure, or how long the system had been actively breached.

However, what this means is that you're not likely to find the processes for this stuff running in memory.  You should, of course, find the service that is waiting, but the other, ancillary processes will run based on a specific trigger, and they tend to run very quickly, so if you're not dumping memory during the exact time that those processes run, you won't "see" them in a memory dump.  And it's relatively simple to "hide" the service in a memory dump, or "hide" the file on the system using time stomping techniques.

Overall, the post discussed looking for some very specific items in the data that was collected; it's probably safe to assume that the overall documented process that Chris and his team uses in instances like this wasn't completely listed in the blog post, simply due to space and brevity.  There are a lot of other checks that could have been done quite easily and efficiently to provide a more thorough, comprehensive result, and I'm sure that in order to save space and not loose the reader, most of these process steps simply weren't mentioned.

Chris was exactly right in the post; "...as professionals, sometimes we have to improvise."  I agree.  I'm sure that like other professionals, Chris and his team have a documented checklist of items to look for, and tools to use, when they encounter customer requests such as this, and I'm sure that it wasn't discussed in detail for brevity's sake. 

Reaching back into the dark recesses of my memory, Chris and I worked a case together where someone had broken into a company in a specific industry (not banking) and the intruder activity that we observed included searching for files that contained the word "banking"; so, sometimes a breach doesn't necessarily start out as being about CHD, or whatever critical data is maintained and processed by the customer.  However, a breach is a breach, and considerable work may need to be done to determine whether or not the intruder accessed that data.

So, I'm sure that a much more comprehensive, documented process was used in "finding evil", as there is a great deal of analysis that could have been done quickly and efficiently, but it simply wasn't included in the post to keep the post from growing too large to be read.

Be sure to catch Chris at the SANS Forensic IR Summit this summer in Austin! 

WRF Review
Grayson posted his review of WRF on his An Eye on Forensics blog.  I would like to give a big THANKS to Grayson and others who've taken the time to read through the book and posted their thoughts.

Community
There have been a couple of posts recently regarding "community" that have garnered a bit of attention.  First is David Kovar's Fragmentation of the digital forensics community post, and the second is this one on Belonging and Community from David Sullivan.

Having viewed the infosec "community" for about 14 years and the DFIR community for about 10 of those years, I've experienced and seen a good deal of what David Kovar talks about in his post, and I have to agree wholeheartedly with many of his points.  Also, like David, I have written programs (Perl scripts) that I have freely provided to the community, and many of you may know that one of my pet peeves is responding to someone who says that they have an emergency need for a particular script or update to a current script, only to not acknowledge receipt of that script and not provide so much as a thank you for the effort.  So much for "community", eh?

Mr. Sullivan starts his post off with the question, "...unless you are an established forensics professional is there even such thing as a community?"  I would suggest to Mr. Sullivan that a "community" is where you make it, and like other communities, some within the community create their own subcommunity.  By this, I don't mean an offshoot or tangential community, I mean that some simply create a community of trusted advisers that they reach to and support through various means.


One of Mr. Sullivan's questions bears a response:  I wonder if people on the inside realise how tough it is for newcomers to the area to gain any foothold into whatever community does exist.  Is it the nature of the business that makes professionals wary of new faces?

I really don't think it's a matter of "new faces" as much as it is, what are you willing to do, most particularly for yourself?  How many times have you gone into a forum or seen a post to a listserv, and you become immediately and acutely aware that the original poster (OP) made no discernible effort to search either the forum or Google for any information pertaining to their question?  Sure, there are a number of posts where the OP is looking for the solution to a homework assignment...those are pretty clear.  However, a community is about sharing, and dropping into a forum to post a question, rather than doing the research yourself and then posting your findings, does little to further the community.  I don't know for sure, but this may be what David Kovar was referring to when he mentioned bad behavior persists in his post.  Some communities advertise themselves as being "noob friendly" and oriented toward learning, but do little to support that role.