- The Forensic Server Project
- Collecting Data Using FSP
- Correlating and Analyzing Data Using FSP
- Future Directions of the Forensic Server Project
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Correlating and Analyzing Data Using FSP
Using the Forensic Server Project, collecting data from a "victim" system is relatively easy. However, the issue of correlating the data for analysis still needs to be addressed. Now that all of this data has been collected, what do we do with it?
The client components of the FSP are capable of collecting a wide range of data from Windows systems. Much of the data collected by these components is the result of external third-party utilities that send their output to the screen (i.e., standard output, or STDOUT) when run from the command prompt. All of these utilities send their output to STDOUT with their own formatting. When their output is captured and sent to the FSP, the result is many files, all with their data in different formats. This data needs to be parsed and put into a format that can be easily reviewed and understood.
Some of the data collected by the FRU can be easily understood. For example, the output of the promiscdetect tool (i.e., appears on the server as "<systemname>-promiscdetect.dat") is fairly straightforward, in that if the network interface card (NIC) of the system were in promiscuous mode, indicating that a network sniffer is running, then the output would display information to that effect. The investigator can open the output file and quickly determine whether the network interface card is in promiscuous mode or not.
Other information isn't quite as easy to pull from the data collected from the "victim" system. For example, a complete view of the process information from a Windows system is only possible by using several tools. Fortunately, one strength of the Perl programming language is in quickly handling flat text files such as those produced by the FSP and FRU. The different ways that these files can be parsed and the information within them presented depends only on the programming skills and needs of the investigator. One of the primary needs of the investigator when trying to track down malware is to be able to correlate processes to the resources they're using, such as ports, as well as the command line used to launch the process. This information can be very useful to the investigator in locating malware or a suspicious process. However, the information required by the investigator is spread across several files. By making use of Perl, the investigator can quickly locate processes that may be harboring malware.
One example for the power of Perl when correlating data from across various files is a script entitled procdmp.pl. This script is a process dumperutility, in that it parses the contents of several files (all containing information specific to processes) and correlates that information, listed by process identifier (PID) in a single HTML file. The script correlates the process data from the various files and presents it in an easy-to-view HTML file. The procdmp.pl Perl script is used in the following Windows 2003 case study and is included on the CD that accompanies this book.
In order to illustrate the use of both the data collection and correlation aspects of the FSP, let's take a look at two case studies. The first is a Windows 2003 system that is "infected" with a network backdoor. The backdoor is, in reality, a copy of netcat renamed to inetinfo.exe, listening on port 80. The second case study is of a Windows 2000 system "infected" with the AFX Rootkit 2003 that was discussed in Chapter 7, Knowing What To Look For.
Infected Windows 2003 System
In order to demonstrate the use of the FRU and FSP, a Windows 2003 system was "infected" with a network backdoor. The FSP is installed on a Windows XP laptop connected to a network via a wireless adapter. The FRU was created and tested on a Windows 2000 system and copied to a CD along with "clean" copies of cmd.exe and netstat.exe taken from a Windows 2003 system. None of the other utilities used with the FRU are native to the Windows 2003 system.
Once the FRU CD is available, it is inserted into the CD-ROM drive of the "infected" system. The command prompt from the CD is launched via the Run box (as described earlier), and the FRU is launched (also as described earlier). The IP address of the waiting FSP is entered into the "Forensic Server IP" field and the "Go" button is clicked.
Figure 8-10 illustrates what the FRU looks like once it has completed sending all data to the server.
)
Figure 8-10 FRU after sending data from a Windows 2003 system.
The server was configured to place all files in a directory named "netcase2k3." Now all the investigator needs to do is parse through all of these files, with the exception of the log files, looking for something unusual.
Since we have the advantage of knowing that the system was "infected" with a network backdoor, we have an idea that we may be looking for malware of some kind. With that in mind, the first thing we'll do is run the procdmp.pl Perl script and examine the output HTML file. Figure 8-11 illustrates an excerpt from that file, showing a suspicious process.
)
Figure 8-11 Excerpt from the procdmp.html file.
The full HTML file, procdmp.html, is included on the accompanying CD-ROM.
On many Windows systems, finding a process called "inetinfo" running in the Task Manager is not unusual, as this is the name of the process that manages the Microsoft Internet Information Server (IIS) web server. Seeing the process name and noting in the output of netstat –an (add the -o switch for Windows XP and 2003) that port 80 is open and in LISTENING mode is not unusual. However, in this case it is unusual because the service usually associated with the IIS server (specifically the World Wide Web Publishing Service, or W3SVC) is not running. Not only that, the command line used to launch the process is very unusual and definitely not something one would normally see being used to launch IIS.
In fact, this is the network backdoor process. If it's not already obvious from the command line for the process, this backdoor is really netcat.exe renamed to inetinfo.exe. The command line arguments indicate that the process is to listen for connections on port 80 and, when a connection is received, to launch a command prompt. Using netcat.exe in client mode to connect to the "infected" system on port 80 will bear this fact out. It is also important to note that the user context of the process is that of the local Administrator, meaning that anyone connecting to the system will have that same level of privileges.
A Rootkit on a Windows 2000 System
The FRU was run on a Windows 2000 system infected with the AFX Rootkit 2003, described in Chapter 7. The server component was run on a Windows XP system where the FRU data was collected and stored. The pd.pl Perl script, illustrated in Listing 8-3, was used to parse through the output of several of the files created by the FRU, looking for discrepancies.
Example 8-3. Perl script to parse the output of tlist, pslist, and openports from the FRU
#! d:\perl\bin\perl.exe
# pd.pl
# Parse output of pslist, tlist, openports from FRU
# Looking for discrepancies
use strict;
my $dir = shift || die "You must enter a directory name.\n";
$dir = $dir."\\" unless ($dir =~ m/\\$/);
my @files;
my %systems;
if (-e $dir && -d $dir) {
opendir(DIR,$dir) || die "Could not open $dir: $!\n";
@files = readdir(DIR);
close(DIR);
# First determine how many computers are in the case dir
foreach (@files) {
next unless ($_ =~ m/\.dat$/);
my $sys = (split(/-/,$_,2))[0];
$systems{$sys} = 1;
}
}
foreach my $sys (keys %systems) {
my $pslist = $dir.$sys."-pslist\.dat";
my $op = $dir.$sys."-openports-fport\.dat";
my $tlist = $dir.$sys."-tlist-c\.dat";
my %tlist = parse_tlist($tlist);
my @op = parse_op($op);
my %pslist = parse_pslist($pslist);
print "----------------------------------------------------\n";
print "$sys report\n";
print "----------------------------------------------------\n";
# Check to see what PIDs are in tlist, but not pslist
print "Processes in pslist but not tlist\n";
foreach my $key (keys %pslist) {
print "PID: $key Process: $pslist{$key}\n" unless (exists $tlist{$key});
}
print "\n";
print "Processes in tlist but not pslist\n";
foreach my $key (keys %tlist) {
print "$tlist{$key} = $key\n" unless (exists $pslist{$key});
}
print "\n";
# Check to see what PIDS are in openports
print "Processes in openports but not pslist/tlist\n";
foreach (@op) {
my ($pid,$process,$port,$proto,$path) = split(/;/,$_,5);
print "PID: $pid Port: $port Path: $path\n" unless (exists $pslist{$pid});
print "PID: $pid Port: $port Path: $path\n" unless (exists $tlist{$pid});
}
print "\n";
}
#-----------------------------------------------------------
# parse_tlist()
# parse the file generated by tlist -c
#-----------------------------------------------------------
sub parse_tlist {
my $file = $_[0];
my @lines;
my %data;
open(FH,$file) || die "Could not open $file: $!\n";
while (<FH>) {
chomp;
s/^\s+//;
push(@lines,$_);
}
close(FH);
my $fini = (scalar @lines) - 1;
foreach my $i (0..$fini) {
next unless ($lines[$i] =~ m/^\d+/);
my($pid,$name,$title) = split(/\s+/,$lines[$i],3);
my $cli = (split(/:/,$lines[$i+1],2))[1];
$data{$pid} = $cli;
}
return %data;
}
#-----------------------------------------------------------
# parse_op()
# parse the file resulting from "openports -fport"
#-----------------------------------------------------------
sub parse_op {
my $file = $_[0];
my @data;
open(FH, $file) || die "Could not open $file: $! \n";
while(<FH>) {
chomp;
next unless ($_ =~ m/^\d/);
my @proc = (split(/\s+/,$_,6))[0,1,3,4,5];
my $str = join(';',@proc);
push(@data,$str);
}
close(FH);
return @data;
}
#-----------------------------------------------------------
# parse_pslist()
# parse the output of "pslist"
#-----------------------------------------------------------
sub parse_pslist {
my $file = $_[0];
my %data;
open(FH, $file) || die "Could not open $file: $! \n";
while(<FH>) {
chomp;
my ($process,$pid) = (split(/\s+/,$_))[0,1];
next unless ($pid =~ m/^\d+/);
next if ($pid =~ m/^\d\.\d+/);
$data{$pid} = $process;
}
close(FH);
return %data;
}
The pd.pl Perl script takes a path to a case directory as its only argument. The first thing the script does is parse through the case directory in order to determine from how many systems data was retrieved. Remember that the FRU can be run on multiple machines, all with the same instance of the FSP server component, and the case directory can contain data from multiple systems.
After getting the name of each system with data in the case directory, the script parses three specific files—the output of tlist –c, pslist, and openports –fport, as collected by the FRU. The purpose of parsing these files is to locate any discrepancies in process information among these three files in the hopes of locating rootkits. By using multiple tools that retrieve process information using different APIs, the hope is to locate processes that may be hidden from one tool but not from another. The script first looks for process identifiers (PIDs) that are listed in the output of pslist but not tlist –c. The script then switches this check around and looks for PIDs that are listed in tlist –c but not in pslist. Finally, the script checks to see what PIDs are listed in the output of openports –fport but not in either pslist or tlist –c. Again, the idea is that if a process or PID is visible in the output of openports –fport, then it should also be visible in other process enumeration tools. If it isn't, then it may indicate a process that has been hidden, possibly by a rootkit. In any case, any information that appears in the output of the Perl script should be investigated.
Listing 8-4 illustrates the output from running the pd.pl Perl script against the data collected by running the FRU against a Windows 2000 system infected with the AFX Rootkit. The script's output is sent to the screen (i.e., STDOUT), rather than to a fancy HTML file. The system in question was described in Chapter 7. The data collected from this system using the FRU is located on the accompanying CD in a zipped archive named afx_2k.zip.
Example 8-4. Result of pd.pl run on Windows 2000 system infected with a rootkit
---------------------------------------------------- KABAR report ---------------------------------------------------- Processes in pslist but not tlist PID: 1280 Process: afx_nc Processes in tlist but not pslist Processes in openports but not pslist/tlist PID: 1280 Port: 8180 Path: C:\afx_nc.exe
The output of the pd.pl Perl script clearly demonstrates why multiple tools should be used to enumerate process information from Windows systems that the investigator or administrator suspects may have been compromised or infected.
A Compromised Windows 2000 System
For purposes of a reader exercise, a Windows 2000 system was compromised, and a network backdoor was installed. The FRU was run on this system, and the files created on the server are included on the CD in a zipped archive named win2k.zip. The reader is encouraged to explore and analyze these files. How was the system compromised? What did the attacker do to gain access to the system? What actions did the attacker take once he had gained access? How could the incident have been prevented?