Home > Articles > Operating Systems, Server > Microsoft Servers

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.

08fig10.gifFigure 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.

08fig11.gifFigure 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);
# 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>) {
    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>) {
        next unless ($_ =~ m/^\d/);
        my @proc = (split(/\s+/,$_,6))[0,1,3,4,5];
        my $str = join(';',@proc);
    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>) {
        my ($process,$pid) = (split(/\s+/,$_))[0,1];
        next unless ($pid =~ m/^\d+/);
        next if ($pid =~ m/^\d\.\d+/);
        $data{$pid} = $process;
    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?

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020