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

Tasklist

Tasklist.exe, a native utility included with Windows XP Pro and Windows 2003 installations (it is noticeably absent from Windows XP Home), is a replacement for tlist.exe. The differences in the two tools are subtle and mostly concern the name and the implementation of the switches. Tasklist.exe does provide options for output formatting, with choices among table, comma-separated value (CSV), and list formats. The /v (or verbose) switch provides the most information about the listed processes, including the image name (but not the full path), PID, name and number of the session for the process, status of the process, username of the context in which the process runs, and title of the window, if the process has a GUI. The investigator can also use the /svc switch to list the service information for each process.

PsList

Pslist.exe (http://technet.microsoft.com/en-us/sysinternals/bb896682.aspx) displays basic information about running processes on a system, including the amount of time each process has been running (in both kernel and user modes). The -x switch displays details about the threads and memory used by each process. Pslist.exe launched with the -t switch will display a task tree in much the same manner as tlist.exe. Pslist.exe can also show detailed information about threads or memory used by a process. However, it does not provide information about a process in regard to the path to the executable image, the command line used to launch the process, or the user context in which the process runs.

ListDLLs

Listdlls.exe (http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx) shows the modules or DLLs a process is using. Listdlls.exe will show the full path to the image of the loaded module as well as whether the version of the DLL loaded in memory is different from that of the on-disk image. This information can be extremely important to an investigator because each program loads or "imports" certain DLLs. These DLLs provide the actual code that is used, so application developers don’t have to rewrite common functions each time they write a new application. Each DLL makes certain functions available, listing them in their export table, and programs access these functions by listing the DLL and the functions in their import tables. This allows you to "see" (using an appropriate tool) which DLLs the program loads or accesses. However, some programs can load additional DLLs that are not part of the import table; for example, the Internet Explorer browser can load toolbars and browser helper objects for which the code is listed in DLLs. Spyware, Trojans, and even rootkits use a technique called DLL injection to load themselves into the memory space of a running process so that they will be running and executing but won’t show up in a process listing because they are actually part of another process. This is different from a child process (as illustrated in the output of tlist.exe run with the -t switch) because the executing malware does not have its own PID.

Part of the output displayed by listdlls.exe includes the command line used to launch each process, excerpted as follows:

Using listdlls.exe (with the -d dllname switch), you can also list the processes that have loaded a specific DLL, in a manner similar to tlist.exe. This can be extremely useful if you’ve identified a specific DLL and want to see whether any other processes have loaded it.

Handle

Handle.exe (http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx) shows the various handles that processes have open on a system. This applies not only to open file handles (for files and directories), but also to ports, Registry keys, and threads. This information can be useful for determining which resources a process accesses while it is running. Figure 1.8 illustrates an excerpt of the output from running handle.exe, without any switches, on a Windows XP SP2 system.

Figure 1.8 Excerpt of Output of handle.exe

Figure 1.8 illustrates some of the handles opened by svchost.exe—in this case, several log files in the Windows directory. While I was writing this topic, for example, one of the handles opened by winword.exe included the full path to the Microsoft Word document.

Handle.exe has several switches that could be of use, such as -a to show all handles and -u to show the owning username for each handle.

Tools & Traps…

Processes and WMI

The Perl script proc.pl, located in the \ch2\code directory on the accompanying media, illustrates how Perl can be used to implement WMI and retrieve process information via the Win32_Process class. Both the script and the stand-alone executable named proc.exe (compiled from the Perl script using Perl2Exe, also available on the accompanying media) display the PID and name of the process, the user context of the process, the PID of the parent process, the command line of the process (if available), the path to the executable image to the process (if available), and the service information for the process.

You can run both the script and the executable locally or against a remote system. Simply type the name of the executable to run it on a local system. The syntax to run the executable against a remote system is as follows:

An example of this would appear as follows:

 

An excerpt of the output of proc.exe follows:

You can easily modify the script to display its output in another format, such as CSV, which is suitable for opening and analyzing in a spreadsheet.

The procmon.pl Perl script (and the accompanying executable, procmon.exe) located in the same directory is an interesting demonstration of the use of WMI to monitor the creation of processes on the local system. Simply launch procmon.exe from the command prompt, and while it is running it will report on the PID, user context, and executable path (and command line) of the new process, as illustrated in the following:

Tools such as procmon.exe are extremely useful in that they can be used to augment auditing of process creation as well as provide insight into processes created during the installation of applications and malware.

It should be clear by now that no single tool or utility displays all the information you might want to know about processes that you find during an investigation. You might want to run only one tool for a quick overview (tlist.exe or tasklist.exe would be good candidates), or you might want to run more than one tool; for example, you could run pslist.exe with the —x switch and the listdlls.exe utility. Depending on the level of detail you need for your investigation, you might want to run handle.exe as well. The level of granularity of information that you want to obtain will depend on your investigation.

Tools & Traps….

Svchost

Svchost is a process that appears often on Windows 2000, XP, and 2003 systems. It appears several times in the Task Manager, as many as two times (or more) on a default Windows 2000 system installation (with no other applications installed), five times on a Windows XP system, and seven times on a Windows 2003 system. Each instance of svchost.exe is running one or more services, as seen when you use tasklist /svc on Windows XP Pro and 2003 systems and tlist -s on Windows 2000 systems.

Microsoft Knowledge Base article Q314056 (http://support.microsoft.com/default. aspx?scid=kb;en-us;314056) provides more information regarding svchost.exe on Windows XP systems, and Knowledge Base article Q250320 (http://support.microsoft.com/default.aspx?scid=kb;en-us;250320) provides similar information with regard to Windows 2000.

In a nutshell, svchost.exe provides a generic process for running services from DLLs. Each instance of svchost can run one or more services. On startup, svchost reads the Registry key to obtain the groupings of services it should run:

Note the space in "Windows NT". This is very important, as by default, there is no Software\Microsoft\WindowsNT key.

Several Trojans and backdoors try to copy themselves to the victim system using the filename svchost.exe. Backdoor.XTS and Backdoor.Litmus are examples of malware that attempt to hide themselves as svchost.exe, most likely due to the fact that administrators and investigators should not be surprised to see multiple copies of svchost listed in the Task Manager. On Windows systems, copying the bogus svchost.exe to the system32 directory proves to be just a plain bad idea, since the file is protected by WFP on Windows 2000, XP, and 2003.

Tip::

Pulist.exe is a Resource Kit utility that lists the processes running on a system as well as the user context (the user account under which the process is running) for each process.

Process-to-Port Mapping

When a network connection is open on a system, some process must be responsible for and must be using that connection. That is, every network connection and open port is associated with a process. Several tools are available to the investigator to retrieve this process-to-port mapping.

Netstat

On Windows XP and Windows 2003, the netstat.exe program offers the — o switch to display the PID for the process responsible for the network connection. Once you’ve collected this information (refer back to the netstat -ano command), you will need to correlate it with the output of a tool such as tlist.exe or tasklist.exe to determine the name (and additional information) of the process using the connection.

As of Service Pack 2, Windows XP has an additional -b option that will "display the executable involved in creating each connection or listening port." This switch is also included in netstat.exe in Windows 2003 SP1 and can provide more information about the process using a particular port. In some cases, the output will also show some of the modules (DLLs) used by the process. Figure 1.9 illustrates an excerpt from the output of the command run on a Windows XP SP2 system.

Figure 1.9 Excerpt of Output from netstat -anob from a Windows XP SP2 System

Fport

Fport.exe has long been one of the tools of choice for obtaining the process-to-port mapping from a Windows system. The output of the tool is easy to understand; however, you must run the tool from within an Administrator account to obtain its information. This can be an issue if you’re responding to a situation in which the user’s logged-in account is a user account and does not have Administrator privileges.

Tcpvcon

Tcpvcon.exe is available from Microsoft (originally part of the Sysinternals.com tools) and is one of the best tools for retrieving the process-to-port mapping information from a Windows system. By default, tcpvcon.exe will show only information regarding TCP connections, and prints the information in the console in a tabular listing format, as illustrated here:

Using the —a and — c switches, you can tell tcpvcon.exe to display information about all connections (both TCP and UDP) in a CSV (.csv) format, which is easy to parse (with Perl, of course!) or open in Excel. Using the — n switch, you can tell tcpvcon.exe to not resolve IP addresses to names, so the output appears a bit more quickly. This output is very easy to parse using any number of tools.

Tip::

In general, you will want to obtain the IP address of the remote system(s) to specifically identify the system(s). However, in some cases you may also want to document the domain name of the remote system since some intruders or malware authors use dynamic domain name system (DNS) servers and the name may be more useful over time than the IP address.

Tip::

If the system you’re responding to is a Windows 2000 system that does not have installed the hotfix I mentioned earlier in the topic so that netstat. exe is capable of listing the PID for each network connection, an excellent alternative is to use tcpvcon.exe.

Keep in mind that tools such as tcpvcon.exe make use of APIs in DLLs native to the system to extract their information. That being said, you may also opt to use a port scanning tool such as Nmap (www.nmap.org) to remotely gather information on open ports from a potentially compromised system. In doing so, you could find a number of ports open in listening mode, awaiting connections; authentication services, Web servers, and File Transfer Protocol (FTP) servers do this, but so do backdoors. If you scan a system and find certain ports open but neither netstat nor any other tool that shows network connections or process-to-port mappings shows the same port open, you definitely have a mystery on your hands. At that point, you should double-check your scan results and ensure that you scanned the correct system. (Hey, it happens!) If the issue persists, you could have a rootkit on your hands.

Tip::

Comparing a network traffic capture or port scan to the output of netstat. exe or tcpvcon.exe is an excellent way to validate your findings. During one of my recent engagements, the customer had collected information from network traffic captures and perimeter device logs, and then mapped that information back to specific systems. Using the output of netstat.exe, they were able to validate that they had the correct systems, as they could see indications of the source and destination IP addresses and ports quite clearly. This also validated the fact that the systems were not infected with rootkits, which tend to try to hide such things as processes, files, network connections, and Registry keys.

Process Memory

A live system will have any number of running processes, and any one of those processes could be suspicious or malicious in nature. When a process is executed on a system, it is most often given the same name as the file where the executable image resides, and on Windows systems in particular a file can be named just about anything. The bad guys simply aren’t so helpful as to name their malicious code something that is easily recognizable, such as badstuff.exe. More often than not, they will rename the file to something less conspicuous, or they could try to disguise the intent of the program by using the name of a program usually found on Windows systems (see the "Svchost" sidebar).

Once you’ve used the tools we’ve discussed and found what you determine to be a suspicious process, you might decide that you want more information about what that process is doing. You can get this information by dumping the memory the process is using. You can use several tools to accomplish this task. As stated previously, you can find a detailed discussion of collecting the contents of RAM (as well as the memory used by specific processes) in next topic.

Network Status

Getting information about the status of the network interface cards (NICs) connected to a system can be extremely important to an investigation. For instance, today many laptops come with built-in wireless NICs, so you might not know just by looking at the desktop whether the system is connected to a wireless access point, and if so, what IP address it is using. Knowing the status of the NICs prior to a system being acquired can provide insight into a follow-on investigation.

Ipconfig

Ipconfig.exe is a utility native to Windows systems that the investigator can use to display information about NICs and their status. The most useful switch for investigators is /all, which is used to display the network configuration of the NICs on the system. This information includes the state of the NIC, whether DHCP is enabled, the IP address of the NIC, and more.

You might find this information useful during an investigation, because you might have network traffic logs to examine, and the IP address of the system could have been modified at some point. Also, many Web-based e-mail services (such as Yahoo! Mail) record the IP address of the system from which an e-mail was drafted in the header of the e-mail. I took part in one particular investigation in which a former employee was sending annoying (not harassing) e-mails to our company. Looking at the e-mail headers, we were able to determine from where he was sending the e-mails. Several of them had been sent from a local copy shop and others from a local public library. With the gracious help of administrators from the copy shop and the county, we were able to narrow the locations even further; in the case of the public library, we were able to pinpoint the branch of the library and the fact that the system he was using was on the second floor (one of the administrators had asked a library staff member to enter the ipconfig /all command on several systems until he located the IP address in question). Needless to say, the former employee was shocked when confronted with this information and stopped sending the e-mails. Had he not been fired and had he been sending the e-mails from his work system via Yahoo! Mail, we would have been able to determine his location as well.

PromiscDetect and Promqry

Sometimes compromised systems will have a "sniffer" installed to capture network traffic, such as login credentials to other systems, or to develop a picture of what other systems are on the network and what services they are running. Some malware payloads include this capability, or it can be a follow-on download installed by an attacker. For the NIC to capture network traffic in this manner, it has to be placed in "promiscuous" mode. This isn’t something an administrator or investigator will see, because there is nothing obvious to indicate that the NIC is in promiscuous mode. There’s no System Tray icon or Control Panel setting that clearly indicates to the investigator that the system is being used to "sniff" traffic.

Tools are available to tell you whether the NIC is in promiscuous mode. One such tool is promiscdetect.exe (www.ntsecurity.nu/toolbox/promiscdetect/). The other is promqry.exe (available from Microsoft, at a really long URL), written by Tim Rains. The primary difference between the two tools is that promqry.exe can be run against remote systems, allowing an administrator to scan systems within the domain for systems that might be sniffing the network.

Tools & Traps…

Promiscuous Mode

The Perl script ndis.pl (located in the \ch2\code directory on the media accompanying this topic) implements WMI code to determine the settings for a NIC. Specifically, it was designed to be used to determine whether a NIC is in promiscuous mode and is capable of sniffing packets from the network.

The file ndis.exe in the same directory is a stand-alone executable version of this script, provided for use by those who do not have Perl installed on a Windows system.

Figure 1.10 illustrates an excerpt of the output returned from ndis.exe.

The output displayed in Figure 1.10 was generated by launching the Wireshark (formerly known as Ethereal; www.wireshark.org) sniffer application on the wireless NIC and then running ndis.exe. The highlighted portion of the output clearly shows that the wireless NIC is in promiscuous mode.

Both the Perl script and the associated executable file are intended to be run only on the local system. However, minor modifications to the code will allow the script (or the executable, after the script is modified and recompiled) to be run against remote systems, in the same manner as promqry.exe.

Figure 1.10 Excerpt from the Output of ndis.exe on Windows XP

Another very important use for tools such as this is to determine what the active network interfaces might be on a live system. My old Toshiba Tecra 8100 systems require a PCIMCIA card to be able to connect to a wireless network, whereas many of the "newer" systems I’ve dealt with come with wireless networking capability built right into the system. You never see anything sticking out of the laptop case itself, nor do you see any blinking lights, as you do with the RJ-45 Ethernet connection. It’s just there. So, when Dave comes into a meeting and sits down behind his laptop, is he just taking notes or is he also surfing the Web and sending e-mail? Wireless access is becoming increasingly ubiquitous, not only because so many locations now have it available, but also because it’s being built right into our laptops.

This wireless access may be an entryway into your organization, or even a route that someone uses to get information out of your infrastructure. I once dealt with an issue in which a public relations person in our company decided that she needed to take her personal laptop into meetings so that she could have access to the Internet. But she decided this without contacting anyone from IT, or even me (I was the security administrator). When she fired up her laptop, she found our wireless access points, which had Wireless Encryption Protocol (WEP) keys and MAC address filtering enabled. Because she hadn’t contacted us and she was in a meeting and needed the access 10 minutes ago, she decided to connect to an open wireless access point that her system detected—one that was used by a company next door to us and that was wide open, with no security measures in place. Once she made that connection, she created an entry point into our infrastructure that bypassed all the protection mechanisms we had in place, including firewalls and antivirus software. At that point, it was hard to tell which situation was more damaging—her connection being used as a conduit to infect our infrastructure or the legal ramifications should the other company’s infrastructure suffer a security breach and any logging mechanisms showing her connection during that time.

During an investigation, it is generally a good idea to collect information about the active network interfaces on the system you are examining. This adds context not only to the volatile data you are collecting, but also to a postmortem analysis, which we will discuss later in this topic.