Service and Process Information For IR

Over at Harlan Carvey's blog he talks about getting the service information during a incident response. Well lets take it a step further by collecting this information before the incident and storing it into a database. By doing this we can then compare the data when in incident does happen or if were lucky and have added monitoring to the processes we may catch it.

What I have put together is a program that will read the database to get a list of servers that you want to get the process and services information for. I have also included web pages that you can view the data with and update the known process and services information. If you constantly run the batch program you can see if there are any unknown processes added to the servers. If you want to take it a step further you could check the database after the batch run and send a message if there are any unknown services/processes that are found (assumes that you have gone through every service/process on each server which if you have a large server farm may take awhile).

The zip file for these programs is here. There are 3 directories,

SQL - Has the create statements for the database
batch_update - Program that reads the servers from the database and updates the current processes/services in the database. I did not write this program just extended one that I had found. The original author was Thomas Berger.
web_pages - The web pages for data entry and showing what service/process is running on what servers.

As you get it and check it out I am sure you might find a few mistakes and possible extensions to the programs as well. If you extend it further then shoot me an email and let me know what you did, it is always interesting to see how ideas can grow.

Questions/Comments/Suggestions?

To DB or Not To DB.........

Man do I really love to use databases. When you have a decent database and a good design there is nothing that you can not accomplish. Now when I say databases you are probably thinking Oracle, DB2, Sql Server, Mysql, etc... Those are all great databases with rich features but I am thinking more along the lines of an embedded database. What I usually use is Sqlite, it is a embedded relational database that is small and fast and supports most of SQL92. By combining Sqlite and perl I can do many things. Some examples of what I can do are as follows:

Store data from log files and report on them based on different criteria.

Load data and use sql to generate commands, ie: load up file names and then use sql to generate rename commands for the files.

Load multiple log files and types and correlate the data into a comprehensive report.

I will now show you what I am talking about. I will use one of Harlan Carveys   Cpan scripts that reads the event logs. I will use the lsevt3.pl program and make a few modifications to insert the records into a Sqlite database. The initial program looks like this:

#! c:\perl\bin\perl.exe

use strict;
use File::ReadEvt;

my $file = shift || die "You must enter a filename.\n";
die "$file not found.\n" unless (-e $file);

my $evt = File::ReadEvt::new($file);
my %hdr = ();
if (%hdr = $evt->parseHeader()) {
# no need to do anything...
}
else {
print "Error : ".$evt->getError()."\n";
die;
}

my $ofs = $evt->getFirstRecordOffset();

while ($ofs) {

my %record = $evt->readEventRecord($ofs);
print "Record Number : ".$record{rec_num}."\n";
print "Source : ".$record{source}."\n";
print "Computer Name : ".$record{computername}."\n";
print "Event ID : ".$record{evt_id}."\n";
print "Event Type : ".$record{evt_type}."\n";
print "Time Generated: ".gmtime($record{time_gen})."\n";
print "Time Written : ".gmtime($record{time_wrt})."\n";
print "SID : ".$record{sid}."\n" if ($record{sid_len} > 0);
print "Message Str : ".$record{strings}."\n" if ($record{num_str} > 0);
print "Message Data : ".$record{data}."\n" if ($record{data_len} > 0);
print "\n";

# length of record is $record{length}...skip forward that far
$ofs = $evt->locateNextRecord($record{length});
# printf "Current Offset = 0x%x\n",$evt->getCurrOfs();
}
$evt->close();

One of the programs I use to create the database is SqliteSpy. This is a nice gui to create and view the data that you load into the database. What I did was create a table with the following definition:

CREATE TABLE events
( file_name text,
Record_Number number,
Source text,
Computer_Name text,
Event_ID number,
Event_Type text,
Time_Generated text,
time_generated_unix number,
Time_Written text,
time_written_unix number,
SID text,
Message_Str text,
Message_Data text);

You can compare this definition to the $record in the lsevt3.pl script. I have added 3 extra columns to make the table more flexible, they are:

file_name which is the event file name that is being loaded, this allows for multiple event logs to be inserted into the database.

time_generated_unix and time_written_unix were added to allow for easier selecting and sorting of timestamps.

The following is the changed lsevt3 program that does the inserts into the database (Added lines in Bold):

#! c:\perl\bin\perl.exe

use strict;
use File::ReadEvt;

use DBD::SQLite;

# Attributes to pass to DBI to manually check for errors
my %attr = (
PrintError => 0,
RaiseError => 0
);

# Create the connecton to the database
my $dbh = DBI->connect("dbi:SQLite:events.db3","","",\%attr);


my $file = shift || die "You must enter a filename.\n";
die "$file not found.\n" unless (-e $file);

my $evt = File::ReadEvt::new($file);
my %hdr = ();

my $sid = "";
my $message = "";
my $data = "";

if (%hdr = $evt->parseHeader()) {
# no need to do anything...
}
else {
print "Error : ".$evt->getError()."\n";
die;
}

my $ofs = $evt->getFirstRecordOffset();

# Make it so Inserts run in a batch mode
$dbh->do("Begin Transaction");

while ($ofs) {

my %record = $evt->readEventRecord($ofs);

# Convert data and check type to be inserted
if ($record{sid_len} > 0) {
$sid = $record{sid};
} else {
$sid = "";
}
if ($record{num_str} > 0) {
$message = $record{strings};
} else {
$message = "";
}
if ($record{data_str} > 0) {
$data = $record{data};
} else {
$data = "";
}

# Insert statement for the data into the events tables Use prepate and execute to handle quotes in the string fields
my $sql_stmt = qq{Insert into events values ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)};
my $sth = $dbh->prepare( $sql_stmt);
$sth-> execute( $file, $record{rec_num}, $record{source}, $record{computername},
$record{evt_id}, $record{evt_type}, $time_gen, $record{time_gen},
$time_wrt, $record{time_wrt}, $sid, $message, $data);

# Check for any errors in the insert statement
my $err_desc = $dbh->errstr();
if (($err_desc =~ m/not\sunique/) || ($err_desc eq "")) {
} else {
print "Error in Database $err_desc\n";
print "loading Record ".$record{rec_num}."\n";
}



# length of record is $record{length}...skip forward that far
$ofs = $evt->locateNextRecord($record{length});
# printf "Current Offset = 0x%x\n",$evt->getCurrOfs();
}

# Commit the Batch
$dbh->do("Commit");

$evt->close();


By running this program from the command line, lsevt3_db.pl Sysevent.evt, the events will now be loaded into the Sqlite database. You can then load multiple event logs into the table and report on them through sqlite.

The following is an example of a query to show when the Removable Storage Service wrote to the event log:

select * from events where source like 'Remov%';

or

To show the when the computer was started and stopped.

select * from events where event_id in (6009, 6006) order by time_generated_unix desc;

If you were to add the application events then you can see everything that happened during a specific time period as well (now you will see why the unix time is important to have since it is much easier to use and sort by).

select * from events where time_generated_unix between 1168484317 and 1168516719 order by time_generated_unix desc;


Now if you use x-ways forensics you can define the perl script under the external viewer programs and when you select a file you can have it run this program and it will load up the database as if you were running the program from the command line.

If there is interest I can post a generic perl script to print out reports from the database, just leave some comments and I will put one out there.

Hopefully I did not confuse you to much, if I did then let me know and I will try and make it less confusing.

Printing Restore Point Information From Another Computer

Since Harlan Carvey gave me an intro I felt I had to give up something else in order to make you want to come back.

Looking at the restore points you may wonder what all those files actually are and what they relate to in each RPXXX directory. Now if you are like me you will start to poke around and see if you can figure it out. At some point you may see that in the change.log.x there is a reference from the file found in the restore to another file located else where. Now what all the other information in the file means who knows since MS does not divluge that information.

Now MS has a nice little tool in the %SYSTEMROOT%\system32\restore directory called srdiag.exe. What this program does is to parse the restore point directory and give you all kinds of information about your restore points. Now you are probably asking how this will help me since when I run srdiag it will only produce the reports (it creates a cab file with all the info stored in it) for the restore point on my analysis computer.

Here are the steps to get restore point information from an xp image that you are analyzing (do the following steps putting your information in replace of mine):

1. Make sure Restore Points have been turned on for your analysis machine.

2. Make sure you have access to your "System Restore Directory" - Use the following command to get the access cacls ":\System Volume Information" /E /G :F

3. On the xp image you are analyzing copy the restore point directory in the "System Volume Information" directory to the "System Volume Information" on your analysis machine. At this point you should see 2 directories like _restore. One will be your analysis machine guid and the other will be from the image.

4. You will now need to edit your registry. Go to the following entry HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SystemRestore\Cfg and rename the following field from MachineGuid to MachineGuid_old. Next create a new String Value of MachineGuid, edit this field and put the GUID that you copied from your image, use the MachineGuid_old as a template if you need to, the format of the 2 entries should be similar.

5. Now run the srdiag.exe from the %SYSTEMROOT%\system32\restore directory. Once the program has completed you should see a cab file with your machine name on it. In the cab file there will be all kinds of good information for you to look at.

6. Finally delete or rename the MachineGuid registry entry and rename the MachineGuid_old back to MachineGuid and remove the directory from your "System Volume Information" directory.

That is it in a nut shell. Enjoy looking at all the infromation provided to you by srdiag.

A New Beginning

Well he is my first post. I was reading Harlan Carveys lastest windowsir Blog post and took his advice and I am starting this blog. I know I do not have as much knowledge as others in the field and I am still constantly learning but who knows maybe I might be able to help one or two individuals, at least I hopefully get better at writing.

What I would like to accomplish with this blog is to pass along knowledge that either I or someone else has gained. If someone else passes the info along to me expect to get credit, if there is nothing more that I hate then people passing along an idea and not getting credit for it. I will try to post a couple times a week but will not make any promises.

How I came up with the title cfed-ttf. I was reading Jesse Kornblum's Blog's lastest entry about naming tools and had to come up with something so cfed is Computer Forensics/Electronic Discovery and ttf is Tips/Tricks and inFo. I tried to be creative but sometimes it is hard.

Now on to the show ( The reason we are here):

Ever wonder what hard drives have been attached to an xp machine. Well if restore points have been enabled then wonder no more. There is a file called drivetable.txt under the root restore point directory. This file contains a list of hard drives that are attached when the computer boots up (from what I can tell so far). Now the cool thing about this is that under each restore point directory there is also a copy of the drivetable.txt file at the time the restore point was taken. Now hopefully you can see where I am going with this. Since each restore point is a point in time you should be able to see when a hard drive was attached and not attached based on date/time of the restore and be able to create a time line of attached hard drives to the computer. This works with USB hard drives as well.

Feedback? Good or Bad who cares I know I am not always right and I will admit it. If I have to be wrong to learn something then I can eat a little humble pie.