Monday, March 26, 2007

Acquiring a Forensic Copy of a Floppy Disk Checklist For Peer Review

Here is a checklist for Acquiring and Creating a Forensic Copy of a Floppy Diskette. It can be found here. Give it the once or twice over and let me know how it looks and if any changes should be made to the doc. Enjoy.



Over on Hogfly's Forensic Incident Response blog he has a great entry about peer reviews. I agree with everything he says and support it. One thing I was thinking about was by publishing this information you are letting every Tom, Dick and Harry have the information, they would then throw out there own shingle and state that they are a computer forensics professional because they know how to acquire a drive. Now this may be true but as you questions these individuals and talk to them at length you will then realize that they are no better then a 1st line of support. You know what I am talking about, you call support and they run you through every step you have also run through before calling them, that is why you are calling them. What I am getting at is the process/procedure is as only as good as the person who understands it and can explain it. After talking to some just going through the steps of the procedure you can ask why they did step 6. If you get the "Deer in the headlights" look you know you can question them further and that they do not understand the peer reviewed process that is published on the Internet. So I guess the previous line of thought should now be a moot point.

Now that Hogfly has thrown down the gauntlet I guess it is time to polish up those procedures and get a peer review or 2.


Tuesday, March 20, 2007

Remote Caputure Solution Posted On X-ways Capture Site

The solution I posted earlier about using X-Ways Capture for remote imaging has been posted on there site.

Monday, March 19, 2007

Mention on Cyberspeak

If you were listening to the end of Cyberspeak then you might have heard my company mentioned as well as this blog (not in name though, hopefully in a future podcast). Hopefully I can live up to keeping the topics flowing and providing information that is useful and helpful. As always any comments, tips, topics, help you may need are always welcome. You can reach me at mark[dot]mckinnon[at]sbcglobal[dot]net.

Thanks for the mention Bret and Ovie.


Reading Apache Access Logs

There are many scripts out there that read the Apache access log. More recently Jesse Kornblum posted his script for parsing the logs for search queries. Well here is my attempt at doing this, as always there is a database involved.

All this script does is read in the apache log file, parse it and save it to the database. You can then write sql to get back the data for you, IE:

select * from apache_log where access_dttm = '10/Mar/2007';

Now to run the program just type access_log. The program and table creates can be downloaded here.

For users of X-ways Forensics you can define this program as an external program and load the database right from x-ways as you are doing your analysis. Just make sure you change the spot where your database points to.


Tuesday, March 13, 2007

Your Local Public Library.

If you are not aware your local public library more then likely has software that you can check out and install (both kids software and adult software, not porn). One good thing about this is that you can create a virtual machine and install the software you checked out and start creating some hash sets. Some library's will probably have quite a list of software to check out. At my local library there are approx 30 titles for adult software and approx 50 children's titles and it is not a very large library. So happy hash set creation.


Monday, March 12, 2007

Imaging that remote PC/Server.....

So what better thing to do on a Monday morning then go through all the e-mails, blogs and news that has piled up this weekend, especially on a time change weekend. So I will try and keep this lite but I am sure it will raise questions. What I have for you today is a way I have found to do a remote image of a machine. The tools I will use are a simple batch file, Autoit, psexec and X-Ways Capture (Capture being the only non free tool but well worth the money). I will not go into very much detail about Capture except for just doing the image of the machine, it is worth looking at though as it has many features for live imaging and incident response as well.

I have uploaded a zip file with my autoit script and executable and a couple of batch files and it can be found here. What I do in a nut shell is psexec a batch file to the remote machine and execute it. I use the copy flag on psexec which copies the file to the machine to run it. From what I have tested, and I still need to do more but wanted to introduce this to everyone, this is what I have seen being changed:

1. Entry in $MFT for batch file and file stored in $MFT (file is only 111 bytes)
2. On Xp systems prefetch files are created for psexec.exe, batch file, capture.exe, net.exe.
3. Registry is updated.

Now for what I did. In the autoit script Remote_capture.exe I ask for the following fields to be filled in:

1. Remote computer's Name - Defaults to current machine name and will be name of machine to image.
2. Domain\Username - Domain (if any) and username to log onto, must be a administrator on that machine.
3. Password - Password of the account to login.
4. Capture Drive Mapping - Drive and unc path to where the capture software is.
5. Output Drive Mapping - Drive and unc path to where the output (image and logs) will go.
6. Capture executable directory - Directory on drive where X-Ways Capture Resides.
7. Capture output directory - Directory on drive where output will go.

There are 2 buttons to push, one is to show the mapped drives on the machine you are going to image which is helpful to make sure that you do not try and map the wrong drive, the other button is to start the process. Once all the information is filled in and you start the process here is what happens.

1. Batch file is executed to run psexec and pass it all the fields above as parameters which executes another batch file on the machine to acquire.
2. Batch file is copied to the remote machine and executed and does the following:

      1. Map the drive for the capture software.
     2. Map the drive for output to go to.
     3. Change directory to where the capture software is.
     4. Execute the X-Ways Capture and image the drive.
     5. Delete both drive mappings.

3. Batch file is executed to show drive mappings of the remote machine to show that they have been deleted.

That is it in a nut shell. I have tested this on a VM server, a remote pc and citrix and I have successfully imaged each machine and was able to import the image into X-Ways Forensics.

A few neat features of this are:

1. Autoit script and batch file can be give to administrator and shows that you are not doing anything out of the ordinary.
2. The passwords do not echo back so an administrator can type the password in for you so you do not need to know it (yes I know you can change the batch file to echo it but we have no need to do that).
3. When scripts run on remote machine no windows are opened and the only indication that anything is running is a couple of extra processes in the task manager and lots of disk activity.
4. If you really want to be slick you can rename the capture.exe program to svchost.exe (or something along that line) so if a user does look or the program abends it will look like a normal running program (I did abend the program and saw a error message pop up on the remote machine saying capture.exe abended).

Hope this helps. If it is not clear let me know and I will try and explain further.


Monday, March 5, 2007

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.


Friday, March 2, 2007

Autoit and Things to Come...

No I have not fallen off the face of the earth, between kids mid winter break (I don't remember this when I went to school) and work I have been a little busy. I have a few things I am working on which I hope you will like. In up coming posts I will chat about Remote Acquisitions, Offline Folders/CSC and anything else I can come up with or anything anyone else wants to mention. I am always looking for good topics to research and share with everyone. If you don't want to post a comment then just shoot me an email (mark dot mckinnon at sbcglobal dot net).

A colleague of mine showed me this nifty little free windows script automation tool called Autoit. It is pretty simple to use and you can make nice GUI front ends for many command line tools. It can be compiled into a stand alone executable and even comes with a editor and build environment. The biggest struggle I had was getting the screens formatted that I had created (my problem not that of the language), once I overcame that hurdle it is a pretty slick tool. You can easily provide a nice GUI wrapper for your command line programs to give them a more professional polished look. You can also make it easier for users who are not as command line savvy as others able to use the command line programs. In the near future I will have a sample program that I have written with Autoit.

Thinking out loud maybe one project for this would be a wrapper around Brian Carrier's Sleuth Kit. Since there is really no native port for Brian's Autopsy Forensic Browser for windows it might be a cool project to start.