EnScript to export selected search hits

This week I was working a case where I was reviewing hundreds of IIS web logs. I had done a keyword search for some unique patterns involving SQL injection. Once found, I want to export just those lines (IIS web logs are one entry per line). So I wrote a quick EnScript that basically exports one complete line that the keyword is found in.

The way the EnScript works is it seeks to the position in the file where your search hit is found, then it backs up until it finds a carrigae return/line feed, then exports from the next character after the CR/LF to the next CR/LF, thus exporting one complete line. This is the format of IIS web logs, but it could work with any text file that uses CR/LF at the end of a line.

To use, conduct your keyword search against any logfiles. Then SELECT (blue check) the search hits you want exported. You can select the whole search tree or just individual search hits, it's up to you. The following example is a screenshot of an old IIS web log:



Imagine you wanted to search through thousands of IIS web logs for the key word of "%5c" and you ended up with a couple hundred hits that you want to export out for reporting reasons or to put into an excel spreadsheet for analysis purposes. The next screeshot shows the search hits after the keyword search:



Select the keyword hits you want to export:



Run the EnScript and look in the default export folder for that case for a file named "searchhits.txt". You can import this into excel or use any text editor to see the exported data:



The result is a text file with only the lines that contain your selected search hits.

Download here

F-Response to the rescue!

A few weeks ago, I received an evaluation version of the new F-Response tool. Although I knew it was coming and I was excited to try it out, I received it while I was out of town and when I returned I was inundated with work and could not play with it immediately as I had hoped, so instead it sat in the shipping envelope in my car.

Last week, I was called by a company who has been the victim of the SQL injection attack. They were frantic and wanted help immediately. I saddled up and grabbed by response kit and met with the company. After getting all the particulars, I responded to the data center where there were two computers that needed to be imaged.

As I setup my gear, The system admin explained that their main back-end SQL server was tied to *everything* and there was no cluster or back-up server, so I could not shut the system down or even reboot it, as it would interrupt their business. I thought, no problem, I will image it live. As I looked at the Dell 2U rack server, I noticed one USB port on the front and two on the back. I collected volatile data and saved the data off to a small USB flash disk. I noticed that the volatile data collection was taking a lot longer than normal. I then asked how old the server was and if the USB was 2.0 or 1.1.....uh-oh.....1.1

I then examined the installed hard drives and found there were 5 SCSI hard drives making up a RAID 5 system. The operating system saw one physical disk, consisting of two logical partitions, totaling 1.1TB.

After he told me it was USB 1.1, I paused for a bit thinking through all the possible scenarios:

A. Use USB 1.1 and save the live image off to a removable USB hard drive
B. Insert a USB 2.0 card (required a reboot and this was not an option)
C. Insert a Firewire card (required a reboot and this was not an option)
D. Use netcat/cryptcat to throw the image across the network to another device
E. Use FTK imager and save the image to a network share.

I figured I would try option A and see how long the image would take. After setting everything up, I started FTK imager and it began to level out at 440 hours....hmmm...440/24 = 18.3 days... ouch!

So option A was out. After thinking a bit, I decided to use option F, F-Response! I remember that I had the package with me, but had not tried it out yet. I retrieved the package from my car and set up a VMware machine on my forensic laptop and went through the installation. I then tested it out using EnCase as the imaging platform and found it worked flawlessly.

I was still concerned about sending 1.1TB of data across the network wire that was actively being used by clients and the web server. After digging around a bit, I found a separate gigabit NIC adapter on the back of the server that was not being used, so I used a crossover cable connected directly to my laptop and statically setup some IP addresses. I then copied the F-Response client application to a flash disk and ran it on the target server. Two minutes later, I had a direct connection and the 1.1TB drive was showing up on my forensic laptop as a local drive. I started EnCase and previewed the drive. I started the imaging process using EnCase and it reported 30 hours until completion, much better than 18 days..;)

--fast forward-->

28 hours later the image was done. When the dust settled, I had an EnCase image file sitting on a Lacie 2 TB removable drive that was complete and verified correctly.

The F-Response setup process took all of about 5 minutes and was extremely easy. There is a very small learning curve in order to understand how it works. The best part of it is that it allows you to use whatever forensic platforms you normally use, the F-Response tool is not a forensic analysis tool itself, but instead is a type of conduit that connects remote hard drives to your local workstation so that your traditional tools can be used.

Hogfly posted a cool video of using F-Response here: http://forensicir.blogspot.com/2008/04/ripping-registry-live.html

Harlan also posted a blog about this tool here:
http://windowsir.blogspot.com/2008/05/f-response.html

There is also a great little demo video on how the tool works on the F-Response website: http://www.f-response.com/

If you have not seen this tool yet, I highly recommend you take advantage of their $100 trial version. Their field kit, consultant and enterprise versions are insanely priced compared to the price point of other forensic tools. Once you see or try this tool I think it will find a permanent home in your response kit, like mine has!

Summary report of file types by extension

I received a request from a friend asking if there was an easy way in EnCase to summarize all the file extensions and the number of files for each extension (like in FTK). Sounded like a useful EnScript.. ;)

The following EnScript will create a list of all the file extensions as EnCase sees them and then counts the number of files in each extension group. The output is printed to the CONSOLE tab. In addition, a file is created in the default export folder named "File Count by extension.csv" that can be opened in Excel for sorting and additional formatting.

Download Here

** I have posted the readable .EnScript version of this script as a learning exercise since this EnScript is pretty simple, easy to follow along and a good one to learn from.

Find duplicate files

This post is not really "forensic" related but it may have use to others...

If you are like me, you have several hard drives laying around that have all sorts of "stuff" on them. Things you have acquired over time and save with the thought that the information, programs or files may come in handy someday in the future. Then after I fill that drive up, I end up upgrading to a larger drive, but I don't want to delete anything in case I need it! After reviewing several of these drives, I found I had lots of duplicate files scattered throughout the drives in various folders.

My solution to this was to write an EnScript so that I could preview all my drives at once and then the EnScript will hash all the files and list all the duplicates for me. I can then decide if I want to manually delete the dupes or not. It also lists how much space is wasted by having all the dupes.

Most of my drives are formatted using NTFS. The NT file system has a feature called hard links. This basically allows you to have multiple directory entries for the same file, but it only takes up the space of one file. This is because all the directory entries can point to the same MFT record and the same data. For example, you can have a file named "lance mueller.doc" in a folder named "e:\documents\", and then have a file named "john smith.doc" in a folder named "e:\old stuff". There are two separate directory entries and the names don't even have to match, but they can point to the same exact MFT record number, and therefore to the same exact data, reducing the amount of spaces being wasted by having duplicates. Opening one of the files and editing it affects both directory entires.

I took the below listed EnScript one step further and actually have the EnScript locate an original file, then for all duplicates, it deletes the dupes and then creates a hardlink to the original file. This basically leaves the directory entry in place, but reduces the amount of space being wasted by pointing all the dupes to the same data as the original. I am not making that version of the EnScript available yet, but I am posting the EnScript that will list all the dupes in the console pane of EnCase and then you can decide what to do with the dupes.


Download Here