The Question of "whodunnit?"
One of the questions that comes up from time to time during an examination is "whodunnit?" Take an examination involving, let's say...illicit images. The accused claims that they didn't do it, so the question becomes, who did? Sometimes the answer might be that someone else sat at the keyboard of the computer and performed the actions that lead to the images being on the system, and in other cases, the answer might be that the images were the result of a remote attacker/hacker or malware. The latter is sometimes referred to as the Trojan Horse Defense, or malware defense. In 2003, this guy used the malware defense and was acquitted of breaking into gov't computer systems...his claim was that someone had hacked his system and then launched the attack. From the article:
A forensic examination of Mr Caffrey's PC had found no trace of a hidden program with the instructions for the attack.
And yet, he was still acquitted. Since then, this has been a concern to many a forensic examiner and law enforcement officer...what happens if the accused makes that claim? How can a forensic examination corroborate that claim, or disprove it all together?
First, let me say that there is no 100% certainty in every examination that any or all of these techniques are going to work. There are certain things that computer forensic analysis will not reveal...one of them being things that simply are not there (ie, an analyst cannot find CCNs or artifacts of an intrusion if there simply are none to be found). However, what I'd like to discuss is some of the finer points of technical forensic analysis that can provide a good deal of information, such that the proper authorities (counsel, jury, etc.) have a better foundation on which to base their decision.
One of the areas of incident response that we're moving into fairly rapidly now...this area has been picking up steam a good bit lately since its introduction in 2005...is the collection and analysis of physical memory. In just about a week, the OMFW will occur and there will be a good number of folks presenting on and discussing this topic. There are a number of tools available now that will allow a responder to dump the contents of physical memory from a Windows system (XP, as well as Vista), and then analyze that dump...locate running processes, network connections, etc. In addition, PTFinder (Andreas appears to be attending OMFW) may still allow the examiner to identify exited processes (lsproc does this for Windows 2000 and can be ported to other versions of Windows)...procL from ScanIT appears to do something similar. A number of other articles provide information on retrieving image files, Registry keys, and even Event Log records from a physical memory dump. Further, a recent print issue of Linux Pro Magazine has an article on pg. 30 entitled Foremost and Scalpel: Restoring deleted files, in which the authors state, "Foremost and Scalpel ignore the filesystem and can even restore data from RAM dumps and swap files."
Within the realm of computer forensic analysis, there are a number of areas of a Windows system in which artifacts indicating user activity may be found. These go beyond the traditional examination of browser history artifacts, etc., and can provide indications of user activity, as well as historical indications of when the user was logged into the system. Windows Event Log and Registry analysis are two of these areas, along with the overall correlation of artifacts from different parts of the system...the more artifacts that the examiner is able to pull together, the more complete a picture that can be developed.
For example, for a backdoor to be useful to an intruder, it has to remain persistent (see Jesse Kornblum's paper, Exploiting the Rootkit Paradox with Windows Memory Analysis) across reboots. There are only so many ways this can occur, with persistent stores being primarily within the Registry and the file system. Using tools such as RegRipper, the persistence mechanisms with the system and user Registry hive files can be displayed, and the file system persistence mechanisms can be viewed, as well, for any indications of suspicious entries.
The Windows Registry holds a wealth of information about software applications installed on the system. Some of this information differentiates between those apps run by the user, and those run automatically by the system. In addition, the applications themselves have traces and artifacts...antivirus applications generally maintain configuration information in addition to log files. The Windows firewall installed on XP and above maintains it's configuration information in the Registry. Many GUI applications...to include image and movie viewing apps...maintain lists of files that have been opened and viewed by those applications.
Knowing where to look and what to look for can give the analyst the ability to paint a very detailed picture of what occurred on the system. Windows XP is something of a fickle lover, as it will provide the knowledgeable examiner with a wealth of information, while at the same time using it's own inherent anti-forensic techniques to deprive more traditional examiners of those artifacts on which they traditionally rely. Remember Harlan's Corollary to the First Law of Computer Forensics?
The great thing about all this is that while it may appear to be magical, requiring knowledge beyond the reach of all but a few individuals...that's simply not the case at all. All of this can be incorporated into the examiner's forensic analysis process and methodology.
So, the question isn't, was there or was there a Trojan or backdoor on the system what was responsible for this activity...it's now, do you want to answer the Trojan Defense before you walk into the interview room with the defendant and their attorney?
Resources:
Ex Forensis post
A forensic examination of Mr Caffrey's PC had found no trace of a hidden program with the instructions for the attack.
And yet, he was still acquitted. Since then, this has been a concern to many a forensic examiner and law enforcement officer...what happens if the accused makes that claim? How can a forensic examination corroborate that claim, or disprove it all together?
First, let me say that there is no 100% certainty in every examination that any or all of these techniques are going to work. There are certain things that computer forensic analysis will not reveal...one of them being things that simply are not there (ie, an analyst cannot find CCNs or artifacts of an intrusion if there simply are none to be found). However, what I'd like to discuss is some of the finer points of technical forensic analysis that can provide a good deal of information, such that the proper authorities (counsel, jury, etc.) have a better foundation on which to base their decision.
One of the areas of incident response that we're moving into fairly rapidly now...this area has been picking up steam a good bit lately since its introduction in 2005...is the collection and analysis of physical memory. In just about a week, the OMFW will occur and there will be a good number of folks presenting on and discussing this topic. There are a number of tools available now that will allow a responder to dump the contents of physical memory from a Windows system (XP, as well as Vista), and then analyze that dump...locate running processes, network connections, etc. In addition, PTFinder (Andreas appears to be attending OMFW) may still allow the examiner to identify exited processes (lsproc does this for Windows 2000 and can be ported to other versions of Windows)...procL from ScanIT appears to do something similar. A number of other articles provide information on retrieving image files, Registry keys, and even Event Log records from a physical memory dump. Further, a recent print issue of Linux Pro Magazine has an article on pg. 30 entitled Foremost and Scalpel: Restoring deleted files, in which the authors state, "Foremost and Scalpel ignore the filesystem and can even restore data from RAM dumps and swap files."
Within the realm of computer forensic analysis, there are a number of areas of a Windows system in which artifacts indicating user activity may be found. These go beyond the traditional examination of browser history artifacts, etc., and can provide indications of user activity, as well as historical indications of when the user was logged into the system. Windows Event Log and Registry analysis are two of these areas, along with the overall correlation of artifacts from different parts of the system...the more artifacts that the examiner is able to pull together, the more complete a picture that can be developed.
For example, for a backdoor to be useful to an intruder, it has to remain persistent (see Jesse Kornblum's paper, Exploiting the Rootkit Paradox with Windows Memory Analysis) across reboots. There are only so many ways this can occur, with persistent stores being primarily within the Registry and the file system. Using tools such as RegRipper, the persistence mechanisms with the system and user Registry hive files can be displayed, and the file system persistence mechanisms can be viewed, as well, for any indications of suspicious entries.
The Windows Registry holds a wealth of information about software applications installed on the system. Some of this information differentiates between those apps run by the user, and those run automatically by the system. In addition, the applications themselves have traces and artifacts...antivirus applications generally maintain configuration information in addition to log files. The Windows firewall installed on XP and above maintains it's configuration information in the Registry. Many GUI applications...to include image and movie viewing apps...maintain lists of files that have been opened and viewed by those applications.
Knowing where to look and what to look for can give the analyst the ability to paint a very detailed picture of what occurred on the system. Windows XP is something of a fickle lover, as it will provide the knowledgeable examiner with a wealth of information, while at the same time using it's own inherent anti-forensic techniques to deprive more traditional examiners of those artifacts on which they traditionally rely. Remember Harlan's Corollary to the First Law of Computer Forensics?
The great thing about all this is that while it may appear to be magical, requiring knowledge beyond the reach of all but a few individuals...that's simply not the case at all. All of this can be incorporated into the examiner's forensic analysis process and methodology.
So, the question isn't, was there or was there a Trojan or backdoor on the system what was responsible for this activity...it's now, do you want to answer the Trojan Defense before you walk into the interview room with the defendant and their attorney?
Resources:
Ex Forensis post