Live Response: Collecting Volatile Data (Windows Forensic Analysis) Part 4

Clipboard Contents

The Clipboard is simply an area of memory where data can be stored for later use. Most Windows applications provide this functionality through the Edit option on the menu bar. Clicking Edit reveals a drop-down menu with choices such as Cut, Copy, and Paste. Microsoft Word 2003 includes an Office Clipboard option.

The Clipboard is most often used to facilitate moving data in some fashion—between documents or between application windows on the desktop. The user selects text or other data, chooses Copy, and then chooses Paste to insert that data somewhere else. The Cut functionality removes the data from the document the user is working on, and that data goes into the Clipboard.

What many folks don’t realize is that they could turn their computer on some Monday morning, work on a file, and copy some information to their Clipboard. Let’s say they’re editing a document containing sensitive information, and personal information about a customer needs to be added to that document. The user locates, highlights, and copies the information to the Clipboard, then pastes it into the document. As long as the computer is left on, the user doesn’t log out, and nothing is added to the Clipboard to replace what was put there, the data remains on the Clipboard.

Try it sometime. Walk up to your computer, open a Notepad or Word document, and simply use the Control + V key combination to paste whatever is currently in the Clipboard into a document. Try this on other computers. You might be surprised by what you see. How often do you find URLs, bits of IM conversations, passwords, or entire sections of text from documents still available on the Clipboard? The Clipboard isn’t visible on the system, but it’s there, and it has been an issue—so much so that there’s a Microsoft Knowledge Base article titled "How to Prevent Web Sites from Obtaining Access to the Contents ofYour Windows Clipboard" (http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q224993&) that applies to Internet Explorer versions 4 through 6.

Data found in the Clipboard can be useful in a variety of cases, such as information or intellectual property theft, fraud, or harassment. Sometimes such information can provide you with clues; at other times you might find images or entire sections of documents on the Clipboard.

Pclip.exe (available from http://unxutils.sourceforge.net) is a CLI utility that can be used to retrieve the contents of the Clipboard. CLI utilities such as pclip.exe make it easy to automate information collection through batch files and scripts.

Tools & Traps…

Clipboard Contents

Perl provides a simple interface to an API for accessing the contents of the Clipboard. The following script prints the contents of the Clipboard as a string:

To make more extensive use of Win32::Clipboard, consult the documentation for the module.

Service/Driver Information

Services and drivers are started automatically when the system starts, based on entries in the Registry. Most users don’t even see these services running as processes on the system because there are really no obvious indications, as there are with processes (e.g., you can see processes running in the Task Manager). Yet these services are running nonetheless. Not all services are necessarily installed by the user or even by the system administrator. Some malware installs itself as a service or even as a system driver.

Tools & Traps…

Service Information

The Perl script svc.pl, located in the \ch2\code directory on the accompanying media, uses WMI (accessing the Win32_Service class) to retrieve information about services from either a local or a remote system. The file svc.exe is a stand-alone Windows executable generated by compiling the Perl script with Perl2Exe.

Both the Perl script and the executable will display the following information about services:

■ Name of the service

■ DisplayName for the service

■ StartName (the context used to launch the service)

■ Description string for the service

■ PID for the service (this can be used to map the service to the process information)

■ Path to the executable image for the service

■ Start mode for the service

■ Current state of the service

■ Service status

■ The type of the service (kernel driver, share process, etc.)

■ Tag ID, a unique value used to order service startup within a load order group

Figure 1.11 illustrates an example of the information displayed by this utility. Both the Perl script and the executable can be modified to output this information in various formats, including CSVs to make parsing the information easier or to ease analysis by making the output suitable for opening in a spreadsheet.

Figure 1.11 Excerpt from the Output of svc.exe on Windows XP

Command History

Let’s say you approach a system during an investigation and see one or more command prompts open on the screen. Depending on the situation, valuable clues could be hidden in the commands typed by the user, such as ftp or ping. To see these previously typed commands, you can run the scroll bar for the command prompt up (if multiple commands are issued via the command prompt, the display will extend above the visible portion of the command prompt window), but that goes only so far. If the user typed the cls command to clear the screen, you won’t be able to use the scroll bar to see any of the commands that had been entered. Instead, you need to use the doskey /history command, which will show the history of the commands typed into that prompt, as illustrated in the following:

I’ll give you an example of when I’ve used this command. I was teaching an incident-response course on the West Coast, and during a lunch break I "compromised" the students’ systems. One step I specifically took on several of the computers was to open a command prompt and type several commands, then type cls to clear the screen. When the students returned, I noticed one particular individual in the back of the room who immediately closed (not minimized, but closed) the command prompt that he found open on his screen. As intended, the "clues" I left behind in the command prompt provided context to the rest of the "compromise," as students who hadn’t closed their command prompts discovered. However, I’ll admit that I’ve never had the opportunity to use this command outside a training environment. In all instances when I’ve been confronted with a live system, the user hasn’t used a command prompt. However, this doesn’t mean it won’t happen to you.

Mapped Drives

During the course of an investigation, you might want to know what drives or shares the system you are examining has mapped to. These mappings could have been created by the user, and they might be an indication of malicious intent (this could be the case if the user has guessed an Administrator password and is accessing systems across the enterprise). Further, there might be no persistent information within the file system or Registry for these connections to mapped shares on other systems, though the volatile information regarding drive mappings can be correlated to network connection information that you’ve already retrieved.

Figure 1.12 illustrates the output of the program di.exe (di stands for drive info), which you can find on the accompanying media.

Figure 1.12 Output of di.exe

The output of di.exe displayed in Figure 1.12 is the result of the program being run on a Windows XP Home system with one drive mapped to a small Windows 2003 server, specifically to the C$ share on that server.

Notice that the output of di.exe also shows a removable drive assigned the drive letter G:\.

Besides resources used by the system you are investigating, you will also want to get information regarding resources the system is making available. Information for shares available on a system is maintained in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\lanmanserver\Shares key, but can also be retrieved from a live system using CLI tools such as share.exe, which is available on the accompanying media. (The Perl source code for the program is also available.)

An excerpt of the output of share.exe follows:

Tip::

Throughout this topic so far, we’ve discussed using WMI through Perl. I’ve presented a number of examples, and made the code available to you on the accompanying media. Microsoft also provides access to WMI through the native CLI tool, wmic.exe (http://support.microsoft.com/kb/290216/en-us). Wmic. exe can be extremely useful for collecting a wide range of information from remote systems across the enterprise. In March 2006, Ed Skoudis published a SANS Handler’s Diary entry (http://isc.sans.org/diary.html?storyid=1229) that gave a number of very cool and very useful command-line options for using wmic.exe.

Nonvolatile Information

During live response, you might not want to restrict yourself to collecting only volatile information. The situation could dictate that the investigator needs to collect information that would normally be considered persistent even if the system were rebooted, such as the contents of Registry keys or files. The investigator could decide that information needs to be extracted from the Registry or that information about (or from) files needs to be collected, either for additional analysis or because an attacker could be actively logged in to the system. In such cases, the investigator may decide that to track the attacker (or botnet), she wants to leave the system live and online, but she also wants to preserve certain information from being modified or deleted.

Once a system has been started, there could have been modifications, such as drives mapped to or from the system, services started, or applications installed. These modifications might not be persistent across a reboot, and therefore might need to be recorded and documented by the investigator.

Registry Settings

Several Registry values and settings could impact your follow-on forensic analysis and examination. Although these settings are nonvolatile themselves, they could have an effect on how you choose to proceed in the conduct of your investigation or even whether you continue with your investigation at all.

There are several tools for collecting information from the Registry. My favorite (if you haven’t guessed by now) is to write a Perl script that provides the various functionality for retrieving specific values or all values and subkeys of a particular key. Reg.exe is a command-line tool for accessing and managing the Registry that is part of the Windows 2000 Support Tools and is native to Windows XP and 2003.

ClearPageFileAtShutdown

This particular Registry value tells the operating system to clear the page file when the system is shut down. Because Windows uses a virtual memory architecture, some memory used by processes will be paged out to the page file. When the system is shut down, the information within the page file remains on the hard drive and can contain information such as decrypted passwords, portions of IM conversations, and other strings and bits of information that might provide you with important leads in your investigation. Although most examiners understand that the page file is an amorphous blob of data, largely without context (i.e., locating an interesting string in the page file doesn’t provide you with important context information, such as which process that string was associated with), advances in Windows memory analysis have determined ways to expand the information available in a dump of Windows physical memory by incorporating the page file into the analysis. If this file is cleared during shutdown, this potentially valuable information will be more difficult to obtain, if not completely lost.

Microsoft has Knowledge Base articles for this Registry value that apply to both Windows 2000 (http://support.microsoft.com/kb/182086/EN-US) and Windows XP (http://support.microsoft.com/kb/314834/EN-US/).

DisableLastAccess

Windows file systems have the ability to disable updating of the last access times on files. According to Microsoft, this was meant as a performance enhancement, particularly on high-volume file servers. On normal workstations and the sorts of desktops and laptops most folks are using (home computers, employee desktops, etc.) this setting doesn’t provide any noticeable improvement in performance. On Windows 2003, you would set the following value to 1:

According to performance-tuning guideline documents from Microsoft for Windows 2003, this value does not exist by default and must be created.

Warning::

Microsoft Knowledge Base article 555041 (http://support.microsoft.com/ kb/555041) refers to this value as DisableLastAccess, but Microsoft Knowledge Base article 849372 (http://support.microsoft.com/kb/894372) refers to the value as NtfsDisableLastAccessUpdate. Knowledge Base article 150355 refers to the NtfsDisableLastAccess value on Windows NT 3.51 and 4.0.

On Windows XP and 2003 systems, you can query or enable this setting via the fsutil command. For example, to query the setting, use this command:

If this Registry value has been set, particularly sometime prior to you conducting your examination of the system, it is likely that you won’t find anything useful with regard to file last-access times.

Warning::

The NtfsDisableLastAccessUpdate functionality is enabled by default on Vista. Keep this in mind when you’re performing incident-response and computer forensic investigations. As of this writing, information is still being developed for forensic investigators with regard to this issue.

Autoruns

Several areas of the Registry (and the file system) are referred to as autostart locations because they provide a facility to automatically start applications, usually without any direct interaction from the user. Some of these locations will automatically start applications when the system boots, others when a user logs in, and still others when the user takes a specific action. In instances where an application is started when the user performs a certain action, the user will be unaware that he is launching another application.

Okay, I know this stuff is in the Registry, and that fact in itself might make this seem like a daunting or impossible task, but the good news is that a finite number of locations serve this purpose. The number might be large, but it is finite. Rather than listing them here, I’m going to leave a more in-depth review of Registry analysis for later in the topic. However, if you decide you need to collect this information as part of your first-response activities, there are two ways to go about it. The first is to use a tool such as reg.exe (mentioned previously) to collect data from specific keys and values. The second way is to use a tool such as Autoruns (http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx) to do it for you. The authors of Autoruns (Mark Russinovich and Bryce Cogswell, now Microsoft employees) do a great job of maintaining the list of areas checked by the tool. In some cases, I’ve found new additions to the tool before I’ve seen those autostart locations in widespread use in malware. Autoruns comes in GUI and CLI versions, both with the same functionality. For example, you can use the —m switch in the CLI version to hide signed Microsoft entries (entries for executable files that have been signed by the vendor) or the —v switch to verify digital signatures.

Autoruns also does a great job of checking areas within the file system, such as Scheduled Tasks. Sometimes administrators will use Scheduled Tasks to provide themselves with elevated (i.e., SYSTEM level) privileges to perform such tasks as view portions of the Registry that are normally off-limits even to administrators. An attacker who gains Administrator-level access to the system could do something similar to further extend his presence on the system.

Another area of the Registry that can provide valuable information in an investigation is the Protected Storage area (see the "Protected Storage" sidebar). The information held in Protected Storage is maintained in an encrypted format in the Registry. If you acquire an image of the system, tools such as AccessData’s Forensic ToolKit will decrypt and recover the information. However, sometimes it is simpler to collect this information as part of live-response activities, particularly if time is of the essence and the information is pertinent to the case.

Notes from the Underground…

Protected Storage

Protected Storage is an area of memory where sensitive information for the user is maintained. When the system is turned off, this information is stored in encrypted format in the Registry, and when the user logs in, the information is placed into memory. Windows places information such as passwords and AutoComplete data for Web forms in Protected Storage for later use.

You can view the contents of Protected Storage on a live system by using tools such as pstoreview.exe (www.ntsecurity.nu/toolbox/pstoreview) or the Protected Storage Explorer (www.codeproject.com/KB/cpp/psexplorer.aspx).

Information within Protected Storage can be useful in cases involving access to Web sites and the use of passwords for services such as Hotmail and MSN.

Information in Protected Storage is also useful to bad guys. I’ve seen systems infected with IRCbots (malicious software that, once installed, connects to an IRC channel awaiting commands; the channel operator can issue one command that is then executed by thousands of bots) that will send information from Protected Storage to the bad guy, on command. On February 19, 2006, Brian Krebs published an article (www.washingtonpost.com/wp-dyn/content/article/2006/02/14/AR2006021401342.html) in the Washington Post Magazine about a hacker who wrote bot software and controlled thousands of systems. In that article, Brian wrote that the hacker could type a single command (pstore) and retrieve the Protected Storage information from all the infected systems, which contained username and password combinations for PayPal, eBay, Bank of America, and Citibank accounts, as well as for military and federal government e-mail accounts.

The information held by the Protected Storage Service is available through the AutoComplete functionality built into the Internet Explorer Web browser. The AutoComplete Settings, shown in Figure 1.13, are available by clicking Tools in the Internet Explorer menu bar and then choosing Internet Options | Content, and then clicking the AutoComplete button.

With AutoComplete enabled, the users of these infected systems have used Internet Explorer to access their online shopping and banking accounts, making them available to an attacker such as the hacker in Brian’s article.

Figure 1.13 AutoComplete Settings Dialog Box on Internet Explorer 6.0

Tools such as PassView (www.nirsoft.net/utils/pspv.html) and the Protected Storage Explorer (www.forensicideas.com/tools.html) allow you to view the Protected Storage information in a nice GUI format, and pstoreview.exe (www.ntsecurity.nu/toolbox/pstoreview) is a CLI tool that will provide the same information to STDOUT. You might need to collect this information in the course of an investigation, particularly if the issue you’re dealing with involves users accessing Web sites that require passwords. You can extract this information from an acquired image, but doing so requires special tools to address the decryption, tools that can be expensive. There may be live-response situations (e.g., data theft or exfiltration, missing persons, etc.) where you will want to collect this information from a system quickly, rather than waiting until an image has been acquired and the data taken to a lab for extraction and analysis.