Digital forensics

Windows systems and artifacts in digital forensics, part I: registry

Learning about artifacts in Windows is crucial for digital forensics examiners, as Windows accounts for most of the traffic in the world (91.8 of traffic comes from computers using Windows as their operating system as of 2013) and examiners will most likely encounter Windows and will have to collect evidence from it in almost all cyber-crime cases. Below, we will discuss several places from which evidence may be gathered and ways to collect information from Windows.

Windows actually provides a great abundance of artifacts and being aware of these artifacts is helpful not only for examiners but for companies and individuals (just to name a few reasons) trying to permanently and irrevocably erase sensitive information or perform informal investigations.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

Before we start, we have to mention that collecting evidence is not the sole challenge to examiners; the challenge is to locate and identify, collect, preserve, and interpret the information; whereas collecting it is only one piece of the puzzle. In this paper, we will only be able to have a glimpse of this wealth of artifacts but its forensic significance will be immediately unveiled to us.

The things you will find in this article

In the first part of this series we are going to discuss the Windows registry, its structure, backups and supporting files, examples from case files which reveal how instrumental the registry might be in prosecuting suspects, and some open source tools.

Registry

What is the Windows registry and what is its structure?

The Windows registry is an invaluable source of forensic artifacts for all examiners and analysts. The registry holds configurations for Windows and is a substitute for the .INI files in Windows 3.1. It is a binary, hierarchical database and some of its contents include configuration settings and data for the OS and for the different applications relying on it. The registry not only keeps records of OS and application settings but it also monitors and records user-specific data in order to structure and enhance the user's experience during interactions with the system. Most of the time users do not interact with the registry in a straightforward manner, but they interact indirectly with it via installation routines, applications, and programs, such as Microsoft Installer files. Nonetheless, system admins have the capability of interacting directly with the registry via regedit.exe (the registry editor) that comes with all varieties of Windows.

Figure 1: How the Windows registry looks like through the eyes of the registry editor, along with the registry's nomenclature.

Figure 1 gives the impression that the structure of the registry is the much familiar folder-based one, but this is merely an abstraction designed by the registry editor. In reality, the registry is just a collection of files located on the user's hard drive. The registry files in charge of the system and the applications on the user's machine are located in the following path: Local Disk:Windowssystem32config, while the registry files in charge of data that is related to the user and his application settings are located in the Windows user profile directory called ntuser.dat and usrclass.dat.

Furthermore, Figure 1 reveals that the binary structure of the registry is based on cells, the notable ones being keys and values. Although additional cell types exist, it can be said that they act as pointers to other keys (subkeys) and values. Values encompass data and they do not direct to other keys.

Registry hives and their supporting files as a useful additive for forensic analysts

Keys, subkeys, and values are typically part of different hives, which are logical groups of the former and have a set of supporting files that encompass backups of their data. User profile hives can be found in the HKEY_USERS key and they store specific registry data that is related to the user's application settings, desktop, and environment as well as holding data related to his/her printer(s) and network connections. Each user on a machine has his/her own hive, which is responsible for his/her user profile.

Below, we have enumerated some extensions of supporting files and have shown what information to expect from such a file extension:

No extension = a thorough replica of the hive's data.

Extension .alt = a duplicate of the HKEY_LOCAL_MACHINESystem hive. It should be noted that the system key is the sole key whose backup files use this file extension as it is a crucial hive.

Extension .log = a record of modifications in the hive's keys and values.

Extension .sav = a backup replica of a hive.

After discussing the types of supporting files and what data they hold, we can move on to show what file names the supporting files of the standard hives have.

Below is a graphic (Figure 2) that illustrates the standard hives and their supporting files.

Points of interest for forensic analysts in the registry's key cell structure

Deleting a registry key would not make it "go" somewhere but it would rather cause its size value to be set to a positive one while undeleted keys have a negative value. Essentially, the space consumed by the registry keys gets labeled as available and it becomes possible to overwrite it.

From the point of view of a signed integer, a registry key has a negative value but from a hexadecimal point of view, the key structure is indeed positive. The code "Unpack("l",$dword)" may be employed to parse the DWORD value as a signed integer using Perl. Keys contain the useful LastWrite time, which pinpoints when the last modification of the key took place. Modification may consist of changes to an existing subkey or value, the deletion of existing subkeys or values, or the creation of new ones.

Figure 3 reveals the most notable key cell structure elements from the point of view of a forensic analyst. Their size in bytes and their offset are also included in the illustration.

Some preliminary information:

Registry keys typically begin with a four-byte double word that contains the size of the particular key.

After the double word, there is a key node identifier "nk," which tell us that what we are looking at is a key and not a value.

Subsequently, there is a two-byte value that reveals the node type. "0x2C" indicates a root key cell whereas "0x20" indicates an ordinary key cell.

The LastWrite time is actually "a 64-bit FILETIME object that marks the number of 100-nanosecond epochs since midnight of 1 January 1601," but it can be perceived as equivalent to the time when the file was last changed, since it reveals when a modification was made to the key.

An offset pinpoints the distance between the start of an object and a particular point or element, usually within the same object.

Registry case study

Below, we will be looking at two cases in the solving of which the registry proved to be instrumental.

Credit card theft

The Windows registry facilitated law enforcement in solving a credit card case in Houston, Texas. The suspects were a man and his wife who bought goods from the Internet with pilfered credit card numbers. They were detained as a result of a controlled drop of commodities ordered from the Internet. When ntuser.dat, the registry, and the protected storage system provider were scrutinized, a list of numerous names, addresses, and credit card numbers were found. It turned out that the information in the list was applied online to purchase goods as well, and after an additional investigation it was concluded that these credit card numbers were used illegally, without any permission from their owners.

The data retrieved from the registry was sufficient to exact more search warrants which led to the arrest of 22 persons and the retrieval of illegally bought goods worth more than $100,000.

The development of the events turned out to be the following:

All defendants pled guilty to organized crime accusations and served time in jail, which may have not been possible without the help of the Windows registry.

Child pornography

Guests at a hotel located in a little town near Austin, Texas, called the law enforcement authorities after seeing a person, who looked intoxicated, walking around the hotel naked. When the law enforcement officials arrived after the 911 call they located the individual and concluded that he was, in fact, staying at that hotel so they escorted him to his room and there they discovered that he was staying with another person—but what surprised them was that a picture of child pornography was being projected on the wall. The picture was projected through a laptop that had a projector attached to it. In close proximity to the laptop, there were two external hard drives.

The individual who was already in the room was surprised by the entry of the police and he asserted that the laptop was his but that the external drives belonged to his intoxicated fellow and had nothing to do with him. The equipment was immediately confiscated and sent for analysis. Forensic clones were created from the laptop and the two external hard drives without delay. The initial analysis of the external hard drives revealed the existence of pictures and movies of child pornography on them.

Consequently, the forensic analysts had to find out whether any of these external drives were connected to the laptop of the individual asserting that he had nothing to do with them. Thus, the laptop's system registry file was examined to match any entries in the USBStor key with the external drives. This turned out to be a fruitful examination, as listings for the external drives were found as well as their hardware serial numbers.

Following these steps, the forensic analysts had to determine whether their results were authentic, so they linked the suspect's external drives to their lab's computer system, using a freshly installed version of Windows. To avert any alteration to the clones of the EHDs a write blocker was linked between the two drives and the system.

Lastly, they examined the clone's system registry file and the USBStor keys and came to the same conclusion, that the EHDs listings were identical to the defendant's, in addition to having the same hardware serial numbers, and this proved that at some point in time the EHDs were connected to the suspect's laptop. Ultimately, the culprit was sentenced for possessing child pornography.

Using open source tools for the examination of the Windows Registry.

Modules

The Win32::TieRegistry is a Perl module that digs out data not only from local systems but also from remote ones. It can be used on live Windows systems. Equivalent to this is the Python module winreg, which is presented for the achievement of the same goal. However, tools like Win32::TieRegistry are not cross-platform and will not work on default OS X or Linux installations, as they depend on the native Windows API.

There are many Perl scripts that take advantage of the Win32::TieRegistry Perl module, such as regscan.pl. You may also want to create your own Perl scripts that will collect the LastWrite time from the registry hives so you can sort and parse the information in any way you like.

Considering you have images collected from the system, the Perl module Parse::Win32Registry seems like a good choice, partially because it is cross-platform. The Win32::TieRegistry rests on the shoulders of the API offered by Windows systems and grants us entry into the registry information on the live systems, while the Parse::Win32Registry module retrieves hive files in their binary form and gives us a level of abstraction that enables us to open a registry value simply by procuring the module with a key path like "Software/Python/PythonCore/3.3/Modules."

Brief overview of some open source tools

F-Response is a software utility that allows examiners to "conduct live forensics, data recovery, and eDiscovery over an IP network using their tool(s) of choice." If you resort to this utility as a means of widening the scope of your incident response range and capacity, you can be misled into thinking that you are intermingling with a live system when, in fact, while utilizing F-Response you will be communicating with hive files in a binary form; therefore, tools based on the Parse::Win32Registry will be handier than tools based on the Win32::TieRegistry module.

A tool that that is very beneficial in investigations is RegRipper, which not only parses registry hives extracted from images but also parses registry hives extracted from within a mounted image and from a system that was entered through F-Response's application. RegRipper bases its dealings with the registry hive files on the Parse::Win32Registry module. It operates through plugins that are tiny files comprising Perl code, which pull out various types of information. rr.pl is the main script of the application, which can be categorized as a GUI interface to a motor that handles all those plugins.

The application can be launched in a Linux environment on which WINE has been installed and it comes in various Linux-centered and forensic-based toolkits such as PlainSight.

RegRipper also contains a command line interface tool named rip.pl that makes it possible for examiners to execute particular plugins against a hive or run listings of plugins (as they can do with RegRipper's GUI - rr.pl). If you are searching for a way in which to obtain concrete data out of a hive or to test recently produced plugins, Rip.pl comes in handy.

Several scripts were created to exploit the property of registry keys that they do not go away after deletion. Such an exploit, if it is appropriate to name it so, is a Perl script that was made in 2008 and got the name Regslack. Regslack parses through hive files and recovers removed keys.

Conclusion

This article is a part of a series, "Windows System Artifacts in Digital Forensics." and objects of examination in the consecutive articles will be Windows file systems, registry, shortcut files, hibernation files, prefetch files, event logs, Windows executables, metadata, recycle bin, print spooling, thumbnail images, and lists of recently used applications, along with a brief discussion of how to find removed information and how to work with restore points and shadow copies.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

Note that most of the abovementioned artifacts are Windows-specific and are unique to this operating system.

Further reading:

Carvey, Harlan, "Windows Registry Forensics: Advanced Digital Forensic Analysis of the Windows Registry," 2011

Sources

• Bott Ed, "Latest OS share data shows Windows still dominating in PCs,"
• Windows Dev Center, "Registry Hives."
• Wikipedia, "Windows Registry."
• F-Response
• Microsoft Support, "Windows registry information for advanced users."
• Cory Altheide & Harlan Carvey, "Digital Forensics with Open Source Tools,"
• Sammons John, "The Basics of Digital Forensics: The Primer for Getting Started in Digital Forensics," 2012