Registry Introduction


Even though Microsoft heavily promoted the use of the registry instead of separate configuration databases, starting as early as Windows 3.x, many application developers, including Microsoft, continued to use their own configuration files along with the registry for many years after the registry was introduced. As Windows moved from the Windows 9x platform to the Windows NT family, existing .INI files were kept only for backward legacy compliance. The registry grew from a little-used database to a huge application configuration store refractory. Today, registry files over 100 MBs in size aren't uncommon (although 11 MBs is the limitation in Windows 98).

Note 

You can still view Windows default .INI files, System.ini, and Win.ini by running many commands, including Sysedit.exe and Msconfig.exe.

The registry solution solved one problem, a single location for system and program information, but introduced many more. Problems such as corruption, large size, single points of failure, and infrequent backups have made the registry a source of criticism since the beginning. Although officially Microsoft claims that end users and administrators should not directly edit the registry, almost every troubleshooting technician can mentally recall numerous keys easily because of their familiarity with its structure. Often, a registry edit is the only way to solve a Windows problem. And like many computer databases, once data is written to it, it never leaves, even if unneeded. The registration database is prone to corruption and its ever-growing size can delay Windows booting up a minute or more.

Microsoft intends to replace or supplement the registry with the Windows File System (WinFS) in upcoming releases of Windows XP, Vista, and Server 2003. WinFS will consist of XML-enabled style data values stored in a SQL-like database. WinFS was initially going to be released in Windows Vista, but it was pulled by Microsoft and will instead be included in Windows XP Release 2. Because current applications are developed to use the registry and not WinFS, if you're a Windows admin0 be prepared to troubleshoot both in the coming years.

Registry Structure

The hierarchical registry database is divided into five different major sections, called hives or subtrees. The five hives, as shown in Figure 6-1, are HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS, and HKEY_CURRENT_CONFIG. They are often abbreviated as HKCR, HKCU, HKLM, HKU, and HKCC by authors, including in this book. You can explore the registry (and view, search, modify, and delete information) using either of the common Registry editing tools, Regedit.exe or Regedt32.exe. There are also a plethora of third-party tools that show information or allow editing of the registry (e.g., HiJackThis, Autorun, etc.).

image from book
Figure 6-1

Under each hive are keys, subkeys, values, and data — making up thousands of separate database entries. Keys are the first level under the subtrees, followed by the lower subkeys, the subkey values, and the data of each value. There can be one or more values under each subkey. Each value can contain data, whether decimal, binary, ASCII string, or another representational data (covered below). In Figure 6-2, the hive is HKLM, the key is \Software, the subkey is \Microsoft\Windows\Current Version\Run, the value is dla, and the data is C:\Windows\System32\dla\tfswctrl.exe.

image from book
Figure 6-2

Hives can be completely independent storage areas or display values and keys of different hives. In NT and later, most hives are stored as physical files in %Windir%\System32\Config or the location indicated by HKLM\System\CurrentControlSet\Control\hivelist. The files in %Windir%\System32\ Config are named Software, System, SAM, Security, Default, and UserDiff. Table 6-1 discusses each of the registry hive files. Unless otherwise noted, they can be found in %Windir%\System32\Config.

Table 6-1

Hive Name

Description

SAM

Contains information stored in the key HKLM\SAM regarding the Security Accounts Manager (SAM) database

Security

Contains the security information stored in the key HKLM\SECURITY

Software

Contains information stored in the key HKLM\SOFTWARE about the local computer's software configuration information

System

Contains information stored in the key HKLM\SYSTEM about the computer's system configuration

Default

Contains the default system information that is stored in the key KU\.DEFAULT

Ntuser.dat

Stored in the user's profile under \Documents and Settings\%UserProfile%, it represents the HKCU subtree.

As you can see, most of the files refer to the HKLM subtree. The registry files ending in the .Sav file extension are backup copies made just after the text-mode portion of the Windows install routine is finished. They are saved so that if the GUI mode portion of the install fails, the Setup program can restore the system to the end of the text-mode install and begin again. Forensic investigators can use their last modified file date to learn when the system was first installed. The files ending in .Log are transaction log files containing a record of the changes made to the registry.

Note 

Microsoft's Windows Vista will have registry virtualization for legacy (i.e., non-Vista) applications. It will redirect many HKLM registry changes to per-user locations. This will prevent many applications (and malware) installed by a single user from affecting all users on the same computer.

Registry Value Data Types

Most registry keys and subkeys eventually get down to the registry subkey values and the value's data. Data can be inputted several different ways (manually, scripting, GPOs, etc.) using a variety of different data types. The most popular data types are shown in Table 6-2.

Table 6-2

Data Type

Description

Reg_Binary

Hexadecimal characters type in two-digit, raw binary, hexadecimal form

Reg_Dword

Binary or hexadecimal characters type in as 4-byte ASCII characters. Related values are DWORD_LITTLE_ENDIAN (least significant byte is at the lowest address or in reverse) and REG_DWORD_BIG_ENDIAN (least significant byte is at the highest address or in normal forward order).

Reg_String or Reg_Sz

Fixed-length ASCII or Unicode character string

Reg_Expand_Sz

Variable-length ASCII or Unicode character string

Reg_Multi_Sz

Variable-length list or array of one or more ASCII or Unicode character strings

There are more data types than shown in Table 6-2. Not all versions of Windows have all data types. See http://support.microsoft.com/kb/256986/EN-US for more details.

HK_Local_Machine Subkeys

The HKLM subtree stores configuration information for hardware and software of the computer regardless of who is logged on. It contains five keys: Hardware, SAM, Security, Software, and System.

The Hardware key contains information about the physical hardware of the computer. The key HKLM\HARDWARE is not stored as a file, because it is re-created each time the system starts. Any values created during the Windows session are discarded when Windows is shut down. Hardware information about local devices, interrupts, and hardware configuration is stored under this key. You can view a lot of this information by using the Device Manager applet under the Control Panel. Windows and other applications can access this key to interface with the hardware appropriately. Malware rarely manipulates this key.

The SAM key is the SAM database that stores authentication and security information about the different security principals (i.e., user, group, computers, etc.). It is usually protected from direct manipulation, even by the Administrator, but as discussed in Chapter 4, several password-cracking tools can access it and extract password hashes.

The Security key contains a plethora of security information related to the local machine. Default permissions don't allow even Administrators to view the subkeys and values, but you can change permissions (covered below) to allow more access. The Security key contains things such as the cached logon passwords and Lsasecrets. By default, Windows caches the passwords of up to 10 different user profiles to assist in faster logons. Those passwords are stored in the HKLM\Security\Cache subkey. The Lsasecrets, which include Service account passwords, are stored in HKLM\Security\Policy\Secrets. Different user security information is stored under HKLM\Security\Policy\Accounts, by account SID number. The \Security key stores a variety of other information related to the local machine. There are several attack tools (e.g., Creddump, Cachedump, as covered in Chapter 4) that attack this key, although most automated malware programs attack the next HKLM key.

HKLM\Software is the most popular Windows key by legitimate users and malware. \Software contains registration and configuration information for the operating system and application software installed on the local machine. It contains many of the registry auto-run keys (including the most popular auto-run key, HKLM\Software\Microsoft\Windows\CurrentVersion\Run). It contains subkeys for nearly every installed software program. Most of the subkeys and values of interest to malware are located at HKLM\Software\Microsoft\Windows\CurrentVersion and HKLM\Software\Microsoft\ Windows NT\CurrentVersion. Table 1-1 in Chapter 1 listed the most popularly abused keys.

This is a good point to mention HKLM\Software\Policies. Most domain group policy settings under the Computer Configuration heading pushed down to the local machine by Active Directory are located here. Any policy setting configured here does not tattoo the registry — meaning if the group policy no longer applies, the pushed down settings are removed. Custom administrative templates can also push values to HKLM\Software\Microsoft\Windows\CurrentVersion\Policies, but this location creates unmanaged policies and they will tattoo the registry and remain in effect until the policy settings are deleted or modified (either manually or using group policy). On a related note, the HKCU\Software\ Policies subkey holds the settings pushed down from the User Configuration portion of group policy (more on this in Chapter 14).

HKLM\System is second in malware popularity only to HKLM\Software. It contains operating system information that controls system startup behavior, device drive loading, service configuration and loading, and overall OS operations. An example is HKLM\System\CurrentControlSet\Control\ Safeboot\Minimal. This subkey controls what services are loaded when the OS is booted in Safe mode. Many forensic investigators rely on Safe mode to remove any malware programs when searching for signs of infection and maliciousness. Many malware programs manipulate this key so that they are loaded and can thus manipulate or hamper forensic techniques even when the OS is in Safe mode. Several popular keys used by malware were shown in Table 1-1 of Chapter 1. If malware is attacking Windows, chances are greater than 95% that it will attack a subkey located under HKLM.

HK_Classes_Root

This subtree is used to list file associations, URI handlers (e.g., news://, aim:// in Internet Explorer), and COM file configuration information. HKCR is most commonly used to list the effective Windows file associations linking a particular file extension to one or more software programs which are supposedly designed to handle the particular file format. For example, clicking on a file ending in .Txt will normally result in Notepad being launched. Clicking a file ending in .VBS in Windows Explorer will result in Windows Scripting Host (Wscript.exe) being called, but clicking it in Internet Explorer will result in VBScript.dll being called to handle it. By default, Windows has hundreds of file associations.

File Associations in the Registry

HKCR lists the effective Windows file associations arising from the combination of HKLM\Software\ Classes and HKCU\Software\Classes. Starting with Windows 2000, file associations can be viewed or modified in any of the following three registry locations:

  • HKCR

  • HKLM\Software\Classes

  • HKCU\Software\Classes

Although file associations can be modified in any of the three locations, HKCR is only meant to be a registry area showing the effective associations. File associations set at the HKLM\Software\Classes location are in effect for all users of the computer unless specifically overridden by HKCU\Software\Classes. Associations in HKCU\Software\Classes take precedence for the currently logged on user. If a new value is written to HKCR and it does not exist in HKCU\Software\Classes, it is written to HKLM\Software\Classes and applies to all users on the computer. If the key or value already exists in HKLM\Software\Classes, the modification is written to HKCU\Software\Classes and only applies to the local logged on user. This is an important point to remember and one occasionally manipulated by malware. Forensic investigators, unaware of the other three file association location interactions, might be stymied by malware using the latter two keys instead of HKCR.

Under the registry key HKCR, applications are listed by either their file extension (e.g., Vbs), file type name (e.g., VBSFile), CLSID (e.g. {}), or handling module (e.g., Outlook.FileAttach). The HKCR subtree can be broken down into two main sections: upper-level file extensions and lower-level program modules and file associations.

The two different sections enable Windows to bind multiple file extensions into aggregate file types, and to simplify management of these. For example, one might have .Bmp,.Jpg,.Gif,.Tif, etc., all pointing to a file type called GraphicFiles, and define actions for these just once, under GraphicFiles. One could then define another file type called AlternateGraphicFiles and, by switching individual file extensions from one to the other, apply different sets of actions without having to destructively set these up for each file extension.

The upper level displays the file extensions associated with each registered program. Although most file extensions are three characters long, some file extensions are shorter and longer in length. The upper-level section is mostly a "pointer" to the related lower-level file associations. Together, both levels display a lot of information for each file type. The most important values include the following:

  • File association

  • File Extension

  • Associated Program and Action

  • CLSID (Class Identifier)

  • Mime Type Identifier

  • Default Icon

  • File Extension Display

  • File Handling (e.g., File Download Confirmation prompt)

Not all file associations have all these fields. At the top of HKCR (using Regedit.exe), you will see \*. This subkey tells Windows how to treat all newly registered file types if not instructed by the installing program or user. Directly under the \* subkey are hundreds of registered file extensions. Actually, not too much information is stored directly under the file extension subkey, but what is there is valuable and useful. For one, the Default value will list the associated registry key where more of the file association information is stored. For nearly every file association listed at the top of the HKCR key, there is another corresponding lower-level file association subkey holding more confirmation information. For example, the .Vbs file association has a Default value of VBSFile.VBSFile is a registry key located lower in HKCR and is where the majority of the information regarding the treatment of Visual Basic Script (.Vbs) files is stored. The top file association subkey will also list the CLSID of the associated program in the Persistant Handler value. The CLSID is a unique alphanumeric value given to each program or module. Windows and Internet Explorer often use the CLSID instead of the file extension to identify a file type handler.

The upper-level subkeys will also reveal MIME Type identifiers (discussed in Chapter 5). For example, the .Txt file association has the MIME Type identifier listed in the Content Type value, with data of text/plain. This means if a file is downloaded in Internet Explorer (or HTML-enabled e-mail) with a MIME Type identifier of text/plain, Windows will associate the file with the .Txt file association and the lower-level TxtFile subkey (as indicated by the Default value).

Heading down lower into the HRCR subtree will reveal more file association information. For instance, choosing the VBSFile file association (remember the .VBS file association's Default value said VBSFile), will display many key informational fields (see Figure 6-3). First, the Default value right under the VBSFile subkey describes the file type. In this example it is VBScript Script File. Although most administrators are familiar with the most common file extensions and their associated applications, there are dozens that are not well known. If you see URL: <protocol handler>, it tells you that the "file extension" is a URL moniker, not a file extension. For example, under the Telnet file association, the Default value has data indicating URL: telenet protocol. This means if telnet:// is typed into Internet Explorer or on the command line, it will launch the Telnet program. All the registered URL monikers are a potential attack point because malware can get third-party programs to launch in Internet Explorer. This method has been used in several attacks in the past.

image from book
Figure 6-3

Another value is the FriendlyTypeName. This lists the .Dll file that will initially handle VBS files in Internet Explorer (i.e., Wshext.dll). Wshext.dll will eventually hand off VBS files to the VBSScript.dll program. The EditFlags decimal value of 0 (or 0x00000000 in hexadecimal) indicates that a file download confirmation dialog box will be displayed if the file is downloaded by Internet Explorer or other Windows programs and does not automatically execute. For potentially dangerous files, as listed in Table 5-1 in Chapter 5, this is a smart option to enable. If left disabled, a malicious web site or e-mail could automatically execute malicious code on the user's system without the user ever having a chance to deny the execution. A binary value of 01 in the third octet of the EditFlags value disables the download confirmation dialog box. The DefaultIcon subkey lists the executable from which the icon graphic is pulled when an associated file is displayed. In the VBSFile example, the icon is pulled from Wscript.exe. Malware has been known to manipulate this value in order to make a potentially harmful file appear harmless (e.g., .EXE file associated with the .TXT file icon) to trick the end user into executing it without the appropriate cautions.

Some file types point to themselves as the source of the icon, and this is a common point at which malware type spoofing occurs. When an icon is pulled out of the parent file, the file can display any icon it likes. This is why icons are an unsafe substitute for file name extensions as a determinant of file type.

The Shell\Open\Command subkey (see Figure 6-3) shows the program the file extension is associated with when executed outside of Internet Explorer. In this example, VBSFile is executed with the Wscript.exe program. The Shell\Open2\Command subkey displays another program, CScript.exe, which can be used to run VBS files at the command prompt. The Shell\Edit\Command subkey displays the program the file is opened in if opened for editing (versus executing). The \Shell\Print\Command subkey tells Windows how to print the file if told to print it (often using Notepad and the /P print command). Other subkeys instructing behavior you might see include New, Printto, and OpenAsReadOnly.

The Shell\Open\Command subkey has been manipulated by many malware programs. Worms and trojans have changed the default program to something more malicious. For example, the normal .Txt handler can be changed from Notepad.exe to Wscript.exe, for a malicious script file. A dangerous VBScript or JSScript file could then be sent to the end user as a .TXT file and it would execute using WScript.exe and be able to cause much more damage than if it were a plaintext file.

Trojans and worms have also manipulated the Shell\Open\Command value so that they were executed along with the normal file handler. For example, many e-mail trojans have manipulated the .Exe file association so that the malware program was executed along with any run .Exe executable. They do this by changing the .Exe file Default value from its normal setting of "%1" %* to "malwareprogram.exe %1" %*, where malwareprogram.exe is the malicious program's name. The following file associations are particularly popular with malware programmers using this trick:

  • BAT

  • COM

  • EXE

  • HTA

  • PIF

But any file association is vulnerable. Other trojans have attacked .Chm,.Ini,.Reg,.Scr, and .Txt files.

The action named as the value of the key called shell is the default action that will happen if you double-click (or press Enter on) a file, and will be the action seen in bold if the file is right-clicked to access the context menu. But there are some shell contexts that will use whatever action is called "open" instead, whether this is set as the default action or not. This includes the "legacy" OpenWith programs list, and use of the Start command.

There are dozens of other possible registry fields related to the registry file associations, but these are the ones most interesting to malware authors and forensic investigators. Messing with file associations in the registry can be difficult and painstaking. Some forensic investigators prefer to use the Windows Explorer GUI to view and manipulate file associations, although GUI manipulation is very limited as compared to the registry interface.

File Associations in Windows Explorer

You can view the current file associations in Windows by choosing the Tools menu option from within Windows Explorer and then choosing Folder Options ê File Types (see Figure 6-4). There are hundreds of registered file associations you can view, modify, and delete. Any changes made here (you need admin permissions) are written to the HKLM\Software\Classes subkeys and will override settings in the HKCR subtree. Currently, there is no way to view or modify file associations for the HKCU\Software\ Classes subkey through the GUI — all changes must be made manually.

image from book
Figure 6-4

The Windows Explorer method only shows the direct file associations between file extensions and their related applications, but doesn't show handling modules or all OLE2 file types. By selecting a file extension and clicking the Change button in the File Types dialog box, you can view the associated application (see Figure 6-4) if you have admin rights. When clicking on a previously unregistered file association, Windows will prompt you to associate an application. If you are an administrator, you can select the Always use the selected program file to open this kind of file option (if the file has an extension) or let Windows use Web Services to search for the appropriate program (this almost never works).

If you select the Advanced button under the Folders Types dialog box, you get another set of features (see Figure 6-5). One, Confirm open after download, if selected will tell Windows and Internet Explorer to ask for the end user's permission before opening the selected file type in its associated program.

image from book
Figure 6-5

If the Always show extension option is enabled, it will force the file extension on the related file type to be displayed in Windows and related applications. By default, the related AlwaysShowExt registry setting is enabled on many existing file associations and all new and previously undefined file extensions (i.e., HKCR\* subkey). But as discussed before, many file associations have the NeverShowExt (i.e., Never show file extension) value enabled. Usually, if both the AlwaysShowExt and NeverShowExt values are present in the same file association subkey, the NeverShowExt wins.

Note 

The HKCR\* subkey represents the default settings for all file types, and all file types will inherit actions and settings defined by it. File types that are not otherwise defined will inherit actions defined by "Unknown." For example, adding an action called BONG! to * shows up on all file types.

It's important to note that any changes made in the Windows Explorer GUI usually affects the file association settings stored in HKLM\Software\Classes, not HKCU\Software\Classes, which is slightly different behavior than when directly modifying the registry.

HK_Current_User

This lists the current configuration and profile information for the currently logged on user. Virtually any setting that affects the user's desktop experience can be found here, including background graphics, screen saver choices, folders, printer and drive mappings, whether or not the user can see hidden files, and hundreds of other settings. If similar values exist in both HKCU and under HKLM, the data in HKCU takes precedence. The HKCU location is not nearly as popular with malware but could lead to many of the same exploits accomplished using HKLM.

Note 

Spyware uses HKCU more often than any other type of malware. The consequences are that any antispyware scanner must be coded to scan multiple user profiles in order to remove all spyware.

HK_Users

HKU contains all the user profiles on the local computer. When a user logs on for the first time, their profile is created using the configuration information stored in the \Documents and Settings\Default User folder and the HKU\.Default key. Thereafter, when the user logs onto the machine using the same profile, their HKU\<profile> information is copied to HKCU for the user's session. The HKU\<profile> is tracked by security principal SID. Any changes made to the user's profile (in HKCU) are saved back to HKU\<profile>. Although malware could take advantage of the profile keys located in HKU, so far to date, they have not messed with it much.

HK_Current Config

HKCC is an alias for HKLM\System\CurrentControlSet\Hardware Profiles\Current and data it contains can be changed in either location. Windows allows one or more hardware profiles to be created for a computer (under Control Panel ð System applet ð Profiles). If desired, varying hardware devices, drivers, and services can be turned on and off per profile. Profiles are most commonly used on laptops, going from docked to undocked states. It has not been frequently manipulated by malware.

Note 

All 64-bit versions of Windows store many HKLM\Software pre-64 bit registry keys (i.e., 32-bit) under a single location in the registry, HKLM\Software\WOW6432Node. 32-bit programs accessing HKLM\Software are seamlessly redirected to the new location.

Alternate Registry Storage Locations

Because the registry is so vital to Windows, backup copies are often created and stored. If these backup copies can be compromised by an intruder, they will significantly help the hacker with future attacks on the same computer. Registry file backups are made by Windows and many backup utilities. Although not current, backup copies of the registry files are made during the initial install and saved to %Windir%\Repair. These files can be used to replace a corrupted registry in an emergency recovery scenario. In Windows XP and Windows Vista, Restore Points will contain a copy of the registry files. System State backups made by the Backup Utility for Windows (formerly known as NT Backup) will contain a copy of the registry files, as will any backup job capable of backing up files in use.

Administrators can make individual backups of the registry using the Registry Editor's export feature or Reg.exe with the /Save parameter. Administrators should always make a backup of any affected registry key before they make modifications. One mistyped entry could cause Windows to have boot problems and STOP errors.

Registry Tools

The Microsoft registry editor tool comes in two forms: Regedit.exe and Regedt32.exe.Regedit.exe was the original tool delivered with Windows 3.x over a decade ago. Regedt32.exe was released with Windows NT. It contained new functionality, such as the capability to view and modify registry permissions and allows registry hives to be saved individually, but many users preferred Regedit.exe's search capabilities. Starting with Windows XP, Microsoft's main registry tool was renamed back to Regedit.exe. If you type Regedt32.exe, it just runs the main Regedit.exe tool.

With Regedit.exe, you can save and load registry keys and hives. You can also modify the local registry database or connect to a remote computer's registry (the Remote Registry service must be active on the remote computer and the user must have the appropriate credentials). If the user connecting to the remote registry has administrative access, they can manipulate all the registry keys. If they are logged in as a regular user, they are restricted to what the particular user could normally see. If the connecting user has no authenticated access (i.e., connected as the anonymous null session), the user can only see the keys marked to allow anonymous viewing. The keys allowed to be viewed by the anonymous user are defined in group policy (or local computer policy) at \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network access: Remotely accessible registry paths. By default, the values in Windows XP Pro are as follows:

  • System\CurrentControlSet\Control\ProductOptions

  • System\CurrentControlSet\Control\Print\Printers

  • System\CurrentControlSet\Control\Server Applications

  • System\CurrentControlSet\Services\Eventlog

  • Software\Microsoft\OLAP Server

  • Software\Microsoft\Windows NT\CurrentVersion

  • System\CurrentControlSet\Control\ContentIndex

  • System\CurrentControlSet\Control\Terminal Server

  • System\CurrentControlSet\Control\Terminal Server\UserConfig

  • System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration

You can add and delete keys from this list according to need, although no glaring holes are incurred by leaving it at the defaults.

Regedit Files and Scripting

Using Regedit.exe, you can view and modify registry permissions (see below), and search and find wanted registry keys and values. You can also manage the registry using Regedit files. Regedit files are text files, usually with .Reg file extensions, created to instruct Reg.exe in creating or modifying registry values. Regedit files have their own syntax, usually beginning with a command word determining which registry subtree to manipulate, followed by the registry entry to make.

For example, the following commands in a Regedit file would instruct Windows to open VBScript files in Notepad.exe instead of Wscript.exe. This can be done to prevent VBS viruses and worms (and legitimate VBScript script files) from activating properly.

    REGEDIT4 HKEY_CLASSES_ROOT\VBSFile\shell\open\command] @=" notepad.exe \"%%1\"" 

Regedit files were a primary tool to programmatically manipulate the registry, but their use requires that the end user running the Regedit file be an administrator. You can find out more information about Regedit files at www.robvanderwoude.com/index.html or www.regedit.com.

Registry values can also be managed using Reg.exe, Group Policy, and scripts. Reg.exe is a default executable that allows registry hives and keys to be added, modified, or deleted manually. In Windows NT it was included in the Windows NT Resource Kit, but starting in Windows 2000 it was included in part of the default install. A good example web site demonstrating the Reg.exe command-line syntax can be found at www.robvanderwoude.com/index.html. Registry entries can also be manipulated via group policy, without the end user needing administrative access. Registry manipulation via group policy and local computer policy is discussed in detail in Chapter 14.

You can use any of several scripting languages, including VBScript, JSScript, and WMI, to manipulate registry entries. The following sample script demonstrates setting Notepad.exe as the default handler instead of using Wscript.exe for encoded VBScript files (.VBE extension):

 Set WshShell = WScript.CreateObject("WScript.Shell") WshShell.RegWrite "HKLM\Software\Classes\VBEFile\Shell\Open\Command\", "C:\Windows\System32\Notepad.exe %1%", "REG_EXPAND_SZ" 

For more information on using script files to manipulate registry keys and values see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsMthRegWrite.asp, www.winguides.com/scripting/library.php?id=6, or www.windowsitlibrary.com/Content/314/2.html#5.

Note 

You can also use Microsoft's universal Logparser utility (http://www.microsoft.com/downloads/details.aspx?FamilyID=&displaylang=en) to view and record registry information. See http://www.logparser.com for more details.

Regmon

Sysinternals' free Regmon tool (www.sysinternals.com/Utilities/Regmon.html) is one of the most widely used registry troubleshooting utilities in the world. It comes in Windows 9x, NT, and 64-bit versions. When running, it displays and logs all registry requests. It can record all reads and writes, and their success or failure, to the registry and detail which process was involved. It is great for determining what access a particular program or user needs to which registry keys. Figure 6-6 shows Regmon in action. What surprises most people initially when querying for all registry requests is how frequently Windows is manipulating the registry even when nothing appears to be actively happening on the desktop. The example in Figure 6-6 collected thousands of registry reads and writes in just a few seconds. Most Regmon users end up filtering what registry events are collected in order to cut down on the "noise." Sysinternals' Filemon (www.sysinternals.com/Utilities/Filemon.html) utility is just as fantastic for troubleshooting file accesses.

image from book
Figure 6-6

Note 

Another very useful tool is NifSoft's freeware Registry Scanner (www.nirsoft.net/utils/regscanner.html). It will return multiple keys back at once when searching for particular keys or data, so you can edit them all at once more quickly. It can also query registry entries based on last modification time and date.

In August 2005, it was found that overly large registry entries (those exceeding 256 characters in length) would not be read correctly by the default Microsoft Windows registry editor (i.e., Regedt32.exe). This could allow malware to make an overly large entry and escape easy scrutiny using Microsoft's tool. Many other third-party registry tools also suffered from the same problem, but most were fixed within a week or two of the announcement. Make sure your registry editor can see long registry entries.

Registry Permissions

Like files, the registry keys also have an extensive list of permissions, although they differ from their file and folder counterparts. To access registry key permissions, you can use Regedit.exe (or Regedt32.exe in Windows 2000 or NT) or the command-line Subinacls.exe tool. To view registry permissions in Regedit.exe, choose a registry key or value, then click on the Edit menu and choose Permissions. Like the NTFS permissions in Windows Explorer for a file or folder, the initial display shows only the higher-level permissions of Full Control, Read, and Special Permissions. Choose the Advanced button and then the Edit button on the Permissions tab to see the underlying 11 granular permissions (see Figure 6-7).

image from book
Figure 6-7

The 11 registry key permissions are as follows:

  • Full Control — Allows full access to the registry key, including the ability to set permissions

  • Query Value — Allows the value of the registry key to be read

  • Set Value — Allows the value of the registry key to be written

  • Create Subkey — Allows the creation of subkeys

  • Enumerate Subkeys — Allows subkeys to be enumerated (found or listed)

  • Notify — Required to request change notifications for a registry key or its subkeys

  • Create Link — Used only by the operating system

  • Delete — Allows a key to be deleted

  • Write DACL — Allows key security permissions to be modified

  • Write Owner — Allows the owner to be changed

  • Read Control — Allows the auditing permission to be read

The Full Control permission contains all registry permissions. The Read permission is normally made up of special permissions Query Value, Enumerate subkeys, Notify, and Read Control. As with file and folder permissions, the Effective Permissions tab under the Advanced button will show you a security principal's effective permissions on a registry key. Normal inheritance rules apply: Permissions are inherited downward by default unless offset by a more granular permission.

You can also use Microsoft's Subinacls.exe (www.microsoft.com/downloads/details.aspx?FamilyID=&DisplayLang=en) tool to display or modify registry permissions. It is useful in a script or when accessing Windows through a command shell window.

Default Registry Permissions

Windows XP and Server 2003 registry permissions are relatively secure by default. If the end user is not logged in as an administrator, then what they, or a program running in their security context, can manipulate is mostly in their own HKCU subtree. On most other subtrees, keys, and subkeys, non-admin users can only read the value. Table 6-3 shows the overall default registry permissions in Windows XP Pro.

Table 6-3

Registry Subtree

Default Permissions

HKCR

Administrators, Creator Owners, and System have Full Control, Users have Read access, and Power Users have Special access.

HKCU

System, Administrators, and the currently logged on user have Full Control. This is a subtree that malware could easily manipulate even when the end user is not logged in as an administrator.

HKLM

System and administrators have Full Control. Everyone group has Read access.

HKLM\Software

Administrators, Creator Owners, and System have Full Control. Users have Read access. Power Users and Terminal Service User group have Special permissions.

HKU

System and Administrators have Full Control and the Everyone group has Read access.

HKCC

Users and Power users have Read access. Administrators, System, and Creator Owners have Full Control.

On the subkeys below the main keys there are small deviations in the permissions, but for the majority of the registry keys and values, these parent permissions hold true through inheritance.



Professional Windows Desktop and Server Hardening
Professional Windows Desktop and Server Hardening (Programmer to Programmer)
ISBN: 0764599909
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net