WFA 4/e Reviews

Brett Shavers has posted the first (that I'm aware of) reviews of WFA 4/e...one on Amazon, and a longer one can be found on his WinFE blog.

Not so much a review, but Corey refers to the book in one of his recent blog posts, saying that he's still digesting it.  He also refers to the RecentFileCache.bcf file, as well as to a tool I wrote and provided with the book materials for parsing it.

I greatly appreciate the time and effort folks are putting into reading and digesting the book, and particularly those who are writing reviews.  Thank you, all.

Addendum, 29 Apr: Two more reviews are up on Amazon!

Follow up on TTPs post

David Bianco's "Pyramid of Pain"

As a follow-up to my previous post on TTPs, a couple of us (David Bianco, Jack Crook, etc.) took the discussion to G+.  Unfortunately, I did not set the conversation to public, so I wanted to recap the comments here, and then take this back to G+ for open discussions.

First, if you're new to this discussion, start by reading my previous post, and then check out David's post on combining the "Kill Chain" with the Pyramid of Pain.  For another look at this, check out David's Enterprise Security Monitoring presentation from BSidesAugusta - he talks about the kill chain, PoP, and getting inside the adversary's OODA loop.  Pay particular attention to David's "bed of nails" slide in the presentation.

Second, I wanted to provide a synopsis of the discussion from G+.  Those involved included myself, David, Jack, and Ryan Stillions...David brought him into the conversation initially because Ryan had developed a concept of "Detection Maturity Level" that overlaps with David's Pyramid concept.  Nothing is available yet, and hopefully Ryan will blog on it soon.

To start off the discussion, I asked that if finding, understanding and countering TTPs causes the adversary "pain", why is there so much emphasis within the community on finding indicators?  There was the thought that indicators are shared because that's what clients are looking and asking for, implying that those providing 'threat intel' services follow client requests, rather than driving them.  This goes back to maturity...in order to share TTPs, organizations have to be mature enough to (a) detect and find them, and (b) understand and employ them within their infrastructure.  There was another comment that indicators at the lowest levels of the PoP are focused on because there are more of them...a recent presentation at RSA 2014 mentioned "3000 indicators".  From a marketing perspective, that's much better than "TTPs for one group".

Ryan followed up with a comment that focusing on the lower levels of the PoP actually inflicts pain on the analysts (re: false positives), and he used the phrase "Cost of Context Reconstruction" (Ryan, start blogging, dude!!), which refers to the "lower in the stack you operate, longer it takes to re-establish situational context, arrive at conclusions, pivot, etc."

At that point, the discussion then moved to organizational maturity and people...skills, etc.  David recommended his above blog post and video, and I went off at that point to get caught up.

The question was then posed asking if attribution was important.  Ryan thought that would be a great panel question, and I agree...but I also think that this is a great question to start thinking about now, not simply to mature and crystallize your thoughts, but when it is posed to a panel, there are going to be a lot of folks who are hearing it for the first time.

What the discussion then centered around at that point was that attribution can be important, depending upon the context (if you're in the intel or LE communities), but for most organizations with a maturity level that has them at the lower levels of the Pyramid, attribution is a distraction.  What needs to be focused on at that point is moving further up the Pyramid and maturing the organization to the point where TTPs are understood, detected, and employed within the detection and response framework.

This then circled back to the "why", with "because that's what the client is asking for" thrown in as a possible response.  David brought up the concept of "provisional attribution" during the course of an incident, meaning that "this is what we know at the moment, but we may be wrong so it's subject to change at any time".

At that point, we got back to "hey, maybe we should open this up", hence, this post.  So, that's where we are at this point.  So, as a means of summary:

Use the Pyramid of Pain to:
- Identify detection/skill gaps
- Determine organizational detection/response maturity (looking for a blog post from Ryan...)
- Combine with the Kill Chain to bring "pain" to the adversary

There was also the idea of actually having a panel discussion at a conference.  I think that's great idea, but I also think that it's limiting...shelving the discussion until a conference means no movement, and then all of a sudden, there's a discussion that many folks are seeing for the first time, and they haven't had time to catch up.  So, we'll take this back to G+ for the time being, simply because at this point, there really hasn't been any better ideas for a forum for this sort of discussion.

Addendum: The G+ post with comments can be found here.

WFA 4/e

Okay, so Windows Forensic Analysis 4/e showed up in a couple of boxes on my doorstep tonight.  It's now a thing.  Cool.

As I write this, I'm working on finishing up the materials that go along with the book.  I got hung up on something, and then there was work...but the link will be posted very soon.

A question from Twitter from "Dark Operator":

so it is a version per version of Windows or the latest will cover 7 and 8?

I know the cover says "for Windows 8", and  I tried to incorporate as much info as I could about Windows 8 into the book by the time it went in for the final review before printing...which was back in February.  This edition includes all the Windows 7 information from the third edition, plus some new information (and some corrections), as well as some information for Windows 8.

The thing about questions like this is that Twitter really isn't the medium for them.  If you have a question or comment about the book contents, you can email me, or comment  here.  It's just that sometimes the answers to questions like that do not fit neatly in to 140 characters or less.

Over the past couple of months, I've been asked to speak at a number of events, and when I ask what they'd like me to speak about, I generally get responses like, "...what's new in Windows 8?".  The simple answer is...a lot.  Also, most folks doing DFIR work may not be completely familiar with what information is available for Windows 7 systems, so what could I say about Windows 8 in an hour that would be useful to anyone.  Some things (Jump Lists, the Registry, etc.) are very similar in Windows 8 as they are in Windows 7, but other things...the Registry, in particular...are different enough to pose some challenges to a good number of analysts.

So, once again...I'll be posting the link to the materials that go along with the book very soon.  I post them online because people kept leaving their DVDs somewhere (at home, at work, with a friend, in their car...) and needed a means for getting the download, so I moved it online.  This also allows me to update the materials, as well.

Questions?  Comments?  Leave 'em here, or email me.  Thanks so much.

Addendum: The book materials are posted here.

TTPs

Within the DFIR and threat intel communities, there has been considerable talk about "TTPs" - tactics, techniques and procedures used by targeted threat actors.  The most challenging aspect of this topic is that there's a great deal of discussion of "having TTPs" and "getting TTPs", but when you really look at something hard, it kind of becomes clear that you're gonna be left wondering, "where're the TTPs?"  I'm still struggling a bit with this, and I'm sure others are, as well.

I ran across Jack Crook's blog post recently, and didn't see how just posting a comment to his article would do it justice.  Jack's been sharing a lot of great stuff, and there's a lot of great stuff in this article, as well.  I particularly like how Jack tied what he was looking at directly into the Pyramid of Pain, as discussed by David Bianco.  That's something we don't see often enough...rather than going out and starting something from scratch, build on some of the great stuff that others have done.  Jack does this very well, and it was great to see him using David's pyramid to illustrate his point.

A couple of posts that might be of interest in fleshing out Jack's thoughts are HowTo: Track Lateral Movement, and HowTo: Determine Program Execution.

More than anything else, I would suggest that the pyramid that David described can be seen as a indicator of the level of maturity of the IR capability within an organization.  What this means is that the more you've moved up the pyramid (Jack provides a great walk-through of moving up the pyramid), the more mature your activity tends to be, and when you've matured to the point where you're focused on TTPs, you're actually using a process, rather than simply looking for specific data points.  And because you have a process, you're going to be able to not only detect and respond to other threats that use different TTPs, but you'll also be able to detect when those TTPs change.  Remember, when it comes to these targeted threats, you're not dealing with malware that simply does what it does, really fast and over and over again.  Your adversary can think and change what they do, responding to any perceived stimulus.

Consider the use of PSExec (a tool) as means to implement lateral movement.  If you're looking for hashes, you may miss it...all someone has to do is flip a single bit within the PE file itself, particularly one that has no consequence on the function of the executable, and your detection method has been obviated.  If a different tool (there are a number of variants...) is used, and you're looking for specific tools, then similarly, your detection method is obviated.  However, if your organization has a policy that such tools will not be used, and it's enforced, and you're looking for Service Control Manager event records (in the System Event Log) with event ID 7045 (indicating that a service was installed), you're likely to detect the use of the tool on the destination systems, as well as the use of other similar tools.  In the case of more recent versions of Windows, you can then look at other event records in order to determine the originating system for the lateral movement.

Book
Looking for Service Control Manager/7045 events is one of the items listed on the malware detection checklist that goes along with chapter 6 of Windows Forensic Analysis, 4/e.

When it comes to malware, I would agree with Jake's blog post regarding not uploading malware/tools that you've found to VT, but I would also suggest that the statement, "...they create a new piece of malware, with a unique hash, just for you..." falls short of the bigger issue.  If you're focused on hashes, and specific tools/malware, yes, the bad guy making changes is going to have a huge impact on your ability to detect what they're doing.  After all, flipping a single bit somewhere in the file that does not affect the executionof the program is sufficient to change the hash.  However, if you're focused on TTPs, your protection and detection process will likely sweep up those changes, as well.  I get it that the focus of Jake's blog post is to make the information more digestible, but I would also suggest that the bar needs to be raised.

Uploading to VT
One issue not mentioned in Jake's post is that if you upload a sample that you found on your infrastructure, you run the risk of not only letting the bad guy know that his stuff has been detected, but more than once responders have seen malware samples include infrastructure-specific information (domains, network paths, credentials, etc.) - uploading that sample exposes the information to the world.  I would strongly suggest that before you even consider uploading something (sample, hash) to VT, you invest some time in collecting additional artifacts about the malware itself, either though your own internal resources or through the assistance of experts that you've partnered with.

A down-side of this pyramid approach, if you're a consultant (third-party responder), is that if you're responding to a client that hasn't engineered their infrastructure to help them detect TTPs, then what you've got left is the lower levels of the pyramid...you can't change the data that you've got available to you.  Of course, your final report should make suitable recommendations as to how the client might improve their posture for responding.  One example might be to ensure that systems are configured to audit at a certain level, such as Audit Other Object Access - by default, this isn't configured.  This would allow for scanning (via the network, or via a SIEM) for event ID 4698 records, indicating that a scheduled task was created.  Scanning for these, and filtering out the known-good scheduled tasks within your infrastructure would allow for this TTP to be detected.

For a good example of changes in TTPs, take a look at this CrowdStrike video that I found out about via Twitter, thanks to Wendi Rafferty.  The speakers do a very good job of describing changes in TTPs.  One thing from the video, however...I wouldn't think that a "new approach" to forensics is required, per se, at least not for response teams that are organic to an organization.  As a consultant, I don't often see organizations that have enabled WMI logging, as recommended in the video, so it's more a matter of a combination of having an established relationship with your client (minimize response time, maximize available data), and having a detailed and thorough analysis process.

Regarding TTPs, Ran2 says in this EspionageWare blog post, "Out of these three layers, TTP carries the highest intelligent value to identify the human attackers."  While being the most valuable, they also seem to be the hardest to acquire and pin down.

What's Up?

TTPs
A bit ago, I ran across this fascinating blog post regarding the Pyramid of Pain.  Yes, it's over a year old, but it's still relevant today.

For one thing, back when I was doing PCI exams (while a member of the IBM ISS ERS team), Visa would send us these lists which included file names (no paths) and hashes...we had to search for them in every exam, so we did.  While I could see the value in the searches themselves, I felt at the time that Visa was sitting on a great deal of valuable intelligence that, if shared and used properly, could not only help us with our analysis, but could also be used to protect the victim merchants.  After all, if we knew more about how the bad guys were getting in and how they were targeting specific systems (TTPs), we could help prevent and detect such things.  As such, it was validating to see someone else discuss the value of such things.

Over the years, I've heard others talk about things like attribution, when it came to "APT" (I apologize for using that term...).  In fact, at one conference in particular, the speaker talked about how examples of code could be used for attribution, but shortly thereafter stated that the code could be downloaded from the Internet, and that various snippets could be pasted together to form working malware.

Indicators
In his recent RSA Confernce State of the Hack talk, Kevin Mandia said that in the APT1 report, 3000 indicators were released...he mentioned domains and IP addresses, specifically.  Those are pretty low on the pyramid.

I have to agree that tools don't make the threat group, as many seem to be using the same tools.  In fact, it seems that a lot of the tools used for infrastructure recon are native tools...so which group gets the attribution?  Microsoft?  ;-)

Every time I read over the blog post, I keep coming back to agreeing with what the author says about TTPs.  Once you're to the point of detecting behaviors, you're no longer concerned with things like disclosure (public or otherwise) resulting in an adversary changing/adapting their tactics...because now, rather than focusing on individual data points, you have a process in place.  In particular, that process is iterative...anything new you learn gets rolled right back into the process and shared amongst all responders, thereby improving the overall response process.  What you want to do is get to the point where you stop reacting to the adversary, and instead, they react to you.

RegRipper EnScript
I recently found out that someone is selling an EnScript to tie RegRipper into EnCase.  Some tweeted questions about how I felt about it, if I was receiving royalties, and asking if it "violated the GPL"...which, honestly, I didn't understand, as the license file in the archive specifies the license.  Why ask me if the answer is right there?

Since Twitter really isn't the medium for this sort of thing (and I honestly have no idea why so many people in the DFIR community restrict themselves to that medium), I thought I'd share my thoughts here.  First, others are making money off of free software, in general, and a few are doing so specifically with RegRipper...so why is this particular situation any different?  The GPL v3 quick guide states, in part, that users should have the freedom to "use the software for any purpose".  It further goes on to state that free software should remain free...and in this case, it would appear that RR remains free, and the $15 pays for the EnScript.  As such, I'm wouldn't think that selling the EnScript violates anything.

Second, this is clearly an attempt to bring the use of RR to users of EnCase.  I've never been a big fan of EnCase, but I realize that there are a number of folks who are, and that many specifically rely on this software.  My original purpose for releasing RegRipper was to put it out in the community for others to use and improve upon...well, that second part really hasn't happened to a great extent, and I don't see this EnScript either taking anything away from RegRipper, or adding anything to it.

RegRipper
I'm not saying that no one has offered up ways for improving RegRipper...some have. Not long ago, I received a plugin from someone, and Corey Harrell submitted one just the other day. I've had exchanges recently with some folks who have had some thoughtful suggestions regarding how to improve RegRipper, and perhaps make it more useful to a wider range of users. All I'm saying is that it hasn't happened to a great extent; some of the improvements and updates (inclusion of alerts, RLO plugin, etc.) are things I've added for my own benefit, and I don't want to maintain two disparate source trees.

Does this mean that more people are likely to use it?  Hhhhhmmmm...maybe.  Folks who go this route are likely going to go the same route as most of the folks who already use RegRipper, either by downloading it or using it as part of a consolidated distribution.  That is to say, they're just going to just blindly run all plugins against the hives that they have available, and it's unlikely that there're going to have any ideas for new plugins (or tool updates or improvements as a whole) coming from this crowd.

So, in short, I don't see how this EnScript is a violation of anything...it's no different from what others are doing, and RegRipper itself remains free.  Further, it takes nothing away from RegRipper, nor adds anything to it.

Finally, Jamie had a good point on Twitter...if you don't want this to happen, don't put stuff out there for free.  Point well taken.

Speaking of which, I had an email exchange with Jamie and Corey Harrell recently, where we discussed some well-considered possible future additions to RegRipper.

Book
Windows Forensic Analysis 4/e is due to be released soon...I need to complete the archive of materials that go along with the book and get it posted.  As soon as that's done, I will start working on the possible additions to RegRipper.

Malware Detection
Speaking of WFA 4/e, one of the chapters I kept was the one on Malware Detection.  Not long ago, I was following the steps that I had laid out in that chapter, and I found that the system had McAfee AV installed.  So, per my process, I noted this to (a) be sure that I didn't run the same product against the image (mounted as read-only volume) and (b) look for logs and quarantined items.

It turns out that when McAfee AV quarantines an item, it creates a .bup file, which follows the MS CFB file format.  This Open Security Research blog post is very helpful in opening the files up, in part because it points to this McAfee Knowledge Center article on the same topic.

Some additional resources:
Punbup - Python script for parsing BUP files
Bup-parse - Enscript for parsing BUP files
McBup - Another Python script that may be useful

Conferences
I'll be speaking at a couple of conferences here in the near future.  I'm giving two presentations at the USACyberCrime Conference (formerly known as the DoD CyberCrime Conference, or DC3) at the end of April.  My presentations will be "APT sans Malware", and "Registry Analysis".  It's unlikely that I will be posting the PPTXs for these, as I'm not putting everything I'm going to say in bullets in the slides...if I did, what would be the point of me actually speaking, right?

Thanks to Suzanne Widup, I'll be speaking on the author's panel at the SANS Forensics Summit in Austin, TX, in June.  This is something new, and something I'm looking forward to.  Not getting feedback from the community regarding what they'd like to see or hear in a presentation, I've backed away somewhat from submitting presentations to CfPs that are posted.  One of my go-to presentations is Registry Analysis, in part because I really believe that it's a critical component of Windows forensic analysis, and also because I'm not sure that analysts are doing it correctly.  However, I've been told that I need to present on something else...but not what.  Also, the panel format is more free-form...I was on a panel at one of the first SANS Forensic Summits, and if you've attended any of the Open Memory Forensic Workshops, you've seen how interesting a panel can be.