Wireless SSIDs
On live systems (most often laptops), Windows will maintain a list of service set identifiers (SSIDs) to which it has connected. If the wireless connections are managed by the Wireless Zero Configuration Service (WZCSVC), this list is maintained in the following Registry key:
![tmpDE-31_thumb[2]_thumb](http://what-when-how.com/wp-content/uploads/2011/09/tmpDE31_thumb2_thumb.jpg "tmpDE-31_thumb[2]_thumb"){kind=small}
The GUID in this case is the globally unique identifier (GUID) for the wireless interface. Beneath this key, you might see the value ActiveSettings and then several other values called Static#000x, where x is an integer, starting at 0. These values are all binary, and the SSIDs for any wireless access points that have been accessed will be included within the binary data. Within the binary data, at offset 0×10, is a DWORD value that contains the length of the SSID. The SSID name immediately follows this DWORD value for the number of bytes/characters listed. Figure 4.8 illustrates the binary contents of the ActiveSettings value, taken from a live system. Note that the SSID has been highlighted.
Figure 4.8 ActiveSettings Value from a Live System, Showing the SSID
Now and again, a question appears on a public listserv regarding determining SSIDs to which the system has been connected. This can be useful in situations where unauthorized access is an issue or in a case where it’s important to trace the IP address that the individual was using. As such, the ssid.pl plugin will extract the data from the Software hive, including both the SSID of the wireless access point connected to, as well as the date of the last connection to that SSID, as illustrated here:
From this information, we can see that the system (in this case, a laptop) last connected to a wireless access point with the "tmobile" SSID (usually offered through Starbucks, among other locations) in October 2007, and to the "ender" SSID in the same month. This information can be extremely valuable in establishing a timeline of activity on the system, particularly when correlated with other data. However, keep in mind that the time-based information from this plugin (and the others, as well) is presented in Universal Coordinated Time, or UTC format, and may need to be corrected for the appropriate time zone.
Autostart Locations
Autostart locations within the Registry are locations that allow applications to be launched without any interaction from the user and very often unbeknownst to the user as he does. something on the system. These locations were originally provided for the user’s convenience. Some applications, such as touch pad drivers and applications on laptops, as well as antivirus and firewall applications, are most useful when they’re started automatically. In other cases, users like to have applications such as instant messaging (IM) clients started automatically when they log in to their systems, as a matter of convenience.
In 2004, members of the Microsoft Research Center’s CyberSecurity and Systems Management Research group presented a paper, "Gatekeeper: Monitoring Auto-Start Extensibility Points for System Management," at a USENIX conference. In that paper, the authors refer to the autostart locations as auto-start extensibility points, or ASEPs. The paper categorizes the ASEPs in a different manner than I have and provides a graph showing that perhaps the most popular ASEP used by spyware (at the time the data was compiled) was to install as a browser helper object (BHO). A BHO is essentially a dynamic link library (DLL) that Internet Explorer loads automatically when it starts, and from there it can monitor the user’s activities. See the "BHOs" case study for an example of how you can use this autostart/ASEP.
Are You Owned?
Case Study: BHOs
I was the security admin at a financial services firm when I ran into an interesting use of BHOs. My employer provided credit monitoring and identity theft protection services to its customers, allowing for a variety of levels of monitoring of their credit, from quarterly reports to nearly-instant pages and/or e-mails whenever a query appeared. And like most businesses, my employer had competition. At one point, I got a call from folks on the business development side of the house with a potential security issue. Several users had gone to the company Web site, and when they loaded the main Web page each instance of our company’s name was highlighted, and clicking it took the user to a competitor’s Web site!
It turned out that a BHO had been installed on the user’s system (it was happening to several people and our business development staff had figured out how to get "infected" as well) and would monitor the user’s browsing activity. Various companies would subscribe to this adware/BHO provider, and whenever their competitor’s names appeared in a Web page, the BHO would automatically turn the name into a hyperlink to their subscriber’s Web site. So, let’s say Consumer Electronics Company A signed up with the adware provider. When the adware had infected a user’s system, every time a Web page was loaded that had the names of A’s competitors, those names would be made into hyperlinks to A’s Web site.
Fortunately, Microsoft is kind enough to provide Knowledge Base article 298931 (http://support.microsoft.com/kb/298931) to tell users how to disable BHOs. The Knowledge Base article provides links to more detailed information regarding BHOs, which are listed beneath the Registry key HKLM\SOFTWARE\Microsoft\Windows\ CurrentVersion\Explorer\Browser Helper Objects. RegRipper’s bho.pl plugin extracts and displays this information for you.
Note that this key is in the HKEY_LOCAL_MACHINE hive, which means that browser loads the BHOs whenever it is opened, regardless of the user.
The bho.pl Perl script located on the accompanying media (in the ch4\code\old directory) allows you to view the BHOs that have been installed on a live system.
One school of thought seems to be that most users and administrators aren’t all that familiar with autostart locations within the Registry and believe that only a very few keys (in particular, the ubiquitous Run and RunOnce keys) can be used for such purposes. This manner of thinking is supported, in part, by documentation and applications provided by the operating system vendor. For example, on a live Windows XP system, a command called MSConfig launches the System Configuration utility (http://support.microsoft.com/kb/310560). You can run this command by clicking the Start button on the Task Bar, choosing Run, and typing msconfig into the text box, then pressing Enter. Figure 4.9 illustrates the System Configuration utility opened to show the contents of the Startup tab.
Figure 4.9 System Configuration Utility Startup Tab
Run this command on your XP system and take a closer look at the Location column. You’ll see that the Registry keys examined are the Run key from both the HKEY_CURRENT_ USER and HKEY_LOCAL_MACHINE hives. Unfortunately, these seem to be the only keys examined. There is a WMI class named Win32_StartupCommand that will allow a programmer to automatically retrieve the contents of these keys, but as with the System Configuration utility, it checks only a very limited number of startup locations within the Registry.
Another school of thought is that the sheer number of autostart locations within the Registry is so large that examining these locations is best left to professionals and/or software created by professionals, such as commercial antivirus and antispyware utilities.
The truth is somewhere in between. Yes, there are a number of autostart locations within the Registry, but for the most part, they are finite and limited. In the following sections, I’ll break down these locations into three areas and describe some of the Registry keys that are accessed when the system boots, those accessed when a user logs in, and those accessed when a user performs some activity on the system. Then we’ll look at ways to enumerate the entries in these locations. However, the listed keys should not be considered all-inclusive or representative of a complete and comprehensive list of all keys. The media that accompanies this topic includes a spreadsheet named regref.xls that contains several worksheets. Each worksheet includes various Registry keys that fall into that worksheet’s category, as well as a brief description of the key and, where applicable, a credible reference that describes the functionality of that key. This spreadsheet should be considered a starting point for Registry analysis, but because there are a great many applications out there and new versions being produced all the time, it should not be considered complete.
System Boot
Autostart locations within the Registry that are accessed when the system boots are favorites of malware authors because they allow the malware to be launched with no user interaction whatsoever—not even logging in to the system. One location is the Windows Services, or more specifically:
When the system starts, the value for the current ControlSet to be used is determined, and the settings for that ControlSet are used. The services listed within that ControlSet are scanned, and services that are set to start automatically (Start value is 0×02) are launched.
When performing an intrusion analysis, often all you have to go on is an acquired image of a system and an incident report (and often the incident report isn’t much more than "we saw this occur on this date"). When you’re faced with something such as this, an easy way to get started is to open the image in ProDiscover, populate the Registry Viewer, locate the ControlSet marked Current, and then sort the subkeys beneath the Services key based on their LastWrite times. Many of these LastWrite times will generally line up in accordance with the last time the system was booted, as many of the Services keys are modified, rather than simply read, during the boot process. However, in several cases I’ve used this technique to locate services and drivers installed by the attacker, including rootkits and a driver called rdriv.sys (which is a rootkit driver file used by some Trojans and Internet Relay Chat, or IRC, bots). In some cases I’ve located these services, and neither the names of the services nor the LastWrite times correlated to the incident report I had received. Essentially, I’d found an intrusion separate from the one I was investigating!
You can find other interesting artifacts using this same technique. For example, I’ve located npf.sys, the driver installed with the WinPcap utilities that allow you to perform packet sniffing on your system. This driver is installed by tools such as Wireshark and the sniffer tools available with the WinPcap utilities—but they might also be installed by an attacker.
RegRipper can use two plugins, svc.pl and svc2.pl, to parse the information available in the Services key. In both cases, the information is extracted and sorted based on each subkey’s LastWrite time. The svc.pl plugin presents a short, quick view of the information, whereas svc2.pl presents more detailed information (including the service or drive display name, path, service/driver type, etc.) in a comma-separated value (.csv) format. When run with rip.pl, the svc2.pl plugin output can be redirected to a file and opened in Excel for quick analysis.
In some cases, an incident responder may need to access Services key information on live systems. For instance, there is malware that uses Windows Services as its persistence mechanism, and installs as a DLL that is run under the svchost.exe process (Microsoft Knowledge Base article 314056, http://support.microsoft.com/kb/314056, provides a description of the svchost.exe process on Windows XP Professional). As malware that uses this persistence mechanism is not easily visible (e.g., the Conficker worm writes a random entry, making it even harder to find), I wrote a CLI tool to run on live systems, called regscan. pl (this tool is stand-alone and is not part of RegRipper; it is available on the media that accompanies this topic in the ch4\code\Regscan directory) which parses through the Services key and lists basic information about each service, including the LastWrite time of the key, the ImagePath value (if available), and the Parameters\ServiceDll value (if available). This information is pipe-delimited and sent to STDOUT, for ease of use. A responder can run regscan.pl (or the "compiled" executable) on a local system, or provide an IP address or system name to which she has Administrator access and extract the same data. Locating malware installed using this method is as simple as typing the following command:
This command extracts all of the Services information from the local system, but performs data reduction by piping the output through the find command to display only the entries that are launched via the svchost.exe process. An excerpt of the output appears as follows:
The pipes ("|") between each segment of the output make it easy to parse and analyze, and allow the output for each key to be on one line so that other tools such as the find command can be used to reduce the amount of visible data that a responder needs to deal with. The data is listed by each service’s LastWrite time, so if the responder has an approximate date or time window for the incident, she can narrow down the data even further.
User Login
According to Microsoft documentation, the startup process for a system is not considered complete until a user logs in. When a user logs in to a system, certain Registry keys are accessed and parsed so that listed applications can be run. Those keys are (in order):
1. HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
2. HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
3. HKLM\Software\Microsoft\Windows\CurrentVersion\Run
4. HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
5. HKCU\Software\Microsoft\Windows\CurrentVersion\Run
6. HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
For the sake of brevity, HKLM refers to the HKEY_LOCAL_MACHINE hive, and HKCU refers to the HKEY_CURRENT_USER hive.
Each time a new user logs in to the system, keys 1, 3, 5, and 6 are parsed, and the programs listed are run (http://support.microsoft.com/kb/137367). By default, these Run keys are ignored if the system is started in Safe Mode. However, on Windows XP and 2003 systems, if you preface the RunOnce values (keys 1 and 6) with an asterisk (*), you can force the associated program to be run even if the system is started in Safe Mode (http://support. microsoft.com/kb/314866). Further, on Windows XP, keys 1, 3, 5, and 6 are provided for legacy programs and backward compatibility so that programs written for earlier versions of Windows (or prior to Windows XP being released) can still be used.
User Activity
Autostart Registry locations that fall under this category are those that are accessed when the user performs an action, such as opening an application like Internet Explorer or Outlook. If you run RegMon on a system and just move the mouse or open an application (or do nothing whatsoever), you’ll see that there are quite a number of accesses to the Registry, even when there is apparently nothing going on with regard to the user interacting with the system. As with other autostart locations, malware (virus, Trojan, worm, etc.) authors find these Registry keys extremely useful in maintaining the persistence of their products, ensuring that they’re up and running. One such notable location is:
This Registry key as well as the keys for other classes of files (batfile, comfile, etc.) control what happens when that class of file is opened. For example, in Windows Explorer, right-click any file and a context menu will appear with the word Open at the top of the menu, in bold. The boldfaced action is, in most cases, what happens when that file is double-clicked.
When you double-click a file, Windows will scan the Registry for that file class and then determine what actions to take, based on the Registry settings for the file class. Malware such as the SirCam (http://support.microsoft.com/kb/311446) and Pretty Park (http:// support.microsoft.com/kb/310585) worms have used this Registry location to maintain persistence on an infected system.
For example, let’s say you want to play Solitaire on your system. You go to the command prompt and type the command:
The output of this command tells you where the executable for Solitaire is located within the file system. (On my Windows XP Home system, sol.exe is located in the C:\Windows\system32 directory.) Just out of curiosity, you wonder what happens when you double-click the file icon for Solitaire, so you type the following command:
The output of the command shows you exefile="%1" %*.This basically tells the system to launch the file with the first argument (the filename) and any successive arguments. However, additions can be made to the shell\open\command Registry entry so that other files are launched whenever a particular class of file is opened. Entries in this key (and others similar to it, as described in a moment) should contain simply ‘%o1′ %* and nothing else, by default. Any other data in this value should be considered suspicious and investigated immediately.
Another entry to check for similar information is:
This functionality does not apply to just the Exefile entry beneath HKEY_CLASSES_ ROOT. Some malware will modify other entries of the same type to ensure its persistence on the system. For example, some backdoors modify entries to the following key:
In this case, x is the version number (8, 9, etc.) for Word. This tells the system that whenever the Open command for Microsoft Word documents is run through the shell (Windows Explorer), such as when the user double-clicks a document, the malware will be executed. Another location that can be used in a similar fashion is the following key:
You can find an excellent reference for the AutoRun key at http://technet.microsoft.com/en-us/library/bb490880.aspx.
This Registry value lists commands that are run whenever the command processor (cmd.exe) is run. For example, it will run an application whenever a command prompt is opened. The value is empty by default. Entries can also be made in the same value within the HKEY_CURRENT_USER hive, and if there is an entry there, it takes precedence over the entry in the HKEY_LOCAL_MACHINE hive.
To illustrate how simple this is, open RegEdit and navigate to the Command Processor key. On my Windows XP Pro SP2 system, that value is visible, but there is no data associated with it. Right-click the value and choose Modify, and then press Enter. Figure 4.10 illustrates an example of data that can be added to the Registry value.
Figure 4.10 Adding Data to the Command Processor\AutoRun Value
Once you’ve changed the value, click OK. Then click Start | Run, type cmd, and press Enter. The command prompt will open, as will the application that you chose. In Figure 4.10, I chose an application with a nice GUI interface so that when I ran the command prompt, it would be obvious that something else was opened as well. A number of other actions can be performed, such as silently installing a user or service or starting a Trojan backdoor that doesn’t have a GUI.
Speaking of GUIs, there’s a little-known Registry key that can be used to load a DLL into memory whenever a GUI application is started. This key is:
Microsoft Knowledge Base article 197571 (http://support.microsoft.com/kb/197571) indicates that the DLLs listed in this value are loaded into memory using the LoadLibrary() function during the DLL_PROCESS_ATTACH process of user32.dll; this is where instructions for various GUI elements, such as windows and dialog boxes, are stored.
In 2000, J. D. Glaser (formerly with Foundstone, now running NT OBJECTives) gave presentations at BlackHat and USENIX conferences regarding tracking down the compromise of a server and finding an entry in the AppInit_DLLs key.
The AppInit_DLLs key is extremely effective as a hiding place for malware. The CoolWebSearch spyware is known to use this key, for example. Why is this key so effective? When I have taught hands-on incident response training, one of the first exercises I would run is a simple "infection" exercise that is meant to look at the attendees’ process rather than determine who can find the "infection" first. I’ve taught the course to new and experienced Windows administrators as well as experienced UNIX and Linux admins who also have responsibilities for Windows systems. Invariably, across the board, 100 percent of the time, the first step that every attendee takes is to open a GUI tool on the desktop. It could be the Event Viewer; it could be the Task Manager; or even Windows Explorer. However, their first instinct is to always reach for a GUI application.
Windows operating systems provide the ability to alert external functions when certain events occur on the system, such as when a user logs on or off or when the screensaver starts. These notifications are handled by the following Registry key:
Entries beneath this key point to DLLs that receive notifications of certain events. Googling for WinlogonNotfy will give you a long list of links to malware that uses this key’s functionality. When you’re performing forensic analysis of a system, it would be a good idea to sort the subkeys beneath Notify based on their LastWrite times and pay particular attention to any entries that are near the date of the suspected incident, as well as any entries that list DLLs in the DLLName value that have suspicious file version information or no file version information at all.
Beneath the WinLogon key (listed previously) is a value named TaskMan that might be of interest to investigators because it allows the user to choose an application to replace the Task Manager. This value doesn’t exist by default but can be added. In fact, installing Process Explorer from Sysinternals allows you to choose Process Explorer to replace the usual Task Manager. If the TaskMan value exists beneath the WinLogon key, you should consider this "suspicious" under most normal circumstances and thoroughly investigate the application listed in the data.
There is an interesting Registry key that allows a user (usually an application developer or someone debugging applications) to specify a debugger to be launched when an application is run. The Registry key is:
Microsoft provides several Knowledge Base articles that discuss using this key to debug Common Gateway Interface (CGI) applications (http://support.microsoft.com/kb/238788) as well as to turn off the Windows Update feature under Windows XP (http://support.microsoft.com/kb/892894). Creating a subkey for the application you want to block, for example, and adding the Debugger value with the ntsd — (ntsd followed by a space and two dashes) data will cause the debugger to attach to the process and then exit immediately. However, Dana Epp identified (http://silverstr.ufies.org/blog/archives/000809.html) a method of using this key as an "attack vector," or perhaps more appropriately, as a method of persistence for malware. To see this in action, first add a subkey to the Image File Execution Options key that is the name of the executable you want to circumvent (e.g., notepad.exe). You don’t need to provide a path, just the name of the executable. Then add to the key a string value called Debugger and point it to the command prompt, as Figure 4.11 illustrates.
Figure 4.11 Adding the Debugger Value to the Image File Execution Options Key
Click OK and then choose Start | Run and type notepad. You’ll see the command prompt open instead of Notepad. No reboot is required for the change to take effect.
At this point, I could highlight some interesting ways to take advantage of this sort of thing, such as pointing the Debugger value to a Trojan’ed copy of notepad.exe that not only opens Notepad but also launches a backdoor or an IRCbot or a worm of some kind. However, enough examples of malware are currently available that establish a foothold in this Registry key to make it clear that this is definitely a key worth examining. In fact, I’ve actually seen this method of persistence used by malware during a number of examinations, including intrusion cases. Simply navigate through all the subkeys and examine the executable pointed to by the Debugger value (if there is one; not all subkeys will have a Debugger value), or use the imagefile.pl plugin to run this search within a Software hive file automatically.
