Sunday, August 03, 2008

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 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 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 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's now, do you want to answer the Trojan Defense before you walk into the interview room with the defendant and their attorney?

Ex Forensis post

1 comment:

Anonymous said...

The Trojan defense, insofar as cp is concerned, is way overblown. When used sucessfully, it's most apt to occur when the prosecution did not do an adequate exam, or have access to resources that could have accomlished that task. As an example, I'll cite the recent government employee case, where we both read the defense report. I, and folks much smarter than I, found several issues in the defense report that could have been addressed by better preparation.

There's also the UK case in which the defendant was acquitted because malcode might have existed in u/c. I don't believe that its existence was proven, only that it was possible. I can't tell you how many times I've been asked by opposing counsel, "Isn't it possible that [defense du jour] caused...?" I was quite pleased when our USDC Judge told defense counsel to present evidence next time, instead of conjecture.

For the time being, my LE colleagues and I are extremely unlikely to gain access to a live system. (We've chatted about this on your blog before.) So, we should do the best that is possible, post mortem. You know the drill better than I. We scan the target system, track the capabilities of found threats, and run a VM to see what goes on when the machine fires up and runs for a while. We also can run some additional tools in a VM, e.g., Rootkit Revealer. We can analyze VM RAM, which may present some analogies to a live acquisition.

You have to consider the evidence found on an image before becoming too concerned about the trojan defense. I'm going to worry less in a case the has 200 user creared folders bearing fruits of the crime. I struggle more with cache cases, at least until I find a host of evidence indicating the intent to "{seek and find."

My remarks are most appropriate to typical cp cases, which seem to draw the most attention to the trojan defense. Perhaps they're overly simplistic to a response to a intrusion or other incident. However, given a dead system, perhaps we're in the same shoes from the start.