本文原作者John J. Barbara，所有权利归原作者所有。
作者简介：
John J. Barbara owns Digital Forensics Consulting, LLC, providing consulting services for companies and laboratories seeking digital forensics accreditation. An ASCLD/LAB inspector since 1993, John has conducted inspections in several forensic disciplines including Digital Evidence. John is the General Editor for the “Handbook of Digital & Multimedia Forensic Evidence” published by Humana Press. He can be reached at jjb@digforcon.com.
During the last fifteen years or so, computers have revolutionized the work place. They store or can access information required by workers to perform their job functions. However, regardless of the policies, rules, and procedures management puts into place to protect the confidentiality and integrity of their digital information, breaches continually occur. The following scenario describes one such breach:
An employee in a stock investment company informs her manager that several of her coworkers have violated their personal conduct contracts and may also be involved in illegal activities. She states that during the last week she saw two coworkers use their work computers to send e-mails containing insider trader information to their friends, a third coworker copying the company’s proprietary “Stock Market Trends and Analysis” software onto a flash drive, and a fourth coworker printing confidential investment portfolios.
How is management going to handle this situation? A typical approach would be to confront the workers. However, they most likely would deny any wrongdoing and probably try to obfuscate any potential evidence. Probably the best approach would be to covertly triage the live computers and perform post-mortem examinations of their hard drives. Frequently a business or corporation’s IT department members will lack the necessary qualifications or experience to perform these types of forensic examinations. This is not uncommon since IT personnel normally are not trained as forensic examiners. Usually management will have to contract with an external digital forensics consulting firm to provide the services. In today’s world, it has become essential that management have processes in place (i.e. a plan) such that when an intrusion occurs or employee misconduct is alleged, they will have a firm foundation to support and assist with any potential civil or criminal proceedings. Failure to do so can have a detrimental effect upon the business or corporation.
Background
A Windows computer system has several forensically important areas where probative information can be found: in the computer’s RAM (if the system is live), in the Registry, or on the computer’s hard drive. The examination and extraction of probative information from a live computer system involves the use of triage tools which themselves will make changes to those same forensically important areas! Although this violates the “golden rule” of digital forensics, in some circumstances there is no alternative. Presuming that examiners have previously verified the functionality of their triage tools, they should have a fairly good understanding, and be able to document, what changes are made to a live computer system when they use those tools.
Unless they are involved in incident response, examiners are not often confronted with having to image a live system. Normally they would forensically image computer hard drives post-mortem, in a controlled work environment. The image would then be examined for probative information. Most forensic tools incorporate automated built-in features such as recovering deleted folders, performing keyword searches, carving data from unallocated space, searching directories and files, and so forth. Automated features are a necessity as it would be extremely labor intensive for an examiner to manually search a hard drive. In today’s digital forensics environment, examiners must have specialized training, knowledge, skills, abilities, tools, and experience to ensure reliable and repeatable results when triaging either a live system or examining a computer hard drive post-mortem.
What Is the Windows Registry and What Does It Do?
Early Windows operating systems included a “WIN.INI” file (which controlled the desktop and all applications on the computer system) and a “SYSTEM.INI” file (which controlled the computer’s hardware). They also used the configuration files “config.sys” (which loaded device drivers) and “autoexec.bat” (which ran startup programs and set environment variables). When Windows 3.1 was introduced, it was initially targeted to the corporate work environment. One of the assumptions made was that very few Windows applications would be installed on each computer. This would then limit the number of stored system and application settings. Since program developers still needed to store application specific settings, they used individual “.ini” human readable text files which were linked to the “WIN.INI” file. These were generally organized in groups located in a shared location. However, there were a number of drawbacks to this practice: it did not allow for user-specific settings in a multi-use environment; there were no rules placed upon their storage by the operating system; their proliferation and storage anywhere on the hard drive made it difficult or virtually impossible to manage and optimize their performance; and their size limitations and slow access often hindered system operation.
The release of Windows 95 introduced a new concept, the “Registry.” Its purpose was to store all application settings in a standardized binary format in a centralized location and replace text-based configuration and “.ini” files. Because it provided one unified solution for accessing both system and application settings, the Registry was initially praised by developers, users, and administrators. Its advantages included: the binary format allowing for more efficient file parsing; Registry settings loading from user-specific paths; permitting multiple users to share the same computer; accessing a computer remotely, allowing for ease of backups and restorations. However, the introduction of the Registry created another whole set of unintended consequences: it now became more difficult to back up and recover individual applications; automated installers and uninstallers became more complex because configuration settings had to be created by the applications; a damaged or corrupted Registry might fail to load the device drivers necessary to boot the system. With the continuing requirements and demands of complex applications and network solutions, each iteration of the Windows Registry has grown larger and more complex.
The Microsoft Computer Dictionary, Fifth Edition, defines the Registry as: “A central hierarchical database used in Microsoft Windows 9x, Windows CE, Windows NT, and Windows 2000 used to store information that is necessary to configure the system for one or more users applications and hardware devices.” Windows XP, Windows Vista, and Windows 7 also contain a Registry. Although referred to as a “central hierarchical database,” the Registry is in fact a collection of files that are located in the “C:\Windows\System32\config” and “C:\Users\(Username)\” directories (Windows 7). The Registry contains information that Windows continually references such as the applications installed on the computer, the user profiles, the hardware on or attached to the system, property sheet folder settings, the ports being used, application icons, and so on. From a forensic perspective, the Registry is a gold mine that can often provide probative information to an investigator. For instance, some of the information that can be found in the Registry includes:
- All the wireless networks that the computer has connected to
- Recent search terms
- Lists of the most recently used files or applications
- Autorun locations that list applications to automatically run when the computer is booted
- Contents of the User(s) desktop
- All USB storage devices that have been attached to the computer
- Malware (if it has installed itself as a service)
- The directory structure and file names contained on external devices that have been attached to the computer (pre-Windows 7)
While the Windows Registry is forensically important, frequently it is not captured during the triage of a live system. Similarly, it is often overlooked during post-mortem examinations. Daily, examiners are faced with many challenges: a lack of training to perform triage on a live system; examining multiple hard drives containing terabytes of data; dealing with pressures from management to complete an arbitrary, often unrealistic, quota of examinations per month; constantly juggling and prioritizing overwhelming case loads; shortages of personnel; and until recently, limited tools for examining Registry files. When faced with these challenges, it is easy to understand why the Registry is not often forensically examined.
System Restore and Restore Points
Many forensic examiners are not familiar with the Registry or its forensic importance. One way to gain first-hand knowledge is to explore the Registry on a live, non-forensic computer. However, before doing so, a word of caution is in order. Any changes made to the Registry, either intentionally or accidentally, could have an effect on the computer’s functionality. Therefore, it is recommended that a Restore Point be created before exploration begins. System Restore, which is used by Windows to regularly create and save Restore Points, can be used to manually create a current Restore Point. It is important to note that System Restore does not back-up nor recover personal files. Rather its function is to create Restore Points which are back-ups of the Registry, most drivers, and system files with certain extensions such as .exe, .dll, etc. The following steps can be taken to create a Restore Point:
- Click the “Start” button. Right-click on “Computer” and then click “Properties.”
- In the left pane under “Control Panel Home” click on “System Protection.”
- When the “System Properties” dialog box appears, click on the “System Protection” tab.
- Click on “Create.” The “Create a Restore Point” dialog box appears. Enter a name for the Restore Point and click “Create.” After the Restore Point has been created, close the dialog boxes.
Restore Points are extremely beneficial because they can restore a computer to an earlier point in time. This becomes particularly important when a computer does not function correctly after a new application, updated software, or a driver has been installed. Uninstalling the previously installed software often corrects the problem, however in some instances links or pieces can still remain scattered in different locations and continue to affect the computer’s functionality. When this occurs, it becomes necessary to restore the computer to an earlier point when it was functioning correctly. The following steps can be taken to restore a computer:
- Click the “Start” button. Right-click on “Computer” and then click “Properties.”
- In the left pane under “Control Panel Home” click on “System Protection.”
- When the “System Properties” dialog box appears, click on the “System Protection” tab.
- Click on “System Restore.” In the “System Restore” dialog box click “Next.” Select a Restore Point and then click “Next.”
- Confirm the Restore Point, and then click “Finish.” This should restore the selected Windows 7 configuration and then restart the computer.
- Log on to the computer and when the “System Restore” confirmation page appears, click “OK.”
Restore Points themselves can be of forensic importance because they represent snapshots of a computer’s Registry and system files. For instance, presume that a User creates a Restore Point, installs hacking software on his computer, hacks into a remote system to perform a malicious act, and then restores his computer to its previous state. Evidence of the hacking software installation would not be found in the current mounted Registry but would still be present in the Registry within a specific Restore Point. This is due to the fact that when System Restore is used, before reverting back to the selected Restore Point, System Restore creates another Restore Point which captures a current snapshot of the system. This Restore Point would contain the Registry information as it existed at the time of the malicious act.
Registry Hives
The Windows 7 Registry is not in actuality a central hierarchical database or one large file, but rather a set of files referred to as “Hives.” These files, located in the “C:\Windows\System32\config” and “C:\Users\(Username)\” directories, are updated each time a User logs onto the computer. (A list of their locations is also stored in the Registry itself under the “HKLM\SYSTEM\CurrentControlSet\Control\hivelist” Key). The files are as follows:
- C:\Windows\System32\config\DEFAULT: contains the default system information which is stored in the “HKEY_USERS\.DEFAULT” Key.
- C:\Windows\System32\config\SAM: contains information about the Security Accounts Manager (SAM) service which is stored in the “HKLM\SAM” key.
- C:\Windows\System32\config\SECURITY: contains the security information which is stored in the “HKLM\SECURITY” key.
- C:\Windows\System32\config\SOFTWARE: contains information about the computer’s software configuration which is stored in the “HKLM\SOFTWARE” Key.
- C:\Windows\System32\config\SYSTEM: contains information about the computer’s system configuration which is stored in the “HKLM\SYSTEM” Key.
- C:\Users\(Username)\NTUSER.DAT: contains the Registry settings for an individual Users account.
The Windows operating system has a built-in Registry Editor that can be accessed by typing “regedit” in the “Search programs and files” menu box on a live system. (Normally a forensic examiner would not access the Registry in this manner. Rather, the Registry might be copied from a live system using a triage tool or after acquisition of the hard drive, it could be examined from an opened acquisition image or copied and examined using specific Registry tools). When the Registry Editor window opens, the Registry appears not as individual files, but as one unified “file system.” The left-hand Registry Editor pane displays the hierarchal Registry Hives which are comprised of Keys and Subkeys. The right-hand Registry Editor pane displays the “Name,” “Type,” and “Data” for a particular Hive, Key, or Subkey. The left-hand pane is similar to the left-hand pane of the Windows Explorer file system with the Keys and Subkeys in the Hives being similar to Windows Explorer folders and subfolders. In the right hand pane, a Key’s “Name” is analogous to a file’s name within a Windows Explorer folder, its “Type” is analogous to a file’s extension, and its “Data” is analogous to the actual contents of a file. The naming convention for the Hives uses their Windows API definitions which all begin with “HKEY.” Frequently Hives are abbreviated to a three or four-letter short name starting with “HK.” A typical Windows 7 Registry consists of the following Hives:
- HKEY_CLASSES_ROOT (HKCR)
- HKEY_CURRENT_USER (HKCU)
- HKEY_LOCAL_MACHINE (HKLM)
- HKEY_USER (HKU).
- HKEY_CURRENT_CONFIG (HKCC)
Of the five Hives, HKLM and HKU are stored as files. The other three are shortcuts or aliases to these two Hives. HKCU is a symbolic link to subkeys in HKU, and HKCR and HKCC are symbolic links to subkeys in HKLM. Access to Registry Keys can be restricted by the use of Access Control Lists (ACL) which are lists of permissions that are attached to an object. An ACL can specify which Users have access to what objects as well as what operations can occur on a given object. For example, if an ACL for a file contains “John, Update” this would give the User “John” permission to “Update” the file. Security tokens acquired by applications or system security policies (predefined or configured) can also restrict access to Registry Keys. As a result, different Users may only see parts of the Registry hierarchy.
Brief Discussion of Registry Hives
A typical Windows 7 Registry consists of at least five Hives, each of which performs a different function. They are as follows:
HKEY_CLASSES_ROOT (HKCR) - HKEY_CURRENT_USER (HKCU)
- HKEY_LOCAL_MACHINE (HKLM)
- HKEY_USER (HKU)
- HKEY_CURRENT_CONFIG (HKCC)
HKEY_CLASSES_ROOT (HKCR)
The Hive contains thousands of Registry Keys and constitutes the majority of the Registry itself. Per-user settings, file associations, class registration for Component Object Model (COM) objects, as well as Programmatic Identifier (ProgID), Class ID (CLSID), and Interface ID (IID) data are contained in the Hive. File extension association Keys describe the file types and associated programs which can open and edit a particular type of file. Each Key stores the information as to what Windows is supposed to do when a User double-clicks on a file with that extension. For example, when a User double clicks on the hypothetical file “Windows 7 Registry.pptx,” PowerPoint will open the file. The Registry stores the necessary information to complete this action in the HKCR\.pptx Key.
HKCR is actually a compilation of the machine-based HKLM\SOFTWARE\Classes Key (which contains default file associations and class registration), and the User-based HKCU\Software\Classes Key (which contains per-User file associations and class registration). If a Registry Key exists in both Hives, but conflicts in some manner, the one in HKCU\Software\Classes takes precedence, which subsequently would then allow for registration of COM objects.
ProgID, CLSID, and IID Keys concern the technical aspects associated with computer programming. ProgID Keys are located under the file extension association Keys (for example, HKCR\.avi\OpenWithProgIds). Although CLSID Keys can be found under many Keys, the majority are located under the HKCR\CLSID Subkey. All IID Keys are located under the HKCR\Interface Subkey.
HKEY_CURRENT_USER (HKCU)
Registry Values in the Keys control or contain configuration information that is specific to the currently logged-on User. The information includes User level control and settings for folders, environmental variables, screen colors, printers installed, display settings, mapped network drives, keyboard layout, Control Panel settings, and so forth. The settings are stored in files located in two locations under the Users directory for each User who has logged onto the computer. Those files are the “C:\Users\(Username)\NTUSER.DAT” file and the “C:\Users\(Username)\AppData\Local\Microsoft\Windows\UsrClass.dat” file(s). Generic information applicable to all Users is normally found in the HKU Hive under the HKU\.DEFAULT Key). Unlike most of the other Registry Hives which are global (retain the same information for all Users), this Hive is User specific. Most Keys and their associated Values will differ from User to User on the same computer. The HKCU Hive is also a pointer to the User’s Security Identifier (SID) Key which is located in the HKU Hive.
The following are the Keys commonly found under the Hive:
- HKEY_CURRENT_USER\AppEvents
- HKEY_CURRENT_USER\Console
- HKEY_CURRENT_USER\Control Panel
- HKEY_CURRENT_USER\Environment
- HKEY_CURRENT_USER\EUDC
- HKEY_CURRENT_USER\Identities
- HKEY_CURRENT_USER\Keyboard Layout
- HKEY_CURRENT_USER\Network
- HKEY_CURRENT_USER\Printers
- HKEY_CURRENT_USER\Software
- HKEY_CURRENT_USER\System
- HKEY_CURRENT_USER\Volatile Environment
Many of the Keys can be of forensic interest to an examiner. For instance, the HKCU\Identities Subkey(s) correspond to an identity in Microsoft Outlook Express. The HKCU\Network Subkeys correspond to mapped network drives to which the computer connects when the User logs on. The Subkey name is the drive letter of the mapped networked drive and contains the configuration information to connect to the drive. All the User specific application settings for installed programs can be found in the HKCU\Software Subkeys. Depending upon the program, this could include information such as the version number, when it was installed, and a list of recent files accessed by the program.
HKEY_LOCAL_MACHINE (HKLM)
HKLM contains computer-specific settings applicable to all Users who log onto a particular computer and the majority of the configuration information for installed software (including the Windows OS). The Hive is actually a “container” for displaying the Registry data which is loaded by the various Subkeys. The following Keys can be found in the Hive:
- HKEY_LOCAL_MACHINE\BCD00000000
- HKEY_LOCAL_MACHINE\HARDWARE
- HKEY_LOCAL_MACHINE\SAM
- HKEY_LOCAL_MACHINE\SECURITY
- HKEY_LOCAL_MACHINE\SOFTWARE
- HKEY_LOCAL_MACHINE\SYSTEM
The Keys under HKLM can also be of forensic importance. For instance, HKLM\SAM is the local security database containing User’s and Group’s information. HKLM\SECURITY contains the Windows local security database. (Note: access to both these Keys is controlled by Access Control Lists and as such, they may not be able to be viewed directly on a live system). HKLM\SOFTWARE contains the computers applications settings. HKLM|SYSTEM contains the device driver and service configurations under the CurrentControlSet Subkeys.
HKEY_USER
HKU contains User-specific configuration information for each User who logs onto the computer. Each of the Keys corresponds to a User and is named with that User's SID. The Keys and Values under each SID control the User specific settings (installed drives, desktop, mapped drives, etc.). A typical Hive is as follows:
- HKEY_USERS\.DEFAULT
- HKEY_USERS\S-1-5-18
- HKEY_USERS\S-1-5-19
- HKEY_USERS\S-1-5-20
- HKEY_USERS\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000
- HKEY_USERS\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1001_Classes
The first four Keys are referred to as the System Accounts and will generally be the same from computer to computer. HKU\.DEFAULT contains global User information. HKU\S-1-5-18 pertains to the LocalSystem Account. HKU\S-1-5-19 is used to run the local services and is the LocalService Account. HKU\S-1-5-20 is the NetworkService Account which is used to run the network service(s). Other Subkeys are unique SIDs which are associated with individual Users and can be of considerable forensic importance. Their interpretation is as follows:
- “S” identifies the string as an SID.
- “1” is the version of the SID specification.
- “5” is the identifier authority value.
- “21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx” is the domain or local computer identifier. (Note: The numbering schema “xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx” will differ from computer to computer since it corresponds to individual, unique User accounts).
- “1000” is the Relative ID (RID). Any Group or User not created by default will have an RID of 1000 or greater.
- “1001_Classes” contains the per-User file associations and class registration.
A wealth of forensic information is contained in each SID. This includes the User’s Name, the number of times the User logged onto the computer, the date and time of the last logon, the date and time the last password was changed, number of failed logons, and so on.
HKEY_CURRENT_CONFIG (HKCC)
HKCC stores information about the hardware profile configurations currently being used. It is a symbolic link to HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current which is itself a link to the HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\xxxx. Data can be modified in any of the three Keys since they are all the same. The two Registry Keys normally found under the Hive are:
- HKEY_CURRENT_CONFIG\Software
- HKEY_CURRENT_CONFIG\System
The next column will discuss Registry Tools and information of forensic interest that can be recovered from specific Registry Keys.
Overview of Viewing and Capturing the Registry
There are several techniques that can be used to examine the Registry, each of which has its own merits. If time is of the essence (such as in an ongoing intrusion), an examiner could choose to access the Registry on a live system by using the computer’s “regedit” command. Obviously, this will make a number of changes to the computer and does violate “the golden rule” of digital forensics. However, in doing so, the examiner might be able to quickly determine the extent of the intrusion. Alternately, the examiner could use a USB triage device containing tools to view the Registry directly (e.g. Registry Commander) or to export it for further examination (e.g. FTK Imager’s “Obtain Protected Files” functionality). The USB device itself can also serve as the storage location for the exported Registry. Note, however, that attaching a USB device to a live system will update the Registry, again violating “the golden rule.” Prior to using this approach, it is extremely important for the examiner to have verified on a test computer what Keys are affected when a USB device is attached to a live system. Likewise, the tools themselves need to undergo some sort of verification and/or validation process before being used for examination purposes. Electronic and/or hard copy documentation must be maintained in both instances such that it can be available to demonstrate that no probative information was compromised on a target system.
As previously mentioned, Registry Commander (which also provides the “Last Write Time” when a Key was accessed) can be used to manually examine the Registry on a live system. However, thisoHowe could turn out to be a daunting, time consuming task. Another tool, such as Autorun, can be used to quickly provide a wealth of information about the Registry, such as what programs are configured to run during system boot-up or login. Alternately, FTK Imager can be used to capture and export the Registry for a thorough offline examination using other tools such as RegRipper, WRA, Registry Viewer, KUSTAR, or Registry Report. Using either of these methods, the examiner will only be concerned with examining the Registry itself.
If time is not an issue, the examiner can perform a live acquisition of the computer’s hard drive using a USB triage device containing an acquisition tool (e.g. FTK Imager’s “Create Disk Image” functionality). During the acquisition, changes will be constantly occurring to the computer hard drive and to the Registry itself. Depending upon the circumstances, the computer could be powered down and its hard drive acquired post-mortem either on-site or back at the examiner’s laboratory. In either instance, the image captured would have to be examined on a forensic computer using other forensic tools such as EnCase or FTK. The Registry could be examined manually or the files extracted and examined using the tools previously mentioned.
Registry Forensics: General Forensic Information
There are thousands of Keys in the Registry. Choosing which ones to examine would depend upon the type of investigation being conducted. As a simplified guide, many of the forensically important Keys can be grouped into several broad categories based upon what potential probative information they may provide: General Forensic Information, Attached Devices, Security Identifiers, and Intrusion Related Activities. (Note: the Keys discussed are by no means a complete listing and others not cited could be of importance. It up to each examiner to determine to what extent Registry Keys are to be examined.)
1. SYSTEM and USER INFORMATION:
HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion
Information about the version of Windows, the product key, the registered owner, the installation type, the system root directory, and other data are maintained in this Key.
2. LAST WRITE TIME:
Keys contain an associated Value called the “Last Write Time” (LWT) which is updated when a Key is created, modified, or accessed. Only the LWT of a Key can be obtained, not the LWT for a particular value. Knowing the LWT of a Key can infer the approximate date or time an event occurred. Although it may be difficult to determine what value was actually changed, it can be helpful in correlating the LWT of a Key and other sources of information, such as MAC times found in the file system.
3. C:\PAGEFILE.SYS:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Virtual memory configuration is controlled by this Key. Only those parts of a program and data that are currently in active use are stored in RAM. Other parts are held in the “pagefile.sys.” If the value of “ClearPagefileAtShutdown” in this Key is set to “1” then the “pagefile.sys” will be cleared upon system shutdown and potential probative information may be lost.
4. MOST RECENT USED (MRU):
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\ LastVisitedPidlMRU
HKU\[SID]\Software\Microsoft\Windows\CurrentVersion\Explorer\ ComDlg32\LastVisitedPidlMRU
MRU lists contain entries that are made when a user performs a specific action such as running an application. These two Keys contain the names of recently used executable files and their folder paths.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\ OpenSavePidlMRU
HKU\[SID]\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\ OpenSavePidlMRU
These Keys and their Subkeys maintain lists of all recently opened or saved files (.pdf, .txt, .jpg, .doc, .docx, ppt, pptx, etc.)
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
If a user enters commands into the “Run” dialogue box, an entry will be maintained in this Key.
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
This Key maintains a list of the last ten files that the currently logged on user accessed or executed via Windows Explorer and corresponds to the file listing found in “C:\Users\[Username]\Recent.”
5. RECENT SEARCH TERMS:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery
HKCU\Software\Microsoft\Windows Search\ProcessedSearchRoots\0003\Default
When searching for files or folders using Windows Explorer, the first Key will store the search query. The second Key points to the default path where the searches are stored, generally “C\Users\[(User]\Searches\oneindex—[User SID].”
6. INTERNET EXPLORER:
HKU\S-1-5-21-1116317277-3122546273-4014252621-1000\Software\Microsoft\ Internet Explorer\Main
HKU\S-1-5-21-1116317277-3122546273-4014252621-1000\Software\Microsoft\ Internet Explorer\TypedURLs
The first Key stores the user’s settings, information about search bars, start page, etc. and the second Key stores typed URLs entered into the address field. The last typed URL is “url1” and the first typed URL is “urlx” where “x” is the highest number in the list.
7. TIME ZONE INFORMATION:
HKLM\SYSTEM\ControlSet001\Control\TimeZoneInformation
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\TimeZones
The Value “ActiveTimeBias” in the first Key represents the current time difference from GMT/UTC in minutes and the value “Bias” represents the difference in minutes between GMT/UTC) and local time. For example, Eastern Standard Time has a Bias property value of -300 (minus five hours difference). The second Key’s Subkeys store information relating to all the various time zones around the world.
8. WINDOWS PROTECTED STORAGE:
HKCU\Software\Microsoft\Protected Storage System Provider
This Key securely stores the encrypted passwords for many applications. Passwords stored here can include those for Outlook Express (passwords created and maintained when the “Remember Password” option is selected), MSN Explorer (MSN Explorer’s “Sign In” and “AutoComplete” passwords), and Internet Explorer (protected sites and “AutoComplete” passwords). Since these Values are encrypted, another tool (e.g. Cain & Able, PassView, IE PassView, PStoreView, etc.) would have to be used to (hopefully) decrypt and view the passwords.
(Note: Software tools mentioned in this column should not to be considered an endorsement of those tools by DFI News or by the author. Prior to purchasing commercial tools or obtaining freeware tools, investigators and examiners should research those that are available to determine which best meet their technical and operational performance parameters. After procurement, the tools’ functionality must be verified before being used for forensic examinations.)