Previously I looked at various important items in the registry that investigators could analyze to determine recent...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
actions of the user currently logged onto the machine. We focused specifically on the portion of the registry referred to as "HKCU," which stands for "Hive Key Current User." This month, we'll analyze various system-wide settings specified in the HKLM (Hive Key Local Machine) section of the registry, which are also very useful for forensics investigators.
Included in several versions of Microsoft Windows -- XP Professional, Vista, Server 2003 and Server 2008 -- is the reg.exe command, which allows a query or update of information in the registry. This great command-line tool can be used locally or against remote systems to dump whole sections of the registry recursively.
Auto-start registry keys
Investigators can benefit by pulling data from three important registry keys that control some of the auto-start behavior of Windows boxes: the "Run" registry keys. When a user logs on locally to a system, programs identified in the settings of these registry keys are automatically executed:
Many malware specimens (as well as a lot of legitimate programs) run every time the system starts up by adding an entry to these registry locations. Query these locations using the reg command as follows:
C:\> reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
C:\> reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
C:\> reg query HKLM\Software\Microsoft\Windows\CurrentVersion\RunonceEx
Because a typical Windows machine may have a half dozen or more legitimate entries here, a forensics investigator will need to separate the good from the malicious by diligently researching each discovered item. This can be done via Web searches and/or by grabbing a copy of unusual autostart programs for further analysis.
When querying these or other items from HKLM (or HKU, where user account and related information is stored), use the reg command against a remote Windows machine across the network with Windows Server Message Block (SMB) connections. Unfortunately, the reg tool works remotely only for items in HKLM and HKU. It can't pull data from other hives in the registry, including the HKCU items we looked at last month. This forces forensics investigators to pull HKCU data by running commands locally on the target machine.
To query HKLM and HKU remotely with the reg command, the Remote Registry service must be started on the target machine, which is activated by default on many versions of Windows (other than Vista). Start by setting up an SMB session with the target using administrator credentials:
C:\> net use \\[TargetIPaddr] /u:[AdminName]
Enter the password for that admin user when prompted, then, with that session open, use the reg command to query items in HKLM as follows:
C:\> reg query \\[TargetIPaddr]\HKLM\Software\Microsoft\Windows\CurrentVersion\Run
USB drive & iPod history
Beyond these autostart keys, the registry also remembers information about every USB token ever plugged into the system. I've worked on a number of cases in which I needed this information. To query for all tokens that have ever been plugged into the Windows machine, run this command:
C:\> reg query HKLM\System\currentcontrolset\enum\usbstor /s
Note that we've included "/s" at the end of this reg command, which tells the machine to pull information recursively from all items in the registry below the branch specified. This command could generate a lot of data, so the investigator might want to pipe it through the more command (| more) or even save the results to a file (> results.txt) for inspection later. The command's output will include a summary of each device's manufacturer and version number, indicated after "Disk&Ven" in the output. Right after that Disk&Ven item is a unique integer ID number assigned to each USB device, which can help investigators determine if the USB device in question has ever been connected to that machine. By plugging the USB token into another Windows machine and querying the same information, it's possible to compare the output of the command on the two boxes to see if the same USB token was installed in both of them.
Alternatively, suppose an investigator wants to look for specifics about an iPod device that may or may not have been connected to a machine. He or she can run the same reg command, this time piping its output through the find command to look for the string "ipod," as follows:
C:\> reg query HKLM\System\currentcontrolset\enum\usbstor /s | find /i "ipod"
Note that we've used the find command with the /i option to make it case insensitive.
Identifying network interfaces
To pull the IP address and related configuration information for all network interfaces on the device, run this command:
C:\> reg query hklm\system\currentcontrolset\services\tcpip\parameters\interfaces /s
Some immensely useful output of this command -- beyond the IP address, netmask, default gateway and DNS server -- is the "LeaseObtainedTime" parameter, a hexadecimal number. This value indicates when the local machine received its DHCP information, which often occurs when the system first boots up or joins a network. With this data, an investigator has an idea of when a given machine first engaged in network activity, information that is useful in building timelines for cases.
The hexadecimal number of LeaseObtainedTime represents the seconds that have transpired since 12:00 a.m. on Jan. 1, 1970, the beginning of the Unix Epoch. For example, my current "LeaseObtainedTime" is 0x4856d93a. I convert the lower-case d and a to capitals, then look up that time (4856D93A) with the free calculator at http://dan.drydog.com/unixdatetime.html that converts the seconds in hex to actual dates. In this example, my computer obtained its lease on June 16, 2008, at 9:20:58 a.m. That date is relative to the current clock on the computer whose registry we've queried, so it's also useful for investigators to pull the current time and date, which they can do using:
C:\> time /t & date /t
Because the output time is in HH:MM form, to make further sense of it, investigators will need to know the time zone of the machine, which they can pull with the command:
C:\> reg query hklm\system\currentcontrolset\control\timezoneinformation
Windows firewall commands
Another helpful query is the configuration of the built-in Windows personal firewall, which can be accessed by running the following command:
C:\> reg query hklm\system\controlset001\services\sharedaccess\parameters\firewallpolicy /s
This output shows the ports the firewall allows through the programs it lets communicate on the network, plus a myriad of other configuration settings. Thus, investigators may be able to determine whether a computer attacker disabled the firewall or reconfigured it to allow access for nefarious activities. For similar information in a better-parsed fashion, an investigator could alternatively run:
C:\> netsh firewall show config
While we've looked at some of the most useful items I've relied on in past investigations, the registry is chock full of additional helpful items. I encourage readers to continue their journey through the Windows registry, looking for additional useful queries, relying on a healthy combination of the powerful reg command, the public documentation available from sources such as Microsoft (though sometimes scanty), and hunches and insights.
About the author:
Ed Skoudis is a SANS instructor and a founder and senior security consultant with Intelguardians, a Washington, DC-based information security consulting firm. His expertise includes hacker attacks and defenses, the information security industry and computer privacy issues. In addition to Counter Hack Reloaded, Ed is also the author of Malware: Fighting Malicious Code. He was also awarded 2004-2007Microsoft MVP awards for Windows Server Security, and is an alumnus of the Honeynet Project. As an expert on SearchSecurity.com, Ed answers your questions related to information security threats.