This chapter is from the book
This chapter is from the book
This chapter is from the book
Collecting Data Using FSP
The client components of the FSP make it extremely easy to collect data from a "victim" system. However, this ease of functionality is in part due to the preparation and configuration of the client components by the investigator prior to deployment. The FSP is written in an interpreted language such as Perl in order to make it relatively easy for the administrator to modify it to suit her particular needs. The client components to the FSP, with the exception of the First Responder Utility (FRU), are intended to be flexible and easy to use. Ease of use and automation (i.e., restricting the amount of interface with the application that is required of the first responder) are the key aspects of the FRU.
Launching the Forensic Server
In order to use the FSP, the investigator launches the server component on the system where she wishes to store data. This system may be the investigator's workstation or a specific system set aside to be the FSP. This system should be physically secure, locked inside an office if the investigator herself needs to go on-site. The system should also be secured while on the network, with patches up-to-date and all unnecessary services disabled.
The investigator's system will also contain the various tools that the investigator will use to correlate and analyze the data she collects from the "victim" system. See the "Setting Up the FSP" sidebar.
Once the investigator's system is set up and prepared, the command to launch the FSP is:
C:\Perl\FSP>fsp.pl
This assumes, of course, that the investigator installed Perl on the C:\ drive and placed the scripts for the FSP in the C:\Perl\FSP directory. Once the investigator runs this command, she will be presented with a configuration dialog for setting up the server component, as illustrated in Figure 8-1.
)
Figure 8-1 The initial configuration dialog for the FSP.
Setting Up the FSP
The first step in setting up the Forensic Server Project (FSP) for deployment and use is to set up Perl on a system in accordance with Appendix A, Installing Perl on Windows. First install the ActiveState Perl distribution and then the Win32::GUI module (see Appendix A for the necessary instructions). Finally, install the Digest::MD5 and Digest::SHA1 modules using the following commands:
C:\perl>ppm install Digest-MD5 C:\perl>ppm install Digest-SHA1
These commands will install the modules necessary for computing MD5 and SHA-1 hashes. The only other module used by the FSP server component, IO::Socket (for handling TCP/IP communications), comes as part of the ActiveState Perl distribution.
The system used to set up the FSP server component does not need to have a CD-ROM writer installed, as the server component of the FSP does not need to be copied to a CD. It can be run from the system on which it is set up. The FSP should remain much more flexible and easily configured (the Perl scripts are more easily modified if they aren't copied to a CD), as it will generally only be used and controlled by the investigator. The investigator will want to be able to add any number of data examination and correlation tools to the FSP, using third-party tools, Perl, or any other programming language.
The version of the FSP included with this book makes use of relative paths. In essence, this means that the case directories created when using the FSP will be within the directory in which the FSP "lives," where the FSP files are located. For example, the FSP was developed on a system in the D:\Perl\FSP directory. The main case directory, therefore, is D:\Perl\FSP\Cases, and all of the files collected from systems are in subdirectories.
Once you've installed Perl (version 5.8 from ActiveState was used for all development and testing for this book) and all necessary modules, copy all of the scripts used by the FSP into a directory on the system. For this book, the files were run from a directory named "FSP," which is a subdirectory of the "Perl" directory.
The initial configuration dialog for the FSP has five text fields that need to be filled out by the investigator. These text fields allow the investigator to establish a case management structure in order to separate different cases. The first field, labeled "Case Dir," refers to the directory in which the particular case directory will be created. A "case" refers to an event about which the investigator wishes to collect data. In this version of the FSP, the case directory is located immediately below the directory that FSP is launched from, in this case, C:\Perl. The default setting for the "Case Dir" entry is simply "cases."
The second text field, with the label "Case Name," allows the investigator to select a name for the case. This name will be given to a subdirectory within the case directory that is unique to the case. The default entry for the "Case Name" field is "<new case>." The brackets are intended to remind the investigator to change the entry. The "Case Dir" and "Case Name" make up the case management component of the FSP, allowing the investigator to keep data collected from various systems and during various incidents separated.
The "Port" field is intended to allow the investigator to designate the port that the FSP listens on for connections. This field is specifically intended to be configurable, making it easy to use in a wide range of environments. For example, on an internal corporate infrastructure, the investigator may have no restrictions regarding network communications. However, when communicating with remotely connected offices, or even via the Internet, there may be firewall rulesets and router access control lists that come into play. The default port of 7070 may be acceptable when collecting data from a system located on the same local area network as the FSP. However, the investigator may be forced to configure the server to listen on port 80 if data is being collected from a system located in a remote location on a wide area network.
The "Investigator Name" field ("<investigator name>" by default) provides a place for the investigator to designate the name of the individual responsible for any portion of the investigation. When the server is started (i.e., when the investigator fills out the appropriate fields and clicks "OK"), the information in this field (as well as the "Port" field) is logged as part of the investigation documentation.
The final field, "Logfile," is intended to provide the name of the file ("casedoc.log" by default) to which all of the case documentation will be logged. This file contains a time-stamped listing (based on the local time on the server) of all of the activity that occurs with the case while data is being collected. Once the investigator stops collecting data, logging stops.
Once the investigator fills out the fields appropriately, she launches the server by clicking the "OK" button. At that point, the GUI will disappear, and a record of activity will appear in the standard output (STDOUT) of the command prompt used to launch the server. This serves to give a visual record of what's going on, while additional information is logged to the case logfile. Figure 8-2 illustrates the Forensic Server once it has been configured and is running, awaiting a connection.
)
Figure 8-2 The Forensic Server running.
When all of the data has been collected, the investigator simply hits Ctrl+C to shut the server off. In order to do this, of course, the investigator needs to be seated at the console of the server.
As previously stated, the version of the FSP provided with this book does not support encrypted communications between the client components and the server. This functionality can be added by an investigator with the necessary Perl programming skills and will be included in future versions of the FSP.
Running the First Responder Utility
In order to collect data using the Forensic Server, the investigator needs to run one or more of the client utilities on the "victim" system. One such client is the First Responder Utility, or FRU. The FRU is intended for use by first responders, which may be a system administrator. The FRU is deployed via CD-ROM (see Appendix A and the "Setting Up the FRU" sidebar), which the first responder will place in the CD-ROM drive of the "victim" system and then run the utility.
Setting Up the FRU
The first step in setting up the First Responder Utility (FRU) for deployment and use is to set up Perl on a system in accordance with Appendix A. Once the ActiveState Perl distribution has been set up, install the following modules:
-
Win32::GUI (see instructions in App. A)
-
Win32::Lanman (see instructions in App. A)
-
Win32::Perms (ppm install http://www.roth.net/perl/packages/win32-perms.ppd)
-
Win32::API::Prototype (ppm install http://www.roth.net/perl/packages/win32-api-prototype.ppd)
-
Win32::TaskScheduler (ppm install http://taskscheduler.sourceforge.net/perl58/Win32-TaskScheduler.ppd)
-
Win32::DriveInfo (ppm install win32-driveinfo)
-
Win32::IPConfig (ppm install win32-ipconfig)
All other modules used by the FRU are included with the ActiveState Perl distribution.
The system used to set up the FRU should have a CD-ROM writer installed with its associated software, or you should be able to copy the Perl directory to a system that has one, in order to create the First Responder CD. The same system that was used to set up the FSP can be used to set up the FRU.
The version of the FRU (as well as the FSP) included with this book makes use of relative paths. In essence, this means that all of the scripts that make up the client components and the tools used by the client components must be in the same directory.
Once you've installed Perl (version 5.8 from ActiveState was used for all development and testing for this book) and all necessary modules, create a directory within the "perl" directory called "fsp" and copy all of the scripts for the FRU into that directory. Also be sure to download all of the third-party utilities used by the FRU into that directory as well.
The version of the FRU included with this book uses the following third party utilities:
-
Cmd.exe, the command interpreter on Windows systems (Note: You must ensure that you get copies of this program from "clean" systems. This means that if you are going to respond to incidents on Windows 2003 servers, you must get a copy of cmd.exe from this system.)
-
Psloggedon.exe, pslist.exe, psloglist.exe, psinfo.exe, listdlls.exe, and handle.exe from SysInternals.com [4]
-
Tlist.exe from the Microsoft Debugging Tools [5] (i.e., not the Resource Kit)
-
CmdLine.exe, iplist.exe, and openports.exe from DiamondCS [6] (Note: Licensing information on the DiamondCS web site states that openports.exe is free for personal use, as well as in public education institutes. A small licensing fee is required for use of this utility in commercial and business environments.)
-
Rifiuti.exe and cygwin1.dll from FoundStone [7]
-
Promiscdetect.exe and pstoreview.exe from NTSecurity.nu [8]
-
Reg.exe and auditpol.exe from Microsoft
Each of these third party utilities is prefixed with "fru_" when stored in the same directory as the fru.pl Perl script. This is hard-coded into the FRU Perl script (i.e., fru.pl) and intended to ensure that there are no issues with the tools or programs with the same names already being in the PATH on the "victim" system.
The source code for the FRU includes several "require" statements. These statements identify other Perl scripts that the FRU makes use of and depends upon, as these scripts contain additional code used by the FRU. When copying the FRU code from the CD that accompanies this book, be sure to include the following Perl scripts in the same directory as fru.pl:
-
getos.pl (identifies the operating system)
-
pclip.pl (retrieves the Clipboard contents)
-
e_cmd.pl (very important, as it provides a wrapper for running third-party executables)
-
service.pl (retrieves service and device driver information)
-
getsys.pl (retrieves system information)
-
tasks.pl (retrieves information regarding Scheduled Tasks)
-
regdump.pl (retrieves Registry information)
-
mdmchk.pl (checks for installed modem drivers)
-
shares.pl (retrieves information regarding available shares)
-
dt.pl (retrieves drive information)
-
ip.pl (retrieves IP configuration information)
Each of these additional scripts must be present for the FRU to function properly.
The command interpreter, cmd.exe, should be copied to the root directory when you are ready to create your CD. This way, when the CD is inserted into the CD-ROM drive (for example, F:\) of the "victim" system, the command prompt can be opened by clicking on the Start button, choosing Run, typing "F:\cmd.exe" and clicking the OK button. From there, type the following commands to launch the FRU:
F:\>cd perl\fsp F:\perl\fsp>F:\perl\bin\perl.exe fru.pl
This assumes, of course, that the files for the FRU were placed in the FSP directory.
These commands can also be added to a batch file named "fru.bat". This makes it easier for the first responder to launch the FRU. When the command prompt appears, the first responder must simply type "fru" to launch the FRU.
Once the FRU GUI is visible, the first responder simply enters the IP address and the correct port (if the default is not correct) of the FSP into the appropriate text fields, and clicks on the "Go" button.
Once the data collection is complete (i.e., the final command, "Close Log", has been sent), the first responder simply clicks the "Exit" button, terminating the FRU, and withdraws the CD from the system. As long as the server is still running, the first responder can insert the CD into another "victim" system and repeat the process.
The FRU can be used from geographically remote locations, such as a wide area network in which there is TCP/IP connectivity between the "victim" system and server. The first responder places the CD-ROM containing the utilities in the CD drive of the "victim" system and then opens the appropriate command prompt for the operating system of the "victim" system. This is most easily done by clicking on the Start button, choosing "Run," and then entering the path to the appropriate version of cmd.exe, located on the CD. When the prompt opens, the first responder will cd (i.e., change directories) to the appropriate directory and type fru.pl at the prompt in order to launch the FRU. Figure 8-3 illustrates the FRU GUI.
)
Figure 8-3 First Responder Utility GUI.
Once the FRU is running, the first responder has only to enter the IP address and port used by the Forensic Server and then click the "Go" button. The first responder may enter the IP address of the server as an argument at the command prompt, or she may enter it into the "Forensic Server IP" field in the GUI. The "Forensic Server Port" is set to 7070 by default, the same as the Forensic Server. However, in the case of both the server and clients, this port is configurable.
The FRU is completely automated in order to remove the first responder from the data collection process as much as possible. The FRU should be completely configured by the investigator prior to being copied to a CD (or USB thumb drive) so that the first responder won't have to make any decisions regarding what information to collect.
Once both the Forensic Server and the FRU have been correctly configured and the first responder clicks "Go," the FRU will take over, limiting the interaction that the first responder has with the potentially compromised system.
The first thing the FRU does is attempt to ping the FSP server system itself. If the investigator's FSP server system is Windows XP and has the Internet Connection Firewall (ICF) enabled, it will have to be disabled or configured to respond to ICMP pings and allow connections to the FSP server.
Once connected to the server, the FRU will automatically collect the data and send it out through the network to the waiting server. Throughout the data collection phase, as data is sent to the server, the server will compute MD5 and SHA-1 hashes of each of the files and record this information in the case log file. Figure 8-4 illustrates the FRU after it has completed collecting and sending data to the server.
)
Figure 8-4 The First Responder Utility after completing data collection.
As the FRU collects data and sends it to the server, the text area of the FRU GUI is updated so that the first responder will be able to observe the progress. The CLOSELOG command indicates to the first responder that the FRU has completed its data collection. All FSP clients send command verbs to the server in order to indicate what actions should be taken. The CLOSELOG command is always the last command to be sent, and when the server receives that command, it places a final entry in the case log file, closes it, and computes MD5 and SHA-1 hashes for the case log file. This provides a level of assurance that the log file integrity has been maintained, allowing the investigator to show that the log file has not been modified.
Figure 8-5 illustrates what the investigator sees at the Forensic Server as the FRU sends the data across the network.
)
Figure 8-5 The activity of the Forensic Server while the FRU sends data.
After the server has been launched, it waits for a connection attempt from one of the client utilities. Once a connection has been created, the server will receive and process the data that the client sends to it. In the case of the FRU, Figure 8-5 illustrates how the client connection is received (i.e., the FRU client is being run from the system using IP address 10.1.1.15), and how the command being sent is displayed. Again, this provides a visual indication to the investigator of the progress of the data collection. The activity status of the FSP that appears on the screen is also recorded in the case log file.
Figure 8-6 illustrates the contents of the case directory from an example case. All of the data is stored on the server in flat files. The naming convention for the files consists of the NetBIOS name of the "victim" system (i.e., "Kabar"), followed by the command that was run. The file extension is .dat to indicate that the files contain data.
)
Figure 8-6 Contents of the case directory after running the FRU.
Information collected by the FRU includes:
-
Process information (tlist.exe, pslist.exe, listdlls.exe, handle.exe, cmdline.exe, openports.exe)
-
Logged on user (psloggedon.exe)
-
Network connection information (openports.exe, ip.pl, iplist.exe, promiscdetect.exe)
-
System information (psinfo.exe, getsys.pl)
-
Protected storage information (pstoreview.exe)
-
Clipboard contents (pclip.pl)
-
Service and device driver information (tlist.exe, service.pl)
-
Scheduled tasks (tasks.pl)
-
Registry information (regdump.pl, reg.exe)
-
Modem drivers (mdmchk.pl)
-
Information about shares (share.pl)
-
Drive information (dt.pl)
-
Audit policy (auditpol.exe)
-
Event Logs (psloglist.exe)
-
Recycle Bin contents (rifiuti.exe)
All of the third-party executables used by the FRU are stored in the same directory as the FRU Perl scripts. Each of the executables is prefixed with the tag "fru_" (without the quotes) to avoid any issues that may occur if a malware file of the same name as one of the executables is located in the PATH. These executables allow the FRU to collect a variety of information from the "victim" system.
File Client Component
Setting up the file client component is similar to setting up the FSP server and FRU components. In fact, this component should be set up along with the FRU. The file client component uses the following modules that are not part of the ActiveState Perl distribution:
-
Win32::GUI (see Appendix A for installation instructions)
-
Win32::FileOp (ppm install Win32-FileOp)
-
Digest::MD5 (ppm install Digest-MD5)
-
Digest::SHA1 (ppm install Digest-SHA1)
The file client component of the FSP provides a little more flexibility for the investigator with regards to the interface. The file client allows the investigator to copy files from the "victim" system to the FSP server. The initial interface to the file client (fcli.pl) is illustrated in Figure 8-7.
)
Figure 8-7 Initial interface to the file copy client of the FSP.
Once the interface is up, the investigator clicks on the File item in the menu bar and then on the Config item in the drop-down menu in order to configure the client to connect to the server. The Configuration Dialog will appear, as illustrated in Figure 8-8.
)
Figure 8-8 Configuration Dialog of the file client component.
All the investigator needs to do is enter the IP address and port of the FSP server and click OK. As with the FRU and the FSP, the default port in the Configuration Dialog is 7070.
In order to select the files to be copied, the investigator chooses the Open item from the drop-down menu rather than the Config item. Clicking on the Open item opens the File Selector dialog, as illustrated in Figure 8-9.
)
Figure 8-9 File Selector dialog of the file client component.
The investigator can choose multiple files from each directory presented in the file selector dialog. When she does, she clicks OK, and the list of files in the main view of the file client component will be updated. If other files from other directories on the "victim" system also need to be copied, the investigator will reopen the file selector dialog and select those files.
Once all the files that the investigator is interested in have been selected (and the information in the Configuration Dialog has been verified, if need be), she then clicks the OK button in the main window, and the file client component takes care of the rest. As the file client moves through the list of files, it first collects information about each file, specifically the MAC times, full path, size in bytes, and MD5 and SHA-1 hashes. This information is then sent to the FSP server and saved in a file with the name of the original file and a .dat extension. Listing 8-1 illustrates the contents of an example .dat file created on the server.
Example 8-1. Contents of an example .dat file
ctime:Thu Aug 14 21:14:41 2003 sha1:bbe028069169da0f3b86b6b6ceb6cc58e1088ec8 mtime:Thu Aug 14 21:21:43 2003 name:C:\WINNT\system32\LogFiles\W3SVC1\ex030815.log atime:Wed Mar 10 14:00:04 2004 md5:0195c718f03bca769189bc2694ba5875 size:359
The values of the .dat file are colon-separated so that they can be easily parsed and loaded into a Perl hash data structure for ease of use. The MAC times stored in the .dat file are based on the system time available on the "victim" system and are not converted or modified in any way once they appear on the server.
The file is then opened in binary mode and copied to the FSP server. Once the file has been copied, the FSP server component opens the associated dat file and attempts to verify the MD5 and SHA-1 hashes. All of this activity is logged. Listing 8-2 illustrates an excerpt of the case log file, showing the logged activity when a file is copied to the server.
Example 8-2. Excerpt of case log file from file copy
Wed Mar 10 15:36:34 2004;DATA command received: ex030815.dat Wed Mar 10 15:36:34 2004;HASH ex030815.dat:d053eb8b0527691db3de041d3d173d18:aa47c9f63f1dc5eb86873b5a5e33db5a351ca5a7 Wed Mar 10 15:36:34 2004;FILE command received: ex030815.log Wed Mar 10 15:36:34 2004;ex030815.log created and opened. Wed Mar 10 15:36:34 2004;ex030815.log closed. Size 359 Wed Mar 10 15:36:34 2004;MD5 hashes confirmed for ex030815.log. Wed Mar 10 15:36:34 2004;SHA-1 hashes confirmed for ex030815.log.
As illustrated in Listing 8-2, the server receives the initial DATA command, telling it that data is being sent. The file is then created on the server, and MD5 and SHA-1 hashes are generated for the newly created file. The values on the second line of Listing 8-2 are separated by colons so that they can be easily parsed and used for verification later. Each of the entries in the file is prefixed with a time stamp in order to document the progression of the activities. These time stamps are derived from the system time of the server.
The server then receives the FILE command, indicating that a file will be sent. The server receives all of the bytes sent by the client component and places them in a file on the server. Once the file is closed, the size of the file is recorded in the log file, and the MD5 and SHA-1 hashes are verified in order to ensure the integrity of the file, proving that it hasn't been modified in any way.
Once all of the files have been sent to the server, the file client (as with the FRU) sends the CLOSELOG command. Again, a final entry is added to the log file, after which it is closed. The server then generates hashes for the case log and saves those to a separate file. At that point, it is up to the investigator to maintain the physical security of the server system in order to ensure the integrity of the data saved on it.
Once the investigator has collected all of the files she's interested in and copied them to the server, she can use several of the tools (i.e., third-party tools and Perl scripts) listed in Chapter 5, Incident Response Tools, to analyze those files. For example, let's say the investigator uses the FRU or a similar tool to collect information from a system she thinks may have been compromised. Based on the information she collected, she decides to copy several files from the system via the file client component. Once she has copied those files, she can use tools such as strings.exe, sigs.pl (from Chapter 3), and ver.pl to retrieve information from them and get a better idea of the extent of the issue. If any of the files copied are MS Office documents, such as Word documents, she can use tools such as wd.exe and meta.pl (discussed in Chapter 3) to locate hidden data within those documents.
The FRU and the file client are simply two components that can be used with the FSP server component. As all of the components are written in Perl and are open-source, they can be modified and extended to suit the needs of the investigator.