Convergence
At times, there appear be a number of different sub-disciplines within the DFIR community, and those of us in that community may tend to separate ourselves based on somewhat arbitrary distinctions. However, when I sit back and think about such things, it occurs to me that these separations are really just obstacles to our own overall success, and do nothing whatsoever to strengthen any one sub-discipline. Instead, these divisions tend to weaken us all.
I once had a law enforcement official tell me, "You do intrusion and malware investigations, we do CP and fraud cases." At first, I thought...uhm...okay. But as I thought more about what he'd said, I began to think, what happens in a CP case when the accused claims the "Trojan Defense"? Doesn't it then become something of a malware case? If a Trojan or other malware is discovered during an exam, do we assume that it was, in fact, the culprit, or do we perform additional analysis to determine its capabilities, and whether or not it even executed?
The same can be said with respect to other issues, and spoliation is a great example. Melia recently blogged about a case experience, and even gave an excellent DFIROnline presentation, during which she discussed certain aspects of an exam that involved spoliation. Her issue involved determining the use of CCleaner, yet many of those skills she used to resolve the case could be easily used in other areas...especially the part about Registry analysis.
Another example of a spoliation exam can involve the defrag utility on Windows, as the use of this utility following a preservation order can be seen to be a violation of that order. After all, we all know that deleting a file doesn't necessarily make it gone, but defragging the hard drive after deleting the file can make that file much harder to recover. During such an exam, the analyst might find a Prefetch file for the defrag utility and determine that it had been run in violation of the order...but had it? Windows XP, by default, runs a limited defrag (see the "Prefetch" section of this page) every three days. Windows 7 includes a Scheduled Task for running the defrag utility every Wednesday...and examining the Application Event Log, you can look for events with source "Defrag" and ID 528 to see the status of some of the defrag runs. You'll also want to check the UserAssist subkeys for indications of the user launching the defrag utility, in order to separate default system behavior from intentional actions performed by the user.
Like other examinations, spoliation cases aren't isolated to their own group of specialists. I've been involved in CP cases where the first step was to address the Trojan Defense, and then the issue of counter-forensics techniques being used. In this case, the convergence with spoliation exams came in through the examination of user activities...in this case, a user had run an older version of WindowWasher and deleted several artifacts, to include the RecentDocs key (the entire key, not just the subkeys) from the NTUSER.DAT hive for the account. In this particular case, the anomaly was found via RegRipper, and determined to be the result of explicit actions taken by the user.
The same can be said for PCI forensic assessments...there are a lot of skills involved in such things that translate to other areas of the DFIR community. Don't believe me? Check out Chris's Core Duo post, and be sure to catch Chris's Sniper Forensics v3 presentation at the SANS Forensic Summit in Austin, TX, this summer.
So let's not isolate ourselves with the arbitrary distinctions. Instead, share what keeps you up at night with others within the community, as doing so will likely result in some innovative and interesting solutions.
I once had a law enforcement official tell me, "You do intrusion and malware investigations, we do CP and fraud cases." At first, I thought...uhm...okay. But as I thought more about what he'd said, I began to think, what happens in a CP case when the accused claims the "Trojan Defense"? Doesn't it then become something of a malware case? If a Trojan or other malware is discovered during an exam, do we assume that it was, in fact, the culprit, or do we perform additional analysis to determine its capabilities, and whether or not it even executed?
The same can be said with respect to other issues, and spoliation is a great example. Melia recently blogged about a case experience, and even gave an excellent DFIROnline presentation, during which she discussed certain aspects of an exam that involved spoliation. Her issue involved determining the use of CCleaner, yet many of those skills she used to resolve the case could be easily used in other areas...especially the part about Registry analysis.
Another example of a spoliation exam can involve the defrag utility on Windows, as the use of this utility following a preservation order can be seen to be a violation of that order. After all, we all know that deleting a file doesn't necessarily make it gone, but defragging the hard drive after deleting the file can make that file much harder to recover. During such an exam, the analyst might find a Prefetch file for the defrag utility and determine that it had been run in violation of the order...but had it? Windows XP, by default, runs a limited defrag (see the "Prefetch" section of this page) every three days. Windows 7 includes a Scheduled Task for running the defrag utility every Wednesday...and examining the Application Event Log, you can look for events with source "Defrag" and ID 528 to see the status of some of the defrag runs. You'll also want to check the UserAssist subkeys for indications of the user launching the defrag utility, in order to separate default system behavior from intentional actions performed by the user.
Like other examinations, spoliation cases aren't isolated to their own group of specialists. I've been involved in CP cases where the first step was to address the Trojan Defense, and then the issue of counter-forensics techniques being used. In this case, the convergence with spoliation exams came in through the examination of user activities...in this case, a user had run an older version of WindowWasher and deleted several artifacts, to include the RecentDocs key (the entire key, not just the subkeys) from the NTUSER.DAT hive for the account. In this particular case, the anomaly was found via RegRipper, and determined to be the result of explicit actions taken by the user.
The same can be said for PCI forensic assessments...there are a lot of skills involved in such things that translate to other areas of the DFIR community. Don't believe me? Check out Chris's Core Duo post, and be sure to catch Chris's Sniper Forensics v3 presentation at the SANS Forensic Summit in Austin, TX, this summer.
So let's not isolate ourselves with the arbitrary distinctions. Instead, share what keeps you up at night with others within the community, as doing so will likely result in some innovative and interesting solutions.