EnScript to bookmark the MFT record of currently highlighted file in EnCase

I wrote this EnScript years ago and recently had a need to use it on some evidence. I realized I had not posted this before on the blog so I figured I would post it in case others had a similar need.

There are times when I want to look at the actual MFT record of a specific file. The most common reason is to look at the second set of timestamps that each MFT record has in the filename attribute. EnCase shows the first set (the ones in the Standard Information Attribute) in the table pane of EnCase, and normally that is sufficient. But there are times when I want to look a the second set of timestamps to see if the file's timestamps have been altered or to help establish whether a file was copied or moved onto the media. This EnScript simply looks up the corresponding MFT record for the currently highlighted file and then bookmarks it (all 1024 bytes of it):



Highlighting simply means to click on it in the table pane of EnCase (upper-right) and turn the entry blue, no need to highlight or sweep any data in the actual file. Once a file is highlighted, run the EnScript and you will get the following message:



Click "Ok" and then check your bookmarks:



You can then quickly inspect the actual raw MFT record to decode it manually or view any residual slack data, etc..

Download Here

Parse IIS FTP logs

I recently had an investigation involving the IIS FTP service. It involved an unauthorized person getting access to a specific user account and then being able to login via the FTP server and download several confidential files.

When reviewing the FTP logs, which had numerous legitimate logins everyday, I found an immediate need to isolate the logins of the specific compromised user account. I could easily do this using a keyword search, but then found a lot of the FTP log information was co-mingled with legitimate FTP traffic, making it hard to follow. I decided to write an EnScript that parsed the FTP logs and broke out each FTP session into its own log file.

The IIS FTP log is similar to the IIS web log, except not nearly as verbose. There are several defined fields that look like this:

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2005-10-29 17:04:39
#Fields: time c-ip cs-method cs-uri-stem sc-status
17:04:39 192.168.11.173 [1]USER anonymous 331
17:04:39 192.168.11.173 [1]PASS guest@unknown 230
17:04:46 192.168.11.173 [1]QUIT - 257
17:04:49 192.168.11.173 [2]USER anonymous 331
17:04:49 192.168.11.173 [2]PASS guest@unknown 230
17:10:51 192.168.11.173 [2]QUIT - 257
17:10:54 192.168.11.173 [3]USER anonymous 331
17:10:54 192.168.11.173 [3]PASS guest@unknown 230
17:11:33 192.168.11.173 [3]closed - 426

There are a couple of important pieces of information contained in each line:
1. Timestamp
2. Source IP address
3. Session number
4. FTP command
5. FTP result code

Using the session number (the number in the brackets) the EnScript parses through the file and pulls out all the associated log entries for each specific session and writes it to new file. For my specific purpose, it made things much easier. The EnScript will write out each session and name the new file with the session number, combined with the original filename that the entry came from and also the user account the specific FTP session is concerning, if it can be determined.

Using the IIS FTP log quoted above, and then selecting the log file and running the EnScript, the following files are created in the default export folder for the case:



The contents of each file is the FTP activity for that specific session:

17:04:49 192.168.11.173 [2]USER anonymous 331
17:04:49 192.168.11.173 [2]PASS guest@unknown 230
17:10:51 192.168.11.173 [2]QUIT - 257

By sorting and looking at the naming convention of each file, I could then quickly look at the FTP activity for the compromised user account and I could quickly identify large amounts of activity by the size of each log.

Hopefully, someone else has a use for it as well.

Download Here

Search for keyword in selected file(s) and then parse till double CRLF

A friend contacted me this past week about a problem he was having parsing a large amount of data in unallocated. He had been searching for specific data that used to be in a text file and had since been deleted, but was still in unallocated. The data had a pretty logical structure, something like this:

label1:field1 label2:field2 label3:field3
label4:field4 label5:field5 label6:field6

label1:field1 label2:field2 label3:field3
label4:field4 label5:field5 label6:field6

.....

He wanted to parse out the data back into a text file so he could process it some more, but it needed to be one complete record per line. I wrote an EnScript that asks for a keyword. The keyword should be a unique keyword, that in this case was the text "label1" found at the begining of each record. The EnScript then parses from the keyword hit until it reaches a double CRLF. It then prints out the parsed data on one line to the Console tab.

Here is an example of the text in text view within EnCase:



So in this example, you would run the EnScript and enter a unique keyword that is found at the begining of each line, in this case "label1" appears at the beginning of each line and the EnScript will parse from the keyword hit until a double CRLF is encountered.



The result looks like this in the console tab:



I figured I would post the EnScript in case anyone else has a use for it.

Download Here

EnScript to parse USNJRNL

* UPDATED (11/29/08) - v1.1 - Improved parsing of large USNJRNL files
* UPDATED (03/17/10) - v1.2 -  Added export to CSV functionality

The USNJRNL is a file system transaction log and it is located in the $EXTEND folder of a NTFS volume. This file system feature is available in Windows XP and greater but is disabled in XP by default. In Vista this feature is enabled by default.

The file system journals changes to files into this log, even if the data itself in the file is not changed, but rather changes to the metadata to the specific file.

The USNJRNL consists of one main file and two alternate data streams. The structure of the data in the USNJRNL•$J (as displayed in EnCase) file is pretty straight forward and is detailed below:

Offset(in hex) Size Description
0x00 4 Size of entry
0x04 2 Major Version
0x06 2 Minor Version
0x08 8 MFT Reference
0x10 8 Parent MFT Reference
0x18 8 Offset of this entry in $J
0x20 8 Timestamp
0x28 4 Reason (see table below)
0x2B 4 SourceInfo (see table below)
0x30 4 SecurityID
0x34 4 FileAttributes
0x38 2 Size of filename (in bytes)
0x3A 2 Offset to filename
0x3C V Filename
V+0x3C P Padding (align to 8 bytes)

The following EnScript parses the USNJRNL•$J file and displays the filename, timestamp and reason code to the console tab of EnCase and to a CSV file in the default export folder.

A definition of the reason codes are as follows:

Flag Description
0x01 Data in one or more named data streams for the file was overwritten.
0x02 The file or directory was added to.
0x04 The file or directory was truncated.
0x10 Data in one or more named data streams for the file was overwritten.
0x20 One or more named data streams for the file were added to.
0x40 One or more named data streams for the file was truncated.
0x100 The file or directory was created for the first time.
0x200 The file or directory was deleted.
0x400 The user made a change to the file's or directory's extended attributes. These NTFS attributes are not accessible to Windows-based applications.
0x800 A change was made in the access rights to the file or directory.
0x1000 The file or directory was renamed, and the file name in this structure is the previous name.
0x2000 The file or directory was renamed, and the file name in this structure is the new name.
0x4000 A user changed the FILE_ATTRIBUTE_NOT_CONTENT_INDEXED attribute. That is, the user changed the file or directory from one that can be content indexed to one that cannot, or vice versa.
0x8000 A user has either changed one or more file or directory attributes or one or more time stamps.
0x10000 An NTFS hard link was added to or removed from the file or directory
0x20000 The compression state of the file or directory was changed from or to compressed.
0x40000 The file or directory was encrypted or decrypted.
0x80000 The object identifier of the file or directory was changed.
0x100000 The reparse point contained in the file or directory was changed, or a reparse point was added to or deleted from the file or directory.
0x200000 A named stream has been added to or removed from the file, or a named stream has been renamed.
0x80000000 The file or directory was closed.

(http://msdn.microsoft.com/en-us/library/aa365722(VS.85).aspx)

Download Here v1.0
Download Here v1.1
Download Here v1.2