Having recently posted on counter-forensics, I wanted to use that as a means for illustrating the need for immediate response.  As discussed previously, one way to address the use of counter-forensics techniques or measures is by having knowledgeable analysts available.  Another way to address these measures, particularly when you include the activities of an operating system and it's applications over time as a counter-forensics measure, is through the use of immediate response, particularly by knowledgeable responders.  Immediate response is something I've thought about a lot, and feel strongly enough about that it consumes an entire chapter of WFAT3e. 

The use, and understanding, of counter-forensics measures is where an immediate response capability comes in...the sooner you detect and respond to something 'unusual', the more likely you are to be able to access and recover pertinent data.  Why is that?  Well, as we've said, computer systems are very active things, even when all we can see is a nice desktop with the mouse pointer just sitting there.  Of all of the systems, Windows are probably the most active, with a considerable amount of activity going on under the hood.  What this means is that anything that's deleted (cookies, Event Log records, files, etc.), and those sectors are available for re-allocation, will likely fall victim to the 'counter-forensics' measures "built into" the operating system.

What am I talking about?  Anyone remember Windows XP?  What happens, by default, every 24 hours on a Windows XP system?  A Restore Point is created...and that can be a LOT of new files being created and lot of previously unallocated sectors being consumed.  As new files are created, older ones may be deleted.  And then every three days, there's a limited defrag that runs.  Windows 7 is subject to similar activity...and in some cases, more so.  Windows 7 ships with a LOT of default Scheduled Tasks that do things like backup the main Registry hives every 10 days, consuming previously unallocated sectors.  When you edit MSOffice files, temporary copies of the files are created, consuming previously-unallocated sectors, and then the temp file is 'deleted' when you close the application.  As such, there's a lot that goes on on a Windows system that we don't even see or even think about.  How about Windows Updates?  Do you use iTunes or QuickTime?  When those applications are installed, a Scheduled Task is created to run on a regular basis to look for updates, and these can be installed automatically. 

As such, the key to a modern response capability, beyond having knowledgeable responders and analysts, is to maintain a proactive security posture the employs early detection and immediate response.  One way to achieve both is through the use of Carbon Black.  (For the sake of full disclosure, I should tell you that my employer is a Cb reseller, but anyone who's followed my blog or read my books knows that my endorsement of Cb predates my current employment.)  Cb is a tool that can be used to solve a lot of problems, but from the perspective of early detection and immediate response, it's invaluable.  From a detection perspective, once you have Cb up and running in your enterprise (before an incident occurs, hence 'proactive security'), you can issue queries on a regular basis that look for the execution of 'new' (haven't been seen before) applications.  Remember the counter-forensics techniques previously mentioned in this post?  The technique itself requires code to be run, meaning that something has to execute, something that Cb can detect and report on.  Or, you may detect an incident through other means...log monitoring, user notification, etc., and Cb can be used to quickly gather more information about the incident, allowing an analyst to drill down into things like parent processes (from where did the malware originate?), file modifications (which files did the malware write to?), etc.  Once IOCs have been identified, scoping can take place quickly, from a central location, allowing analysts to determine how many of the monitored systems are affected, and then execute immediate actions in response to the incident.

The alternative (and in many cases, currently employed) approach is to, once an event has been identified, provide incomplete information to senior management, so that they can begin shopping around for a consulting firm that provides response services.  While this is going on, we would hope that no one is doing anything on the systems (this isn't often the case) in question, but as we know, as time passes, things do happen all on their own.  When a response firm is finally selected, additional time is required for contract negotiations, the responders need to travel on-site, and then they need to begin working with you to understand your infrastructure and scope the incident...all while data is (potentially, probably, most likely) leaving your infrastructure.

Consider this...is your organization subject to any compliance regulations or legislature?  Many that are have little choice in notification reporting...if you cannot explicitly show which records were exposed, you have to report on ALL records that were potentially exposed.  Which would you rather do...report on the records that were exposed, or report on all records that may potentially have been exposed (because you don't know)? 

After all, "knowing is half the battle!"  Did you see what I did there, with the quote, and the "GI Joe" image?  This also serves another purpose...one of the things that military folks are trained in is "immediate actions"...stuff that you're trained over and over in, so that when the situation arises for you to use that skill, your response is immediate and instinctual, based on muscle memory.  That same concept can be easily applied to the need for immediate incident response, as well.  Many security events can be quickly investigated and either deemed non-events, or escalated for a more thorough investigation.  Why is it that many organizations simply wipe a system on which suspicious activity has occurred, and reload the operating system?  Because it's the easiest thing to do...they have the installation media right there.  It's their "immediate action".  So, what if you were able to replace that with a new immediate action...pre-stage the necessary tools for dumping memory and acquiring an image, and providing the training so that it becomes easy to do?

So...in summary, on the surface, counter-forensics techniques may appear to pose significant challenges for analysts, but the fact is that many of those challenges can be overcome through early detection, and immediate response by knowledgeable analysts and responders.  The more pertinent information that is available to responders and analysts through early detection will significantly impact that immediate response, taking you from "something happened on a bunch of systems" to "this is what happened, and only these systems were affected", drastically reducing the impact of an incident to your infrastructure.

A recent SANS Forensics Blog 'Case Leads' post pointed me to a Hexacorn blog post that "...presents several techniques used to prevent forensic analysis."  That statement is a bit too succinct and just a little bit misleading, as the techniques presented in the Hexacorn blog post don't do anything to prevent analysis...rather, they're counter-forensics techniques intended to make analysis a bit more difficult.  However, many analysts are aware that deleting cookies and clearing Event Logs really doesn't do a whole lot more that just alter where you go to get the information you're looking for.  I didn't bring this up simply to say that, and I'm not bashing the Hexacorn guys.  Nor am I suggesting in anyway that the information they've provided isn't useful...for reasons I've already mentioned, it's very valuable information.  But there are two very important principles to keep in mind when it comes to digital analysis that play an important role when discussing such techniques...Locard's Exchange Principle, and "the absence of an artifact where you expect to find one is itself an artifact."

Sidebar:
I should point out that at the Blackhat conference in 2005, James Foster and Vincent Lui gave a presentation that covered "log manipulation and bypassing forensics".  Attendees were invited to join "the speakers in a lively discussion of the “Top 10 Ways to Exploit a Forensic Examiner”", so the approach of targeting the analyst and their training via counter-forensics techniques is nothing new.
/end sidebar

So what am I talking about?  We know from Locard that any interaction between two physical objects is going to have an effect on both of those objects (including a transfer of material between them, if they come into contact), and we know that the same is true in the digital realm.  Therefore, it stands to reason that attempts at counter-forensics are going to themselves constitute an interaction (something will have to execute in order to perform some of these techniques), either between malware and the eco-system in which it's running, or between an intruder and the system they've compromised.  As such, the execution of the counter-forensic technique will have an effect on the environment in which it's being executed.

I've analyzed systems on which a user had no RecentDocs key in their NTUSER.DAT...not that it wasn't populated, it simply wasn't there.  This told me something...and I found out how it was deleted, what was used to delete it (via RegRipper and timeline analysis), when it was deleted, and what the deleted content was (via regslack).  However, had I not known that not having a RecentDocs key was an artifact, I might never have looked.  The same is true for malware found to be using the WinInet API for off-system communications...no artifacts were found in the index.dat file for the user profile that the malware was run under, and that in itself was an artifact.  This led to further analysis that determined why that was the case.  In other situations, cleared Event Logs from Windows XP and 2003 systems have been easily retrieved from unallocated space.

Now, data recovery such as this isn't necessarily going to be of value, or even viable, for all counter-forensic techniques.   Securely wiping a file will make it gone-gone...you may find little bits and pieces of the file, small portions of it as it existed at one time, or you may find indications that a user accessed the file, but if your analysis goals center around the actual contents of the file itself, some counter-forensic techniques may obviate analysis. 

One method that we've seen in recent years to perform counter-forensics is that intruders have minimized their interactions with compromised systems; however, this does not completely obviate that interaction, it simply minimizes it.  Want to do some stuff on the system or network to which it's attached, and minimize your footprint?  Use native tools.  Want to hide your activities?  Make them look as much like normal system activities, and delete your tools and the data repositories that you create...Windows systems are very "noisy" when it comes to system activity, and given everything that occurs under the hood, your deleted files may very well be overwritten and obfuscated in fairly short order.  (Note: this is why I wrote an entire chapter on Immediate Response in WFAT3e...the sooner you respond to an incident, the better data you're likely to get.)

Sidebar:
One thing I do disagree with, with respect to the Hexacorn post, is the reason given for not discussing NTFS alternate data streams (ADSs); "...because it’s quite common and hard to find good keywords".  While the use of ADSs in malware (PoisonIvy) may be 'quite common', the value of analyst's knowing about them and understanding how they're used is a matter of perspective.  I've been in rooms full of analysts and responders, and not been able to get more than maybe one or two of them to admit that they've even heard of ADSs.  If you're a malware analyst and used to seeing the use of ADSs all the time in the samples that you're looking at, and you think that they are nothing new and pretty trivial, consider the number of organizations that don't do any sort of root cause analysis on supposedly-infected systems, where the routine is to wipe and re-install the OS and data.  In these cases, no one is looking for ADSs, in part because they aren't even aware that they could exist.  As such, intrusions or malware that use ADSs may go unnoticed for quite some time.

So, if we're saying that ADSs are 'common' and therefore not worth addressing, I think that we're really missing an opportunity here to not only raise awareness, but to also start developing some trending information with respect to the use of such artifacts.  If a malware analyst sees "a lot" of samples that use ADSs in some capacity, how many is that out of the total amount of malware they're examining?  Is that more or less than last year, or last month?  Instead of samples, look at families...how pervasive is the use of ADSs across families?

As to the keywords comment...forgive the poetic license, but to paraphrase the Bard, "...there are more things on heaven and earth than are dreamt of in your keyword lists."  Keyword searches are a useful tool, don't get me wrong...but they are not the be-all, end-all of digital analysis.  As with any other tool, keyword searches should be employed thoughtfully, and doesn't work for everything.
/end sidebar

One thing to keep in mind when analyzing Windows systems is that Windows has it's own, built-in counter-forensics "measures"...I hesitate to call them that because I don't believe that it's intentional, but the fact is that a lot of what makes Windows useful to a user can also serve as counter-forensics measures.  What I mean by that is this...let's say an intruder accesses a system remotely and "does some things".  If the intruder were to delete some files or indications of their actions, well, we know that "deleted" isn't really gone, it's just hidden until it's overwritten.  Have you ever looked at what a Windows system does when it just sits there, with nothing happening on the monitor?  Stuff goes on...the OS and applications may be updated, Restore Points are created and deleted, limited defrags are run on a scheduled basis, etc.  Now, let's say that the intruder deletes a key file, but the user's on their system, going about their regular work.  Open a Word doc, an Excel spreadsheet, or open that PowerPoint presentation to update some of your slides, and the Office applications will create a tempoorary file...which consumes unallocated sectors.  NTFS MFT records are reused.  With all of this activity, all that it may take to make a deleted file completely unrecoverable is to wait a day or two.  This is really more of an argument for immediate response, which is an entirely different discussion (and blog post) but it fits in here as a counter-forensics measure.

So, in short, the intentional use of counter-forensics techniques will leave traces on the system,which may appear in some cases as a glaring absence of data.  Some counter-forensics techniques are specifically tailored  toward subverting the training and knowledge of the analyst.  A knowledgeable analyst will employ an analysis process, and as such be able to recognize and adapt to the use of such techniques.  But nothing that we do is ever absolute...securely wiping a file will mean that you likely won't be able to recover that file, if that's the goal of your analysis.  You may be able to locate remnants of temporary versions of the file (some applications create temporary copies of files while they're being edited), or you may find indications that a user interacted with a file of that name (through Registry or Jump List analysis).  Some techniques may truly make specific data unrecoverable...but there will very likely be traces of that activity, and that fact can be used in cases of spoliation.