COMPSCI 365/590F

Digital Forensics (Spring 2018)

Overview

Syllabus

Schedule

Assignments

17: Trojan Horse Defense; Windows Forensics

DRAFT

Announcements

We’re going to talk about the Trojan Horse defense today, then switch gears to cover the start of Windows forensic analysis.

But first we’ll go over midterm 2 quickly, since I’ve gotten several requests to do so.

Midterm 2 review

(on projector / board)

The Trojan Horse Defense

A technological variant of the SODDI defense, where the defendant in a computer crime case claims that their computer was under the control of malware when “it” committed a crime.

Notable case occurred on September 20, 2001 (near a significant date in US history) when allegedly Aaron Caffrey engaged in a DoS on a webserver in Port of Houston. He claimed the evidence

was planted on his machine by attackers who used an unspecified Trojan [horse program] to gain control of his PC and launch the assault.

A forensic examination of Caffrey’s PC found attack tools but no trace of Trojan infection.

He was acquitted after only a few hours deliberation (after essentially acting as his own expert witness), after the jury was convinced that

a [T]rojan horse armed with a ‘wiping tool’ was responsible, enabling the computer to launch the DoS attack, edit the system’s log files, and then delete all traces of the trojan — despite prosecution claims that no such technology existed.

Several other cases:

  • UK defendant Julian Green acquitted in CP case, based upon expert testimony that 11 trojans were on his computer. (2003)
  • UK prosecutors dismissed charges against Karl Schofield after finding a trojan on his computer. (2003)
  • In the US, Eugene Green (accountant) successfully claimed that a virus caused the $630k underreporting of his own income that prosecutors charged him with. Acquitted (despite the fact the virus apparently never modified returns he prepared for others).

Trojans present a unique challenge to prosecution in the US, as the “beyond a reasonable doubt” standard can be difficult to meet, especially if the defense can raise the possiblity of a computer being remote-controlled by SOD.

SODDI is often rebutted by motive and lack of alternative suspects (but seriously, Green?), but sometimes this can be difficult when the crime is less personalized.

First, note it’s potentially a real thing: as evidence, look at botnets and extortionware (“your files are encrypted, send BTC to this address to get the decryption key”).

The THD can work as follows:

  • The defendant can claim no knowledge of the crime. Reasonable doubt is raised because SODDI.
  • The defendant can claim he may have committed the actions (actus reus) of the crime, but done so unknowingly (mens rea). To convict for many crimes, prosecution must show both. (Green the accountant used this version of the THD).
  • In either case, the defense usually also claims technological naivete, so that the traces of trojans, etc., found by expert witnesses support their claims.

The prosecution’s response will generally be as follows:

First, if possible, establish the defendant’s technological expertise, to cast doubt on possibility of infection. The effectiveness of this approach varies. More sophistication (+ more evidence of a secure computer) along with less evidence of malware (“wiped all the logs”) makes the THD less reasonable.

Second, negate the factual basis of the defense. Thoroughly examine the drives, looking for malware. If found, determine if its capabilities permit the alleged crime. If not, look for evidence of wiping or wiping tools.

Finally, seek confessions in interrogation or before. As noted by Brenner et al., suspects often confess, and these confessions are binding (assuming the suspect has been Mirandized appropriately). Some questions can be asked that rule out (or make more difficult) the THD or SODDI: “Who else has access to this computer?” “Do you use antivirus programs?” Etc.

Forensic examinations also help in other ways. If the main activity (by log exam, etc.) the computer was used for was, say, CP collection, it becomes harder for the defendant to claim THD – why was the computer in your house and turned on if you never used it? Similarly the case for well-organized collections of CP.

Windows Forensics

So now we’ll turn our attention to Windows forensics. Like most modern OSes, Windows creates and modifies artifacts on the basis of user actions, ongoing processes, scheduled events, and so on. Today and Thursday, we’ll dig into some of these artifacts.

Like before, we’re concerned mainly with on-disk artifacts.

Unlike before, we’re going to take a (mostly) high-level view of these artifacts. Instead of writing the parsers for the binary objects we’ll examine, we’ll use pre-written tools – but now you have the knowledge to understand how they work under the hood, so it’s not just “magically run the tool to get the answer.” If you had the specification for, say, a Windows event log, you’d be able to write a parser for it (I hope!) at this point.

It’s usually a reasonable idea to start by flsing the entire drive image (and saving to a file), so that you can later grep for files of interest.

Thumbs.db / thumbcache

Most versions of Windows cache “thumbnails” of image files that are stored in users directories and opened by the user. Various tools can process these thumbnails, such as scalpel.

lnk files

LNK files are Windows shortcuts. Users might create them deliberately, but they are also created when files are opened by a user (to place in the “Recents” folder). Various tools exist to parse these files, for example, liblnk.

Browser information

Depending upon the version of Windows, the browser information (cache, users-typed URLs, etc.) lives in various places. Tools exist to parse and extract relevant information (libmsiecf for example).

Registry

The Windows Registry is a binary key-value store that also supports subkeys. In other words, it is a hierarchical database that maintains configuration settings for applications, hardware, and users. Typically there are five top-level entries, or “hives,” in the registry:

  • HKEY_USERS: all actively loaded user profiles for the system
  • HKEY_CURRENT_USER: actively loaded profile for logged-on user
  • HKEY_LOCAL_MACHINE: “vast array” of configuration information for the system (hardware and software)
  • HKEY_CURRENT_CONFIG: hardware profile used at startup
  • HKEY_CLASSES_ROOT: configuration information related to which applications open which files

You can directly access your local registry through regedit. You can use various forensic tools to directly parse the registry. Where do the backing files live?

HKEY_LOCAL_MACHINE\System: %WINDIR%\system32\config\System
HKEY_LOCAL_MACHINE\SAM: %WINDIR%\system32\config\Sam
HKEY_LOCAL_MACHINE\Security: %WINDIR%\system32\config\Security
HKEY_LOCAL_MACHINE\Software: %WINDIR%\system32\config\Software
HKEY_LOCAL_MACHINE\Hardware: volatile
HKEY_LOCAL_MACHINE\System\Clone: volatile
HKEY_USERS\User SID: NTUSER.DAT; Documents And Settings\User
HKEY_USERS\Default: %WINDIR%\system32\config\default

Along with various event logs, you can use the registry to find evidence that certain apps were opened, or settings modified, or hardware inserted/removed, etc.

Partial printer files

.SPL files are spoolfiles, that is, the file Windows creates when preparing to send a file to a printer. Find the EMF marker, then go back 41 bytes, carve from there.

Then you have an EMF file, which is an enhanced Windows Metafile. These are most easily viewed on Windows, since the are typically parsed with Windows API functions.