Other Applications

There are many other applications that we could cover. However, we have limited time and space, so we’ve chosen a few additional applications that have provided us with crucial evidence in more than one case. We hope these will illustrate how application data can be helpful, even if you can only obtain indirect information.

Truecrypt

Truecrypt is a popular, free, and open source disk encryption tool that supports Windows, OS X, and Linux. It can provide encryption of an entire physical disk, individual partitions, or virtual disks (files that are mounted as disks). Truecrypt uses modern encryption algorithms, along with a passphrase or a passphrase and a key file, to protect data.

www.truecrypt.org

In the few incidents we’ve seen Truecrypt used, the attacker created and used an encrypted virtual disk to store tools and stolen data. In this mode of operation, Truecrypt creates and encrypts a file that contains a full file system, such FAT32 or NTFS. As needed, the user can mount and unmount the file as a drive letter. Any data stored or accessed on that drive letter is encrypted and decrypted in real time, also known as on-the-fly encryption (OTFE). Using a Truecrypt volume in this manner greatly reduces the number of useful forensic artifacts present on the system.

In the context of incident response, it’s unlikely that we would have the time, resources, or justification to attempt to break the Truecrypt passphrase or encryption. In cases where you really do want the password, a good approach might be to install surveillance software, such as a keystroke monitor, on the system. So, why are we talking about Truecrypt? Because even though we may not be able to do anything with a Truecrypt volume if it is not mounted, there may still be useful artifacts on the system. Those artifacts may provide some clues about the data that is in the Truecrypt volume, and possibly even some plain text data.

Artifacts

Truecrypt can run in two modes—fully installed and portable. In a fully installed mode, the software is installed on the system like any other application. In portable mode, the Truecrypt application files are placed in a folder, which can be moved and executed anywhere on a system. In both cases, Truecrypt maintains a file named Configuration.xml, where a number of preferences are stored. Depending on the operating system version and Truecrypt mode, the file is stored in different locations. The following table lists where you can find the file:

Operating System	Truecrypt Mode	Configuration.xml Location
Windows Vista and newer	Fully Installed	C:\Users\{username}\AppData\Roaming\TrueCrypt
Windows XP and older	Fully Installed	C:\Documents and Settings\{username}\Application Data\TrueCrypt
OS X	Fully Installed	/Users/{username}/Library/Application Support/TrueCrypt
N/A	Portable	Same directory as Truecrypt application files

Even when “Never save history” is checked, Truecrypt still leaves behind at least one artifact in the Configuration.xml file—the drive letter of the last volume mounted is saved. If you inspect the file, you will see a configuration item, usually around line number 25, which looks similar to this:

<config key="LastSelectedDrive">T:</config>

This indicates the last drive letter that Truecrypt performed an operation on was “T:”—typically mounting or unmounting a Truecrypt volume. Although it doesn’t sound like much of a lead, if you suspect an attacker is using this letter consistently, it may allow you to search for valuable clues. In one case, we discovered hundreds of file names in the volume by searching the main hard drive and memory for the drive letter with a backslash (“T:\” for example). There are many locations on a Windows system, including the file system, registry, and memory, where file paths are saved… whether directly or indirectly. Therefore, even though we never discovered the password for the volume, we had a good idea what the attacker was doing based on the file names.

Also, keep in mind that the operating system or the application opening a file that resides in a Truecrypt volume may create a copy of the file. If that copy is placed on a unencrypted drive, you may be able to recover some plain text data without gaining access to the volume. Looking at a file system timeline around the time you suspect files in a Truecrypt volume were accessed may lead you straight to those copies.

Tools

We found two tools that you may find useful when dealing with Truecrypt volumes. The first is a free tool named TCHunt, which can help you identify possible Truecrypt virtual disk files. The second is a commercial tool named Elcomsoft Forensic Disk Decryptor, which can extract the Truecrypt encryption keys using several methods against the target system. The use cases for these tools are somewhat limited in an incident response context, so we will only cover them briefly. Let’s take a look at TCHunt first.

Finding Truecrypt (TC) containers can be tricky. There are indirect methods, such as examining command or application history, or sorting by file size and examining large files. There are also more direct methods, such as looking for files with the “.tc” extension or using a tool that is able to scan a system for TC containers. We have used a tool named TCHunt that examines files on a system for characteristics consistent with TC containers.

16s.us/TCHunt/index.php

TCHunt only looks for suspect files (TC containers)—it does not search for TC hidden volumes. In our experience, TCHunt has a low false positive (FP) rate, well within reasonable limits. In our tests, TCHunt generally produced fewer than 10 false positives per system. However, there were some false negatives. When a TC container is actively mounted, TCHunt cannot examine the associated file. So in our test case, one real TC container was not reported because it was mounted. Once we dismounted the container, TCHunt reported the file as suspicious. If the container is mounted, Elcomsoft Forensic Disk Decryptor can help you maintain access if the volume is dismounted and you do not know the passphrase. Let’s look at how Disk Decryptor can help.

Elcomsoft Forensic Disk Decryptor can examine a memory dump or hibernation file to try to extract the encryption keys—not the passphrase—for a Truecrypt volume. The volume should be mounted at the time the memory dump or hibernation file is created, or the chances the tool will find the keys are significantly reduced. The Elcomsoft web page has additional details about the capabilities of Forensic Disk Decryptor:

www.elcomsoft.com/efdd.html

The primary use case for an investigator is when you do not have the passphrase for the Truecrypt volume, but you do have access to memory or a hibernation file from the system at the time the volume was mounted. Using Disk Decryptor, you may be able to obtain the encryption keys so that you can access the Truecrypt volume after it is dismounted.

Compression Tools with Encryption

As part of an intrusion investigation, it is common for us to encounter archives that are encrypted with a compression tool, such as ZIP, RAR, or 7-Zip. Attackers choose these formats because they make it difficult for us to determine what data is in the archive and because compression reduces the size of the data. Some archive formats only encrypt the file data—leaving the file names in plain text. In those cases, you may be able to infer what data is in the encrypted archive based on the file names. In terms of compression, it’s not uncommon for good compression algorithms to reduce text-based data to 10 percent of its original size. So a set of text files that add up to 1GB could be reduced to 100MB—making it a lot easier for an attacker to manage.

Normally when we find a password-protected archive that an attacker created, we are interested in finding out what is in it. There are two common ways we use to determine the password: using a password cracking tool and analyzing the system for command-line artifacts associated with creating the archive. When attackers use a strong method to create the archive—full encryption with a long and complex password—the password-cracking method will probably take a long time. For most common archive formats, such as RAR, ZIP, and 7-Zip, there are both free and commercial cracking tools available. We frequently use AccessData’s Password Recovery Toolkit (PRTK) Distributed Network Attack (DNA), which we’ve found to be one of the more effective tools at cracking archive files. It uses a number of optimization routines, supports customization, and takes a divide-and-conquer approach of splitting work up between many computers. A cheaper commercial option is Elcomsoft’s product called Advanced Archive Password Recovery. Cheaper yet are free or open source solutions such as Zipcrack and Rarcrack. There are many password-cracking solutions on the market, and any major search engine will help you to locate more options.

www.elcomsoft.com/archpr.html
www.accessdata.com/products/digital-forensics/decryption
sourceforge.net/projects/zipcrack
rarcrack.sourceforge.net

In many cases involving Windows-based systems, we analyze the system itself to find the password. The success of this method depends on many variables, including what tool was used, how long ago the event occurred, and how heavily the system is used. Two artifacts have a fair chance at containing the password: main memory and the page file. We search these two artifacts for common command-line switches of compression tools. For example, if an attacker uses RAR, the command-line switch to both encrypt and password protect is -hp. A string search for “ -hp” (note the space in front of the dash) will find this switch. The password should appear immediately following the switch on a command line. In some cases, we’ve used this method to find complex passwords within just a few hours—much to the surprise of organizations using far superior computing power and a cracking approach.

Microsoft Terminal Services Client

The Microsoft Terminal Services Client (mstsc) allows a user to connect to other Windows systems on the network that are running the Remote Desktop Protocol (RDP) service. Mstsc is a built-in application in all recent versions of Windows. The mstsc software provides a graphical desktop, similar to when you log in normally at a physical computer. This tool is commonly used by system administrators to perform administrative tasks on remote systems. Attackers also use the tool, because it is already on most Windows systems and its use tends to blend in with normal network traffic—especially when using valid administrator credentials.

Use of mstsc on Windows systems creates several useful artifacts. There are two registry keys, each in the user’s Software hive, and one file:

• HKEY_USERS\Software\Microsoft\Terminal Server Client\Default\
• HKEY_USERS\Software\Microsoft\Terminal Server Client\Servers\
• Default.rdp
• {systemdrive}\Users\{profile}\Documents\ (Vista and newer)
• {systemdrive}\Documents and Settings\{profile}\My Documents\ (XP and older)

Default.rdp is created in the user’s profile directory, as indicated, the first time the mstsc executable is run. Default mstsc settings are stored in that file in plain text—you can open the file with any text editor. The setting named “full address” contains the hostname or IP address of the last system that mstsc successfully connected to. There are also redirection settings, such as the clipboard and drive letters, that can be useful in an investigation. Although the default.rdp file usually doesn’t contain much in the way of relevant information, the registry keys are often very useful.

The key ending with “Default” listed previously contains values for the most recently used (MRU) entries of computers that mstsc has successfully connected to. The values go from MRU0 to MRU9, with MRU0 being the most recent. This list can be useful in determining what systems an attacker has connected to. However, if you recall from the Investigating Windows chapter, Windows registry values do not have individual timestamps—so there is no way to know for sure when any of these systems were connected to. The “Servers” registry key, on the other hand, can be of more help.

The key ending with “Servers” contains a subkey for every system mstsc has connected to. That’s right—a key. The modified dates on those keys are much more useful to help determine a time line of activity. The key is named whatever string the user entered in the Computer field of mstsc to connect to. Also, this key contains a value named UsernameHint. This value will have the domain and user name last used to connect to the remote system—sometimes a critical piece of information during an investigation.

There is an RDP client for OS X; however, it does not keep such a large amount of artifacts. Only the most recent settings and host information are stored. You will find the data stored as XML in the file /Users/{profile}/Documents/RDC Connections/Default.rdp.

Secure Shell “known_hosts”

Secure shell (SSH) is an encryption protocol that is most commonly used for remote command-line access to Unix-based systems. Similar to mstsc, administrators commonly use SSH to perform administrative tasks on remote Unix-based systems. Because SSH is also widely used, it is typically a part of the default installation of most Unix-based operating systems. In most environments, use of the SSH client creates an artifact—a file named known_hosts. This file can help an investigator determine what hosts an attacker may have connected to.

The first time an SSH client connects to a host, it adds the public key of that host into the known_hosts file, along with the host name or IP address associated with it. This is used as a security measure—the SSH client will warn you if the key changes for a given host, which may indicate malicious activity. The file is in plain text—you can open it with any text editor. There is one entry per line, each for a single host. The default location for the file is a directory named “.ssh” under the user’s home directory. The following is an example of what the known_hosts file looks like:

10.18.0.30 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzZ/l...
www.example.com,10.18.0.21 ssh-rsa AAAAB3NzaC1yc2EA...
10.18.0.42 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCy...
10.18.0.80 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCy...
www ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCyHieczX4...

In this example, the last field is truncated with “…” because it’s normally around 300 bytes long. The first field can contain the IP address, host name, or both, depending on what was specified on the SSH command line. There are no timestamps associated with these entries, so there is no definitive way to know when, or how often, each host was connected to.

If the system has a more recent version of the SSH client installed, you may notice that there are no IP addresses or host names in the known_hosts file. Newer versions of the SSH client contain a setting to hash the host name or IP address, and store the hash in the known_hosts file instead. You can check the HashKnownHosts setting in the SSH client config file, normally /etc/ssh/ssh_config. If HashKnownHosts is set to “yes,” the entries in the known_hosts file will contain hashed versions of the host name or IP address—they will not be in plain text. The following entry is an example of what the newer format looks like:

|1|DhuFlmyKF5WZeqM8cfttdhsWROE=|0zhVAfoZiVWDWrQRqc3ZGgNUrV0= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTTtbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCuQkd7AdShFT7VpQLjTOQ1OVYtHik91LGbG28DvMdUWLeaIkDgaHSFXZ1Wwd77LxSGuGnema4KMrUE0e8wAfek=

This new format is a security measure, created to help prevent someone (or something) from easily obtaining a list of systems that you connect to. There is a nice article about why this was done and includes a tool that can attempt to brute force the host name or IP address out of the hash:

blog.rootshell.be/2010/11/03/bruteforcing-ssh-known_hosts-files

Adobe Flash Player

The Adobe Flash Player is an application that views multimedia and other Adobe Flash run-time content. The player is most commonly implemented as a web browser plugin, delivering streaming content, interactive applications, and other multimedia rich experiences. Over the years, Adobe’s Flash Player has been the target of many exploits. During those exploits, web browsers may crash and not save browsing history or other browser artifacts that can help the investigation. However, there may be some artifacts created directly from the player.

By default, the player saves what are called Local Shared Objects (LSOs). They are similar to web browser cookies—small files used to save preferences. In Windows, the LSOs are saved in a directory under each user’s profile:

OS	Path
Windows Vista and newer	C:\Users\{profile}\AppData\Roaming\Macromedia\Flash Player\#SharedObjects
Windows XP and older	C:\Documents and Settings\{profile}\Application Data\Macromedia\Flash Player\#SharedObjects

In the #SharedObjects directory, the Flash player creates a folder that contains a subdirectory for each website that stores an LSO. The subdirectories are named the site that was accessed, such as www.example.com. Although the contents of the LSO files are unlikely to be very useful, the timestamps and names of the directories may provide some good leads. We know of at least one tool that parses and displays these files:

www.nirsoft.net/utils/flash_cookies_view.html