New Stuff

RegRipper Plugins
Corey's busy this week attending Volatility training, but last night sent me a couple of RegRipper plugins he wrote, inspired by what he was learning in the training.  He'd also sent me a third one, which I got the okay to include right after I'd posted the newest release of RegRipper, so I'm including it now.

I've added  processor_architecture.pl, winevt.pl, and an updated pagefile.pl to the download archive.  However, I have not updated the appropriate profiles to include the two new plugins, nor have I changed the version number for the download.  Many thanks to Corey for sending those plugins in!  Keep 'em coming!

Malware Hiding Techniques
I've had another article posted on the Dell SecureWorks Research blog.  Part of the purpose of this post was to illustrate how sometimes we make assumptions about how malware (or other artifacts) may have ended up on the system, and there while there are times that the assumptions may be correct, when they aren't, the actual method of infection can be a game-changer. The analysis that resulted in these findings was fascinating, to say the least.

After you've read the post, something else to consider from the examples is how they circumvent protections.  For the first example, the assumption many analysts have with respect to the deployed RAT is that it gets on systems as a result of a spearphishing attack.  As such, protections against this infection vector would include email filtering and user education; however, both of these protections are obviated if the user is capable of disabling protections (AV, etc.) and installing the RAT.  As mentioned in the article, network monitoring flagged the system based on C2 communications, and efforts to install endpoint detection technologies were...again...obviated by the user.

With the second example, the malware file itself used an interesting technique to hide itself from casual view on the system, which also worked equally well against some digital analysis techniques.  The carrier file was identified as Vercuser.B, which "cleared the way" for the Poison Ivy infection, by checking for various protection mechanisms (VM, running AV software, etc.).

Something else that isn't mentioned in the blog post is that I initially ran into some analysis roadblocks, or so I thought...but after reaching out to Jamie Levy for some input, she pointed me in the right direction and the analysis went really smooth.  A good bit of what she helped me with was described in this blog post.  I didn't crowd-source this one, because to be honest, I didn't want to hear what a lot of folks thought, I wanted to hear what an expert knew.

My previous articles published to the Dell SecureWorks Research blog are here, and here.

WFA 4/e
There have been additional reviews of WFA 4/e posted on Amazon; again, thank you to everyone who's taken the time to share their thoughts...I greatly appreciate it.

There have been some discussion on social media regarding the edition number for this book.  While I understand the issue that was raised, I do not control what the publisher chooses to do with respect to numbering the editions. I did, however, get several folks that I trust to look at my outline and planned updates, and give their opinions as to the proposed content.  The book was tech edited by someone knowledgeable and known within the DFIR community. Further, I have asked for feedback on the third edition (as I have for my other books), as well as gone to the community to ask for input regarding what they'd like to see in the next edition.  In both cases, there have been very little of either.  I did receive a request to talk about "anti-forensics", but after I asked the person who asked for that to elaborate and expand on that a bit, I have yet to hear back.

I have to say, I have asked Syngress about their color scheme for the books.  Digital Forensics with Open Source Tools, Windows Forensic Analysis 2/e and 3/e, and Windows Registry Forensics all have the same color scheme, and the same shade of green.  I've been to conferences and given presentations, during which I've stated at the beginning of the presentation (when I have a copy of one of my books on the who am I slide) that the books all have the same color scheme and it confuses people.  Then, at the end of the presentation, I ask a question, offering to give away a copy of one of my books to whomever gets the right answer...and inevitably, the winner immediately states that they already have the book, only to find out that they thought they did because they only looked at the color scheme.  That happened at the USA CyberCrime Conference just last week.  So, it does confuse people.

My point is simply this...there's a great deal authors do not control when it comes to working with a publisher.  However, I have tried to address the content issue by reaching out to the community, particularly while developing the outline for the next book or edition, and I have received little input.  I tried to address one of the first questions I received regarding the content for this edition in this blog post, although that came after this book was actually published.

One thing that I hope folks consider doing before commenting or writing a review (good or bad) is actually reading the content of the book.  The two chapters at the end of the book are new material.  In the third edition, ch 8 was "Application Analysis", and this edition, it's "Correlating Artifacts", which includes information similar to what I posted to this blog in July, 2013.  Chapter 9, "Reporting", is entirely new.