Network Forensics

Understanding Network Forensics Analysis in an Operational Environment

Memory Forensics

Detecting Malware With Memory Forensics

Android Forensics

Andriller - Android Forensic Tools

Sunday, August 16, 2015

Windows 10 Doesn't Stop Spying You, Even After Disabling It's Creepy Features




In our previous articles, we raised concern about Windows 10 privacy issues,
unfortunately, all those efforts got wasted because Microsoft still tracks you, even after you harden your Windows 10 privacy to an extreme level by disabling all privacy-infringing settings.


This time the culprits are – Cortana and Bing search.


Windows 10 features, including Cortana and Bing search, continue communicating with Microsoft's servers and sending it data, even after you turned the features off.

A Technical Analysis done by Ars showed that even when you tell Microsoft to not to make any Internet-related inquiries by changing various privacy settings, it appears that Windows 10 still communicate with the software giant's servers for different information.


Cortana is Cheating on You

With Cortana and searching the Web from the Start menu turned off, a request to www.bing.com is still made for a file called threshold.appcache that contains some Cortana information, whenever a user opens Start and start typing.
The operating system's voice assistant Cortana sends information containing user's identifying computer ID that persists across reboots. This allows Microsoft to distinguish between the Cortana requests from different computers.
The worrisome part is that Cortana sends this data even though she is disabled.


Windows 10 Sends your Data via Unencrypted Channel

Moreover, it also appears that Microsoft keeps on sending data to its servers via its Live Tiles in the Start menu. Even if users clear all the Tiles, Windows 10 re-install new tile info from Microsoft.

However, Windows 10 do so using unencrypted HTTP connections, potentially leaving users open to malicious actors who could intercept the traffic between users and the company, which is more troublesome.

In response to the latest report, Microsoft said that all communications between a Windows 10 machine and Microsoft are only to make the retrieval of updates easier.
"As part of delivering Windows 10 as a service, updates may be offered to provide ongoing new features to Bing searches, such as new visual layouts, styles and search code," Microsoft said.
Microsoft further added that "no query or search usage data" is sent to the company, in accordance with the user’s selected privacy settings, and the same applied to searching offline for apps, files and settings on the device.

How to forensically examine an Android device with AFLogical OSE on Santoku Linux

What you will need:

  • Santoku – Alpha 0.1 (or later)
  • AFLogical OSE (already installed in Santoku)
  • An Android device (with adb enabled)

AFLogical OSE Background

AFLogical OSE was released in December 2011 and is now hosted on GitHub. The app provides a basic framework for extracting data from Android devices using Content Providers and then saves the data to the SD Card of the device including:
  • Contacts
  • Call Logs
  • SMS
  • MMS
  • MMS Parts
  • Device info
AFLogical OSE has been successfully tested on Android 1.5 through 4.1 (Jelly Bean) and across many non-standard Android devices.

Installing and running AFLogical OSE

First, let’s get a terminal prompt in the correct directory by navigating to Santoku –> Device Forensics –> AFLogical OSE.
To install AFLogical OSE, connect your Android device over USB and if you are running Santoku CE in a VM, make sure you pass the USB connection through. You can run the following command to verify Santoku can communicate with your Android device:
adb devices

which should return your device serial number.
santoku@santoku-vm:/opt/santoku/af-logical$ adb devices
        * daemon not running. starting it now on port 5037 *
        * daemon started successfully *
        List of devices attached 
        01653EF81C00510F device

If you do not see something similar to this, you need to resolve this issue first.
Next, you need to push AFLogical OSE to your Android device:

For Santoku 0.4 and later

Install the application to your device:
aflogical-ose
You should receive a success message as follows:
634 KB/s (28794 bytes in 0.044s)
         pkg: /data/local/tmp/AFLogical-OSE_1.5.2.apk
        Success
        
        Starting: Intent { cmp=com.viaforensics.android.aflogical_ose/com.viaforensics.android.ForensicsActivity }
        
        Press enter to pull /sdcard/forensics into ~/aflogical-data/
Again, if you receive an error, you need to resolve the issue.
Next, on your target device, select the data you want to extract and click “Capture”:
AFLogical at work extracting physical data
In your AFLogical-ose terminal window in Santoku, press enter to pull the data from your SDCard to the location “~/aflogical-data”. Santoku will automatically pull all the data recovered from your device to that location.
To view the data, open a terminal window and type:
$ cd ~/aflogical-data/
        $ ls
        20131028.1039
The data is stored under a folder labeled with the date and time of the acquisition. In this example, it was 2013-10-28 at 10:39 local time.
You can then open the “~/aflogical-data” directory in Nautilus and browse any images as well as the extracted data (such as contacts, call logs, mms/sms, and device info) in CSV format:
aflogical-data

For Santoku 0.1 to 0.3:

First, install the application to the device:
adb install AFLogical-OSE_1.5.2.apk
You should receive a success message as follows:
santoku@santoku-vm:/opt/santoku/af-logical$ adb install AFLogical-OSE_1.5.2.apk
        574 KB/s (28794 bytes in 0.048s)
         pkg: /data/local/tmp/AFLogical-OSE_1.5.2.apk
        Success
Again, if you receive an error, you need to resolve the issue.

Run AFLogical on your Android device:

To run AFLogical OSE, , navigate to it through Applications –> AFLogical OSE:
AFLogical in an Android's app menu
Then select the data you want to extract and click “Capture”:
AFLogical at work extracting physical data
AFLogical OSE will then save the extracted data on the SD Card of the device. You can now uninstall AFLogical OSE with the following command:
adb uninstall com.viaforensics.android.aflogical_ose

which will close the app (if still running) and remove from the device:
santoku@santoku-vm:/opt/santoku/af-logical$ adb uninstall com.viaforensics.android.aflogical_ose
        Success

Pull and examine the extracted data:

AFLogical OSE creates a folder on the SD Card called forensics and then a subfolder with the date and time of the extraction. The easiest way to copy the data to Santoku is with the recursive “adb pull” command:
adb pull /mnt/sdcard/forensics

which will extract all data under that directory (so, if you reuse a removable SD Card, you might have multiple subfolders with data). Here’s some example output (truncated for space):
santoku@santoku-vm:/tmp$ adb pull /mnt/sdcard/forensics
        pull: building file list...
        pull: /mnt/sdcard/forensics/20120912.0741/Contacts Phones.csv -> ./20120912.0741/Contacts Phones.csv
        pull: /mnt/sdcard/forensics/20120912.0741/SMS.csv -> ./20120912.0741/SMS.csv
        pull: /mnt/sdcard/forensics/20120912.0741/MMSParts.csv -> ./20120912.0741/MMSParts.csv
        pull: /mnt/sdcard/forensics/20120912.0741/MMS.csv -> ./20120912.0741/MMS.csv
        pull: /mnt/sdcard/forensics/20120912.0741/CallLog Calls.csv -> ./20120912.0741/CallLog Calls.csv
        pull: /mnt/sdcard/forensics/20120912.0741/info.xml -> ./20120912.0741/info.xml
        pull: /mnt/sdcard/forensics/20120912.0741/Photo0284.jpg -> ./20120912.0741/Photo0284.jpg
        
        11 files pulled. 0 files skipped.
        499 KB/s (893180 bytes in 1.746s)

You can then open the directory in Nautilus and browse any images as well as the extracted data (such as contacts, call logs, mms/sms, and device info) in CSV format:
AFLogical results

Digital Intelligence and Investigation Tools

By providing operational support to high-profile intrusion, identity theft, and general computer crime investigations, DIID is able to see the current limitations of computer forensics and incident response in the field first hand. Combining applied research with the unique talents, operational experience, research capabilities, and the vast knowledge base of Carnegie Mellon University, we have developed resources, training, and tools to facilitate forensic examinations and assist authorized members of the law enforcement community.

Restricted Access Tools

Users can access the following tools after they register and are vetted.
Live View LE allows forensic investigators to take a physical device or an image file of a disk or partition and automatically transform it into a virtual machine.
CCFinder is a suite of utilities designed to facilitate the discovery, organization, and query of financial data and related personally identifiable information in large-scale investigations.
CryptHunter alerts law enforcement if active encryption is running on a system so that investigators can act to preserve evidence that would be lost if the system were shut down.
ADIA is a VMware-based appliance used for digital investigation and acquisition.

Unrestricted Access Tools

Users can access the following tools for free; no secondary access is required.
AfterLife permits the collection of physical memory contents from a system after a warm or cold reboot.
Live View (public version) is a Java-based graphical forensics tool that creates a VMware virtual machine out of a raw (dd-style) disk image or physical disk.
DINO is a lightweight front end for network visualization and utilizes the open source network monitoring tools SiLK and SNORT to create an easy-to-use dashboard for situational awareness.
LATK is a collection of command line and web-based tools for use in incident response and long-term analysis of web server and proxy server log data.
CERT Linux Forensics Tools Repository houses packages for Linux distributions. The repository provides useful tools for cyber forensics acquisition and analysis practitioners and is currently offering Fedora and Centos/RHEL.

Information Only

Users can access information and perhaps more about the following tools; requests are handled on a case-by-case basis.
C-CAP is a state-of-the-art forensics analysis environment that provides a broad set of tools for host-based and network investigations.
MCARTA is a completed incident analysis framework in respect to run-time analysis with automated log and pocket data correlation.

Friday, August 14, 2015

Windows 10 Full Artifacts as Promised




Download the Full Windows 10 Artifacts PDF

Windows 10 Artifacts

Sunday, August 9, 2015

Recovering a FAT filesystem directory entry in five phases

The directory entry we’ll be recovering is from the Honeynet Scan of the Month #24. You can download the file by visiting the SOTM24 page. The entry we’ll recover is the 3rd directory entry in the root directory (the short name entry for _IMMYJ~1.DOC, istat number 5.)
Location
The first step is to locate the entry. It’s at byte offset 0x2640 (9792 decimal). How do we know this? Well assuming we know we want the third entry in the root directory, we can calculate the offset using values from the boot sector, as well as the fact that each directory entry is 0x20 (32 decimal) bytes long (this piece of information came from the FAT file system specification.) There is an implicit step that we skipped, recovering the boot sector (so we could use the values). To keep this post to a (semi) reasonable length, we’ll skip this step. It is fairly straightforward though. The calculation to locate the third entry in the root directory of the image file is:
3rd entry in root directory = (bytes per sector) * [(length of reserved area) + [(number of FATs) * (size of one FAT)]] + (offset of 3rd directory entry)
bytes per sector = 0x200 (512 decimal)
length of reserved area = 1 sector
number of FATs = 2
size of one FAT = 9 sectors
size of one directory entry = 0x20 (32 decimal) bytes
offset of 3rd directory entry = size of one directory entry *2 (start at 0 since it’s an offset)
3rd entry in root directory = 0x200 * (1 + (2 * 9))+ (0x20 * 2) = 0x2640 (9792 decimal)
Using xxd, we can see the hex dump for the 3rd directory entry:
$ xxd -g 1 -u -l 0x20 -s 0x2640 image
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Extraction
Continuing to the extraction phase, we need to extract each field. For a short name directory entry, there are roughly 12 fields (depending on whether you consider the first character of the file name as it’s own field.) The multibyte fields are stored in little endian, so we’ll need to reverse the bytes that we see in the output from xxd.
To start, the first field we’ll consider is the name of the file. This starts at offset 0 (relative to the start of the data structure) and is 11 bytes long. It’s the ASCII representation of the name. 
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
File name = _IMMYJ~1.DOC (_ represents the byte 0xE5)
The next field is the attributes field, which is at offset 12 and 1 byte long. It’s an integer and a bit field, so we’ll examine it further in the decoding phase.
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Attributes = 0x20
Continuing in this manner, we can extract the rest of the fields:
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Reserved = 0x00
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Creation time (hundredths of a second) = 0x68
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Creation time = 0x4638
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Creation date = 0x2D2B
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Access date = 0x2D2B
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
High word of first cluster = 0x0000
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Modification time = 0x754F
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Modification date = 0x2C8F
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Low word of first cluster = 0x0002
0002640: E5 49 4D 4D 59 4A 7E 31 44 4F 43 20 00 68 38 46 .IMMYJ~1DOC .h8F
0002650: 2B 2D 2B 2D 00 00 4F 75 8F 2C 02 00 00 50 00 00 +-+-..Ou.,...P..
Size of file = 0x00005000 (bytes)
Decoding
With the various fields extracted, we can decode the various bit-fields. Specifically the attributes, dates, and times fields. The attributes field is a single byte, with the following bits used to represent the various attributes:
  • Bit 0: Read only
  • Bit 1: Hidden
  • Bit 2: System
  • Bit 3: Volume label
  • Bit 4: Directory
  • Bit 5: Archive
  • Bits 6 and 7: Unused
  • Bits 0, 1, 2, 3: Long name
When decoding the fields in a FAT file system, the right most bit is considered bit 0. To specify a long name entry, bits 0, 1, 2, and 3 would be set. The value we extracted from the example was 0x20 or 0010 0000 in binary. The bit at offset 5 (starting from the right) is set, and represents the “Archive” attribute.
Date fields for a FAT directory entry are encoded in two byte values, and groups of bits are used to represent the various sub-fields. The layout for all date fields (modification, access, and creation) is:
  • Bits 0-4: Day
  • Bits 5-8: Month
  • Bits 9-15: Year
Using this knowledge, we can decode the creation date. The value we extracted was 0x2D2B which is 0010 1101 0010 1011 in binary. The day, month, and year fields are thus decoded as:
0010 1101 0010 1011
Creation day: 01011 binary = 0xB = 11 decimal
0010 1101 0010 1011
Creation month: 1001 binary = 0x9 = 9 decimal
0010 1101 0010 1011
Creation year: 0010110 binary = 0x16 = 22 decimal
A similar process can be applied to the access and modification dates. The value we extracted for the access date was also 0x2D2B, and consequently the access day, month, and year values are identical to the respective fields for the creation date. The value we extracted for the modification date was 0x2C8F (0010 1100 1000 1111 in binary). The decoded day, month, and year fields are:
0010 1100 1000 1111
Modification day: 01111 binary = 0xF = 15 decimal
0010 1100 1000 1111
Modification month: 0100 binary = 0x4 = 4 decimal
0010 1100 1000 1111
Modification year: 0010110 binary = 0x16 = 22 decimal
You might have noticed the year values seem somewhat small (i.e. 22). This is because the value for the year field is an offset starting from the year 1980. This means that in order to properly interpret the year field, the value 1980 (0x7BC) needs to be added to the value of the year field. This is done during the next phase (interpretation).
The time fields in a directory entry, similar to the date fields, are encoded in two byte values, with groups of bits used to represent the various sub-fields. The layout to decode a time field is:
  • Bits 0-4: Seconds
  • Bits 5-10: Minutes
  • Bits 11-15: Hours
Recall that we extracted the value 0x4638 (0100 0110 0011 1000 in binary) for the creation time. Thus the decoded seconds, minutes, and hours fields are:
0100 0110 0011 1000
Creation seconds = 11000 binary = 0x18 = 24 decimal
0100 0110 0011 1000
Creation minutes = 110001 binary = 0x31 = 49 decimal
0100 0110 0011 1000
Creation hours = 01000 binary = 0x8 = 8 decimal
The last value we need to decode is the modification time. The bit-field layout is the same for the creation time. The value we extracted for the modification time was 0x754F (0111 0101 0100 1111 in binary). The decoded seconds, minutes, and hours fields for the modification time are:
0111 0101 0100 1111
Modification seconds = 01111 binary = 0xF = 15 decimal
0111 0101 0100 1111
Modification minutes = 101010 binary = 0x2A = 42 decimal
0111 0101 0100 1111
Modification hours = 01110 binary = 0xE = 14 decimal
Interpretation
Now that we’ve finished extracting and decoding the various fields, we can move into the interpretation phase. The values for the years and seconds fields need to be interpreted. The value of the years field is the offset from 1980 (0x7BC) and the seconds field is the number of seconds divided by two. Consequently, we’ll need to add 0x7BC to each year field and multiply each second field by two. The newly calculated years and seconds fields are:
  • Creation year = 22 + 1980 = 2002
  • Access year = 22 + 1980 = 2002
  • Modification year = 22 + 1980 = 2002
  • Creation seconds = 24 * 2 = 48
  • Modification seconds = 15 * 2 = 30
We also need to calculate the first cluster of the file, which simply requires concatenating the high and the low words. Since the high word is 0x0000, the value for the first cluster of the file is the value of the low word (0x0002).
In the next phase (reconstruction) we’ll use Python, so there are a few additional values that are useful to calculate. The first order of business is to account for the hundredths of a second associated with the seconds field for creation time. The value we extracted for the hundredths of a second for creation time was 0x68 (104 decimal). Since this value is greater than 100 we can add 1 to the seconds field of creation time. Our new creation seconds field is:
  • Creation seconds = 48 + 1 = 49
This still leaves four hundredths of a second left over. Since we’ll be reconstructing this in Python, we’ll use the Python time class which accepts values for hours, minutes, seconds, and microseconds. To convert the remaining four hundredths of a second to microseconds multiply by 10000. The value for creation microseconds is:
  • Creation microseconds = 4 * 10000 = 40000
The other calculation is to convert the attributes field into a string. This is purely arbitrary, and is being done for display purposes. So our new attributes value is:
  • Attributes = “Archive”
Reconstruction
This is the final phase of recovering our directory entry. To keep things simple, we’ll reconstruct the data structure as a Python dictionary. Most applications would likely use a Python object, and doing so is a fairly straight forward translation. Here is a snippet of Python code to create a dictionary with the extracted, decoded, and interpreted values (don’t type the >>> or …):

$ python
>>> from datetime import date, time
>>> dirEntry = dict()
>>> dirEntry["File Name"] = "xE5IMMYJ~1DOC"
>>> dirEntry["Attributes"] = "Archive"
>>> dirEntry["Reserved Byte"] = 0x00
>>> dirEntry["Creation Time"] = time(8, 49, 49, 40000)
>>> dirEntry["Creation Date"] = date(2002, 9, 11)
>>> dirEntry["Access Date"] = date(2002, 9, 11)
>>> dirEntry["First Cluster"] = 2
>>> dirEntry["Modification Time"] = time(14, 42, 30)
>>> dirEntry["Modification Date"] = date(2002, 4, 15)
>>> dirEntry["size"] = 0x5000
>>>
If you wanted to print out the values in a (semi) formatted fashion you could use the following Python code:

>>> for key in dirEntry.keys():
... print "%s == %s" % (key, str(dirEntry[key]))
...

And you would get the following output

Modification Date == 2002-04-15
Creation Date == 2002-09-11
First Cluster == 2
File Name == ?IMMYJ~1DOC
Creation Time == 08:49:49.040000
Access Date == 2002-09-11
Reserved Byte == 0
Modification Time == 14:42:30
Attributes == Archive
size == 20480
>>>
At this point, there are a few additional fields that could have been calculated. For instance, the file name could have been broken into the respective 8.3 (base and extension) components. It might also be useful to calculate the allocation status of the associated file (in this case it would be unallocated). These are left as exercises for the reader ;).
This concludes the 3-post series on recovering data structures from a stream of bytes. Hopefully the example helped clarify the roles and activities of each of the five phases. Realize that the five phases aren’t specific to recovering file system data structures, they apply to network traffic, code, file formats, etc.

Saturday, August 8, 2015

A Forensic Analysis Of The Windows Registry

Abstract
This paper will introduce the Microsoft Windows Registry database and explain how critically important a registry examination is to computer forensics experts. In essence, the paper will discuss various types of Registry 'footprints' and delve into examples of what crucial information can be obtained by performing an efficient and effective forensic examination. Many of the Registry keys that are imperative and relevant to an examination will also be discussed.

Acknowledgments
This paper is primarily a product of research, but may also serve as a reference to a Windows registry examination. For the sake of simplicity, there will only be reference to the Windows XP operating system - Even though earlier versions of Windows utilize the Registry, contain similar characteristics, and even apply many of the same concepts. The reasons XP was chosen to be discussed over other versions of Windows is because it remains popular and very widely used among average computer users, thus the chance of encountering it in a forensic examination is higher. Windows XP is still very current and much of the same information can still be applied to previous versions of Windows. The illustrations throughout this paper are intended to provide a better understanding of the subject being discussed. All of the screenshot images contained in this paper were captured from the Windows XP system in which the research was conducted on. The P2P client programs that were downloaded, installed, used, and examined were for the purpose of research use only. Searches were conducted and files were downloaded from these networks, not to engage in illegal or malicious activity, but to help provide a better understanding of the software's architecture and how it utilizes the Windows Registry from a forensics standpoint.


Introduction
The Importance of a Registry Examination
Today's society relies heavily on computers and the internet to accomplish everyday tasks, which includes practically everything from communicating and shopping online to banking and investing. It is much more common to send or receive an email than a physical letter. Along with the increasing use of computers and the internet, comes a little problem called computer crime-- facetiously speaking. Computer crimes present exorbitant issues in today's society. Including, but certainly not limited to - fraud, identity theft, phishing, network infiltration, DoS attacks, piracy of copyrighted material, and CP. With computer crimes on the rise, it is becoming extremely crucial for law enforcement officers and digital forensic examiners to understand computer systems and be able to examine them efficiently and effectively. In order to do this a study of how operating systems work must be explored from the inside out. The Registry is the heart and soul of the Microsoft Windows XP operating system and an exponential amount of information can be derived from it.


History

First, it is important to understand what the Registry is, why it exists, and the types of information it contains. Virtually everything done in Windows refers to or is recorded into the Registry. A program called RegMon by Sysinternals can be used to display registry activity in real time. After running this program it is apparent that registry access barely remains idle. The Registry is referenced in one way or another with every action taken by the user.
The Microsoft knowledge database and also the Microsoft Computer Dictionary, Fifth Edition, define the registry as:
A central hierarchical database used in Microsoft Windows 9x, Windows CE, Windows NT, and Windows 2000 used to store information necessary to configure the system for one or more users, applications and hardware devices.
The Registry was first introduced with Windows 95 and has been incorporated into many Microsoft operating systems since. Although some versions slightly differ, they all are essentially composed of the same structure and serve the main purpose as a configuration database. The Registry replaces configuration files that were used in MSDOS, such as config.sys and autoexec.bat. The primary purpose of config.sys was to load device drivers and the primary purposes of autoexec.bat was to run startup programs and set environment variables - the Registry now handles these functions. In addition to replacing DOS configuration files, the Registry also replaces text-based initialization (.ini) files that were introduced in Windows 3.0. The .ini files - specifically win.ini and system.ini - store user settings and operating system parameters.
This very basic history of the Windows Registry, why it was implemented, and some of its functions are the core fundamentals of understanding the structure and what each part of the Registry pertains to.

Structure of the Windows Registry

By opening the Registry Editor (by typing 'regedit' in the run window), the Registry can be seen as one unified 'file system'. The left-hand pane, also known as the key pane contains an organized listing of what appear to be folders. The five most hierarchal folders are called 'hives' and begin with 'HKEY' (an abbreviation for Handle to a Key). Although five hives can be seen, only two of these are actually 'real', HKEY_USERS (HKU) and HKEY_LOCAL_MACHINE (HKLM). The other three are shortcuts or aliases to branches within one of the two hives. Each of these five hives is composed of keys, which contain values and subkeys. Values are the names of certain items within a key, which uniquely identify specific values pertaining to the operating system, or to applications that depend upon that value.
A common analogy that is often used to help understand the structure of the Windows Registry is a comparison between it and the Windows Explorer file system, both are very similar in their structures. The key pane of the Registry is much like the hierarchical structure of the left-hand pane in the Windows Explorer file system. The keys and subkeys located within the five main hives are similar to folders and subfolders of Windows Explorer, and a key's value is similar to a file within a folder. In the right-hand pane of the Windows Registry - a value's name is similar to a file's name, its type is similar to a file's extension, and its data is similar to the actual contents of a file.
Figure 1 - Structure of the Windows Registry (CLICK TO ENLARGE)

Root Key Functions:

Below are listed the five hierarchical hives seen in Figure 1, with a very basic description of each. Beside the root key is their commonly referred to abbreviation in parenthesis, which will frequently be referred to as throughout the paper.
1.HKEY_CLASSES_ROOT (HKCR)
Information stored here ensures that the correct program opens when it is executed in Windows Explorer. It also contains further details on drag-and-drop rules, shortcuts, and information on the user interface. Alias for: HKLM\Software\Classes
2.HKEY_CURRENT_USER (HKCU)
Contains configuration information for the user who is currently logged into the system, including user's folders, screen colors, and Control Panel settings. Alias for a user specific branch in HKEY_USERS. The generic information usually applies to all users and is HKU\.DEFAULT.
3.HKEY_LOCAL_MACHINE (HKLM)
Contains machine hardware-specific information that the operating system runs on. It includes a list of drives mounted on the system and generic configurations of installed hardware and applications.
4.HKEY_USERS (HKU)
Contains configuration information of all user profiles on the system, which concerns application configurations, and visual settings.
5.HKEY_CURRENT_CONFIG (HCU)
Stores information about the systems current configuration. Alias for: HKLM\Config\profile

Examination Tools

Currently, there are many tools available to forensic examiners for extracting evidentiary information from the Registry. The tool used in this paper to analyze and navigate the registry is Registry Editor (regedit.exe). Registry Editor is free and available on any installation of Microsoft Windows XP with administrator privileges.

Registry Examination

The Registry as a Log
All Registry keys contain a value associated with them called the 'LastWrite' time, which is very similar to the last modification time of a file. This value is stored as a FILETIME structure and indicates when the Registry Key was last modified. In reference to the Microsoft Knowledge Base, A FILETIME structure represents the number of 100 nanosecond intervals since January 1, 1601. The LastWrite time is updated when a registry key has been created, modified, accessed, or deleted. Unfortunately, only the LastWrite time of a registry key can be obtained, where as a LastWrite time for the registry value cannot.
Harlan Carvey, author of Windows Forensics and Incident Recovery, refers to a tool called Keytime.exe, which allows an examiner to retrieve the LastWrite time of any specific key. Keytime.exe can be downloaded from http://www.windowsir. com/tools.html.
Knowing the LastWrite time of a key can allow a forensic analyst to infer the approximate date or time an event occurred. And although one may know the last time a Registry key was modified, it still remains difficult to determine what value was actually changed. Using the Registry as a log is most helpful in the correlation between the LastWrite time of a Registry key and other sources of information, such as MAC (modified, accessed, or created) times found within the file system. However, a comprehensive discussion of that process is outside the scope of this paper.

Autorun Locations

Autorun locations are Registry keys that launch programs or applications during the boot process. It is generally a good practice to look here depending on the case of examination. For instance, if a computer is suspected to have been involved in a system intrusion case, autorun locations should be looked at. If the user denies their involvement then it's possible their own system was compromised and used to initiate the attack. In a case such as this, the autorun locations could prove that the system had a trojan backdoor installed leaving it vulnerable for an attacker to use at their discretion.

List of common autorun locations:

HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\Software\Microsoft\Windows\CurrentVersion\policies\Explorer\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run 
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
(ProfilePath)\Start Menu\Programs\Startup

MRU lists

MRU, or 'most recently used' lists contain entries made due to specific actions performed by the user. There are numerous MRU lists located throughout various Registry keys. The Registry maintains these lists of items incase the user returns to them in the future. It is basically similar to how the history and cookies act to a web browser. One example of an MRU list located in the Windows Registry is the RunMRU key. When a user types a command into the 'Run' box via the Start menu, the entry is added to this Registry key. The location of this key is HKCU\Software\Microsoft\Windows\ CurrentVersion\Explorer\RunMRU and its contents can be seen in Figure 2. The chronological order of applications executed via 'Run' can be determined by looking at the Data column of the 'MRUList' value. The first letter of this is 'g', which tells us that the last command typed in the 'Run' window was to execute notepad. Also, the LastWrite time of the RunMRU key will correlate with the last application executed in 'Run', or in this case application 'g'.
With the information provided from the RunMRU key, an examiner can gain a better understanding of the user they are investigating and the applications that are being used. In reference to Figure 2, it is apparent the user has sufficient knowledge of the Windows operating system - based on applications that have been executed, such as msconfig, cmd, sysedit, and regedit.
Figure 2 - RunMRU key

UserAssist

The UserAssist key, HCU\Software\Microsoft\Windows\CurrentVersion \Explorer\UserAssist, contains two or more subkeys which have long hexadecimal names that appear as globally unique identifiers (GUIDs). Each subkey records values that pertain to specific objects the user has accessed on the system, such as Control Panel applets, shortcut files, programs, etc. These values however, are encoded using a ROT- 13 encryption algorithm, sometimes known as a Caesar cipher. This particular encryption technique is quite easy to decipher, as each character is substituted with the character 13 spaces away from it in the ASCII table. A much faster and easier method to decipher this code is with the use of an online ROT-13 decoder, such as http://www.edoceo.com/utilis/rot13.php.
Figure 3 - UserAssist Key
Figure 3a - ROT-13 cipher decoded

With the UserAssist key, a forensic examiner can gain a better understanding of what types of files or applications have been accessed on a particular system. Even though these entries are not definitive, for they cannot be associated with a specific date and time, it may still indicate a specific action by the user.
For instance, in the example of Figures 3 and 3a the decoded value can show a potential amount of information. First, it tells the name of the user profile - 'Cpt. Krunch' - from which the .exe was executed from. Cpt. Krunch could also indicate a handle or an alias of some sort. Second, by researching 'p2ktools.exe', it tells that it is a program used for editing and managing Motorola cell phones. Finally, it shows the user has the p2ktools folder in a parent directory called 'Razor programs', which is located on their desktop. Not only does this give the location of where similar programs may reside, but the name of this directory is a good indicator that the suspect has a Motorola Razor cell phone. If so, that too should be seized for further analysis.

Wireless Networks

Wireless networks today are popular and are only becoming more popular. A wireless ethernet card picks up wireless access points within its range, which are identified by their SSID or service set identifier. When an individual connects to a network or hotspot the SSID is logged within Windows XP as a preferred network connection. Unsurprisingly, this can be found in the Registry in the HKLM\SOFTWARE\ Microsoft\WZCSVC\Parameters\Interfaces key. When opening this Registry key there may be subkeys beneath it, like UserAssist, that look like GUIDs. The contents of these should contain the values 'ActiveSettings' and 'Static#0000'. There may be additional values that begin with 'Static#' and are sequentially numbered. In the binary data of these 'Static#' values are the network SSIDs of all the wireless access points that system has connected to. This can be seen by right clicking the value and selecting 'modify', as shown in Figure 4.
Figure 4 - SSID 'flynn-net'
In addition to logging the name of the SSID, Windows also logs the network settings of that particular connection - such as the IP address, DHCP domain, subnet mask, etc. The Registry key in which this can be found is HKLM\SYSTEM\ControlSet001\ Services\Tcpip\Parameters\Interfaces\, which is illustrated in Figure 4a.
Figure 4a - Network settings of SSID 'flynn-net'
Based on this wireless network information, a Forensic examiner can determine if a user connected to specific wireless access point, the timeframe, and their IP address they were assigned by the DHCP server. For instance, if it were a case about a child pornography suspect that was war-driving to various network connections and using them illegally, these methods would be very useful. Given the suspect's computer to run an analysis on would make it possible to see what network connections they were using and the IP address that was assigned to further support a subpoena of the ISP.

LAN Computers

Windows XP implements a network mapping tool called My Network Place, which allows users to easily find other users within a LAN or Local Area Network. A computer on a properly configured LAN should be able to display all the users on that network through My Network Place. This list of users or computers, like many other things, is stored in the Registry. Therefore, even after the user is no longer connected to the LAN, the list of devices still remain, including desktop computers, laptops, and printers. The Registry key where this information is stored is HKCU\Software\Microsoft\ Windows\CurrentVersion\Explorer\ComputerDescriptions.
The ComputerDescriptions key is useful in determining whether or not a user was connected to certain computers or belonged to a specific LAN. Figure 5 displays the output of this key.
Figure 5 - List of computers associated with on a LAN

USB Devices

There is sufficient information on this topic to write an entire research paper on, however, for the scope of this paper only the basics will be discussed to show the most relevant Registry keys.
Anytime a device is connected to the Universal Serial Bus (USB), drivers are queried and the device's information is stored into the Registry (i.e., thumb drives). The first important key is HKLM\SYSTEM\ControlSet00x\Enum\USBSTOR. This key stores the contents of the product and device ID values of any USB device that has ever been connected to the system. Figure 6 reveals the contents of this key. All of which can be interpreted - there lists an ipod, two external hard drives, a digital video camcorder, and several different thumb drives.
Figure 6 - Contents of USBSTOR key
Beneath each device is the Device ID, which is also a serial number. The serial numbers of these devices are a unique value assigned by the manufacturer, much like the MAC address of a network interface card. Therefore, a particular USB device can be identified to determine whether or not it has been connected to other Windows systems. Carvey mentions in his article The Windows Registry as a Forensic Resource, an important consideration to keep in mind regarding USB device IDs. Not every thumb drive will have a serial number. Particularly, those that have an '&' symbol for the second character of the device ID. In reference to Figure 6, the Device ID that is pointed out has a serial number. However, if the '0' was an '&' that would indicate to an examiner that the device doesn't have a designative serial number. An example of a device that doesn't have an assigned serial number can be seen in Figure 6a, a Western Digital 250GB external hard drive.
Figure 6a USB device without a designated Device ID
Knowing what USB devices have been connected to a system can assist an examiner in collecting additional evidence that may be crucial to the investigation.

Mounted Devices

There is a key in the Registry that makes it possible to view each drive associated with the system. The key is HKLM\SYSTEM\MountedDevices and it stores a database of mounted volumes that is used by the NTFS file system. The binary data for each \DosDevices\x: value contains information for identifying each volume. This is demonstrated in Figure 7, where \DosDevice\F: is a mounted volume and listed as 'STORAGE Removable Media'.
Figure 7 Identification of volume \DosDevice\F:
This information can be useful to a digital forensics examiner as it shows the hardware devices that should be connected to the system. Therefore, if a device is shown in the list of MountedDevices and that device isn't physically in the system, it may indicate that the user removed the drive in attempt to conceal the evidence. In this case, the examiner would know they have additional evidence that needs to be seized.

Internet Explorer

Internet Explorer is the native web browser in Windows operating systems. It utilizes the Registry extensively in storage of data, like many applications discussed thus far. Internet Explorer stores its data in the HKCU\Software\Microsoft\Internet Explorer key. There are three subkeys within the Internet Explorer key that are most important to the forensic examiner. The first is HKCU\Software\Microsoft\ Internet Explorer\Main. This key stores the user's settings in Internet Explorer. It contains information like search bars, start page, form settings, etc. The second and most important key to a forensic examiner is HKCU\Software\Microsoft\ Internet Explorer\TypedURLs. Figure 8 demonstrates the content of what the TypedURLs key displays.
Figure 8 TypedURLs key
From this data an examiner could conclude that the user possibly has a gmail and hotmail email address, they engage in online banking at tdbanknorth, is interested in digital forensic websites, and that they perhaps go to college at Champlain and have been researching apartments in the area.
The third subkey that may interest an examiner is HKCU\Software\Microsoft\ Internet Explorer\Download Directory. This key reveals the last directory used to store a downloaded file from Internet Explorer, giving the examiner an idea as to the location of where the user stores their files.

Opera, Netscape, and Firefox

It is the best to my knowledge that none of these browsers utilize the Registry in the way that Internet Explorer does. Internet Explorer stores web history in a file called Index.dat, which is referenced in the Windows Registry database - hence the reason we can see the history contents in the TypedURLs key.
Opera on the other hand, stores its history in a file called opera.dir. The default location of this file is C:\Documents and Settings\User Profile\Application Data\Opera\Opera\profile\. Upon installing and using this browser, the only remnants of Opera located in the Registry were install paths. In fact, according to the features of Opera (http://operawiki.info/WhyOpera), two of the many reasons people choose to use this browser is because it doesn't use the registry to store data and the size of it is very small. It is only a 1.8mb executable and according to the 'Add or Remove Programs' applet in Control Panel; the total installation is only 5.33mb.
Like Opera, Netscape and Firefox leave limited footprints (other then install paths) regarding Registry activity. Netscape and Firefox both store web history in a history.dat file, which is in ASCII format and plainly visible when opened. The location for the history.dat file in Firefox is C:\Documents and Settings\User Profile\Application Data\Mozilla\Firefox\Profiles\x.default\ and Netscape is C:\Documents and Settings\derrick.farmer\ Application Data\Netscape\NSB\Profiles\x.default\. An in-depth analysis of these browsers is out of the scope of this particular paper as they are not relevant in a Windows Registry examination.

P2P Clients

Peer-to-Peer (P2P) networks are notorious of providing users with the ability to distribute illegal and sometimes unethical materials. Three popular P2P clients were downloaded, installed, used, and examined for the purpose of this research. The clients that were used are Limewire, Kazaa, and Morpheus.

Limewire

The research conducted on Limewire was somewhat inconclusive in regards to a Registry examination. There were very minimal footprints of user activity and no logs of searches or downloaded files could be found. The most helpful thing discovered in the Registry was install paths of the program. Knowing this information would give the exact location of where to look in the file system. In a default installation of Limewire the location of the install directory is C:\Program Files\Limewire and the share directory is C:\Documents and Settings\User Profile\Shared.

Kazaa

Kazaa, however, was a bit more successful. Two Registry keys of interest were discovered. The first was HKCU\Software\Kazaa, and contained many user settings that could be useful to an investigator. For instance, beneath the Kazaa key there is a subkey called ResultsFilter, which shows the value for the “adult_filter_level”. This setting will filter adult content from search results. If the value of the adult_filter_level is (1) it is enabled and if it is (0) it is disabled. By default Kazaa enables the adult filter, so if this setting is disabled then it's a good indication the user has taken the initiative to do so within the Kazaa options menu. Figure 9 shows the location of this key and the information in which it contains.
Figure 9 Kazaa key
The other Kazaa Registry key that is worth pointing out is HKLM\Software\ Kazaa. This key contains subkeys that hold connection information and the destination directory of the downloaded files, which show that a default installation of Kazaa stores downloaded files to C:\Program Files\Kazaa\My Shared Folder.

Morpheus

Of the three P2P clients that were researched, Morpheus was the only one that kept a log in the Registry of recently searched for keywords or phrases. The location of this key is HKCU\Software\Morpheus\GUI\SearchRecent and can be seen in Figure 10.
Figure 9a Morpheus recent search list
If an examiner is investigating a case where the user is suspected to have used Morpheus to download illegal content, this key could be very useful in seeing exactly the type of material the user was querying.

One Thing in Common

Research of these three P2P clients revealed one Registry key that they all had in common:
HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\ FirewallPolicy\StandardProfile\AuthorizedApplications\List This is a list of applications that are allowed 'outside access' by the Windows Firewall that was implicated in SP2. If the P2P programs are not included in this list then they wouldn't be assigned a TCP or UDP port to access the P2P client's server and would consequently be blocked. Therefore, any type of program in use for file sharing purposes should appear on this list. This would be a great place for a forensic examiner to look in determining if the system has other potential file sharing applications that have been overlooked.
Figure 9b Firewall Authorized Applications key

Overview

The following list includes a brief recap of the Registry keys discussed in this paper.
o HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
o HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist
o HKLM\SOFTWARE\ Microsoft\WZCSVC\Parameters\Interfaces
o HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\
o HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ ComputerDescriptions
o HKLM\SYSTEM\ControlSet00x\Enum\USBSTOR
o HKLM\SYSTEM\MountedDevices
o HKCU\Software\Microsoft\Internet Explorer\Main
o HKCU\Software\Microsoft\Internet Explorer\TypedURLs
o HKCU\Software\Microsoft\Internet Explorer\Download Directory
o HKCU\Software\Kazaa
o HKCU\Software\Morpheus\GUI\SearchRecent
o HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\ FirewallPolicy\StandardProfile\AuthorizedApplications\List

For a comprehensive list of Registry keys that directly relate to a computer forensic examination, many of which were not discussed in this paper, refer to AccessData's PDF document Registry Quick Find Chart.
http://www.accessdata.com/media/en_US/print/papers/wp.Registry_Quick_Find_Chart.en_us.pdf

Conclusion

Given the popularity of the Windows operating system - in homes and businesses - it is important for computer forensic experts to understand the complexity of the Windows Registry. The information and potential evidence that reside in the Registry make it a significant forensic resource; uncovering this data can be crucial to any computer related investigation. By understanding the fundaments of the Registry from a forensics standpoint, an examiner can develop a more precise account on what actions occurred on the given machine. This report is by no means conclusive in terms of a Registry Examination. It presents some explanations and examples of what types of data can be found, how it can be found, and why it may be relevant to an examination. For as long as operating systems are dependent upon the Registry as a configuration database, and for as long as applications continue to use that database for storage, there will always be different locations to discover that provide evidential support in an investigation.

References

Books

Honeycutt, Jerry. Microsoft Windows Registry Guide. 2nd. Redmond, WA: Microsoft Press, 2005.
Kruse, Warren G., and Jay G. Heiser. Computer Forensics: Incident Response Essentials. New York: Addison-Wesley, 2004.
Nelson, Bill, Amelia Phillips, Frank Enfinger, and Christopher Steuart. Guide to Computer Forensics and Investigations. 2nd. Canada: Course Technology, 2006.
Journals
Carvey, Harlan. "The Windows Registry as a forensic resource." Digital Investigation: The International Journal of Digital Forensics & Incident Response 2(2005): 201-05.
Carvey, Harlan, and Cory Altheide. "Tracking USB storage: Analysis of windows artifacts generated by USB storage devices." Digital Investigation: The International Journal of Digital Forensics & Incident Response 2(2005): 94-100.

Online

Carvey, Harlan. "Windows Incident Response." [Weblog Mounted Devices] 21 Dec 2004. 8 Apr 2007 .
Davies, Peter. "Forensic Analysis of the Windows Registry." Peter Davies. 2006. 3 Feb 2007 .
Jones, Kieth J., and Rohyt Belani. "Web Browser Forensics, Part 1." Security Focus. 30 Mar 2005. 13 Apr 2007 .
Microsoft, "Description of the Microsoft Windows Registry." Help and Support. 27 Jan 2007. Microsoft Corp. 8 Apr 2007 .
Microsoft, "INFO: Working with the FILETIME Structure." Help and Support. 23 Jan 2007. Microsoft Corp. 8 Apr 2007 .
Opera, "Why Choose the Opera Internet Suite'." Operawiki. 2007. 13 Apr 2007 .
'Registry Quick Find Chart." AccessData. 2005. AccessData Corp. 1 Apr 2007 .
"ROT 13 Encoder/Decoder." Consulting, Development, Research, and Support. 2007. Edoceo, inc.. 14 Apr 2007 .
Srinivasan, Ramesh. "Registry MRU Locations." Ramesh’s Site: Troubleshooting Windows. 2006. 14 Apr 2007 .
Websense, "Emerging Threats: Peer-to-Peer File Sharing." Advanced Systems Group. Websense, Inc. 13 Apr 2007 .
Wong, Lih Wern. "Forensic Analysis of the Windows Registry." Forensic Focus. 1 Feb 2007 .