Counter-Forensics
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.
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.