EnScript to Export files based on Extension v1.1

A few days ago I posted a blog about a new EnScript I wrote based on a reader's suggestion here.

I have updated this EnScript based on a suggestion from Iain Kenny & Jerry Hatchett to add the feature to de-duplicate exported files based on the hash values. The initial screen now has a check box to perform de-duplication by hash values:



If you check this box, the EnScript will hash every file it exports and if any additional files match the hash values of previous files, the contents will not be exported. Instead, the duplicate file will be created, but the contents will contain the text "DUPLICATE" as well as the path of the ORIGINAL file with the same hash.



The log file "index.csv" will also indicate each file that is a duplicate and list the hash values for all the files.



Download v1.1 Here

EnScript to Export files by extension

A fellow examiner emailed me asking if I could write an EnScript that could be used to quickly export all the existing files in the evidence based just on their file extensions. This would typically be used for eDiscovery type cases.

Below is an EnScript that when run, will present a window asking for two pieces of information. The first is the export folder where you want the files exported to. The second is all the extensions you want to use as the criteria to export the files. You can copy and paste whatever extensions you wish, comma separated:



The EnScript will export all the files with matching extensions (case insensitive) to the folder you specify. A subfolder for each extension is made and the corresponding files are placed into their respective folders:



An index.csv file is made that contains a listing of every file that was exported along with its original path in the evidence and the exported filename. A unique number is appended to each exported file to ensure uniqueness and to avoid one file with the same name as another from overwriting it.




Download Here

SANS Forensics and Incident Response Summit 2009

For those of you that have not heard about the upcoming SANS Forensics and Incident Response Summit in Washington D.C. in July, you should really try and attend. I had originally planned on attending and was kindly asked by Rob Lee to participate in the forensic tool panel discussions, but unfortunately my schedule is now preventing me from attending.

This year's summit looks even better than the last one in Las Vegas, which was great. The speaker lineup looks awesome and I am sure it will prove to be very interesting. If you are anywhere near Washington D.C. July 6th-9th, or can get there, I highly recommend you try and go. If you do, take notes for me.. ;)

You can read more about the agenda here:
https://blogs.sans.org/computer-forensics/2009/04/07/agenda-released-forensics-and-incident-response-summit-2009/

Article on renaming files to hide them

I ran across an article in a popular Thai magazine named "Computer Today" (http://www.ctmthailand.com) that I found interesting. I don't read Thai, but I was browsing through it looking at the pictures and saw a picture of a file called "my secret.txt" and then it was renamed to "my.sys", so it caught my attention and I was curious what they were teaching.





I had the article translated and it is basically an article on how to hide data by renaming a file that you want to keep from prying eyes to something like "my.sys" and placing it in an obscure folder like the Windows folder.

Nothing earth shatering here about this technique, but I found it very interesting to find an article like this is a mainstream published magazine and it just reinforces why we go through the trouble of file signature analysis, hash analysis, keyword searching & metadata analysis.

File System creation date vs. Operating System install date - Part I

I have recently seen a few listserv messages regarding determining when the Operating System was installed. This post focuses on the two common sources of date/times that can be somewhat misleading.

Two areas that are commonly looked at on a Windows installation are the MACE times for the internal NTFS objects, like $MFT, $MFTMirr, $LogFile, etc. which are all the same and then the OS install date registry value under: HKLM\Software\Microsoft\Windows NT\CurrentVersion\InstallDate

Lets clarify something first. One is the file system creation date and the other is the operating system install date. Remember that file systems and operating systems are two totally different things, with different purposes. Let talk through a common example:

An average home user buys a new hard drive and wants to install Windows XP. After the afternoon job of installing the hard drive, he pops in the Windows XP SP3 install disk and powers up the computer. Soon the user will be asked where to install Windows XP and in this common example, where to create the partition and file system. The common screen looks like this:



The user is sitting in California and the computer clock is set to the -8 GMT timezone, AKA: Pacific Standard Time, but the date is currently May 27th, 2009, meaning the region is currently in daylight saving time (-7 GMT). The time is currently 6:38 p.m. (GMT time is 1:38 a.m. on May 28th).

After seeing the blue screen shown above, the user hits enter and the NT file system is created. After the setup program copies the necessary setup files to the newly created volume, setup continues and the computer reboots. Approximately an hour later, the installation of the operating system is completed and the shiny new XP installation is done. The time is 7:53 p.m.

Now lets imagine at this moment that the local police swarm the house and seize the computer. A forensic examination is done the next day. What will the examiner find?

Lets think this trough for a moment. The user popped in a XP install CD and installed a fresh version of XP. The file system creation date/time was when that blue screen appeared and then an hour later the installation was done and Windows was ready for use. The OS Install date/time was approximately one hour after the file system creation time. The examiner should expect to see approximately one hour gap between these two dates and times, right?...right??

Back to the scenario: Investigators interview the user and he explains that he went to the local computer store at approximately noon and purchased a brand new 500GB hard drive. He then stopped for lunch and did some unrelated shopping before getting home. The football game was on, so he watched that for 3 hours before finally getting around to installing the hard drive and beginning the installation around 6:30pm.

The examiner uses EnCase and looks at the creation time for the $MFT and it shows this:



The examiner shouts the highly technical term "WTF" ?? The user must be lying. The examiner then checks the registry value for the install date and it shows:



What is going on here? Why aren't these two timestamps lining up the way we would expect? Here is where the misleading part is. The user started the installation at around 6:30p.m. The file system *WAS* created at 6:38p.m. Here is the problem. The system was started from the Windows install CD. Since there is no Operating System installed yet, the computer and installation program have no reference to a timezone yet, all it has is a date/time from the BIOS. The Windows install program uses the BIOS time as the local time, much the way older file systems did, like FAT with Windows 9x. The install program grabbed the time from the BIOS (6:38PM) and used that date/time.

Later, when examined, EnCase is expecting that this timestamp is stored in GMT and automatically applies a timezone shift of -7, because that's were the examiner's machine is set to. So what was stored was the actual local time of 6:38 p.m., but EnCase now displays that as 11:38a.m. since it thinks all timestamps are being stored by the file system in GMT.





The install date in the registry is correct a that was the time the installation completed and that is stored GMT since the operating system is fully installed and has a reference to the correct timezone and where GMT is in relation to the BIOS date/time.

As with all date/time issues, an examiner must be very careful *NOT* to rely on that information as the sole indicator of an event. This example just reinforces that issue and that the date/time you expect to find might not be what you actually find because of the way an application handles it.

The above scenario has been tested in all versions of Windows XP, SP1-3.

Having the above information in mind, if you took a new USB flash device and formatted it in Windows XP with the NT file system, what would you expect to be stored as the created date/time for the file system? your localtime or GMT?

Harvest Keywords EnScript

This is a follow-up to the post I made on April 28 regarding the "Maine State Police - Keyword Search" EnScript.

This EnScript harvests keywords from selected files in EnCase. If you have a collection of contraband images, movies or whatever, you can load them into EnCase and then use this EnScript to generate a keyword list from a specific offset in each file. The original concept is to extract a unique keyword from somewhere in the middle of each contraband file to be used to positively identify it. Avoid using generic locations such at the header, which would get you hits of that file type, but they may not be contraband. The concept relies on the fact that you have a keyword from the original contraband file(s) that you can use to generate the keyword list (a kind of unique signature), then the original "Main State Police - Keyword Search" EnScript searches each cluster, in just the offset your keyword was harvested from to help reduce the time it takes and positively identify contraband, reducing the need to review every hit.

To use, just blue-check whatever files you wish to harvest keywords from:



Once selected, run the EnScript and pick the offset and size of the keyword. The longer the keyword harvested, the more unique and less chance of false positive hits.



A text file is created with whatever name you specify and the Length (LEN) and Offset (OFF) are appended to the filename, as well as the date and time to avoid accidentally overwriting an existing keyword list:



The list of keywords generated are displayed in the Console Tab of EnCase and can be viewed with notepad:





The generated keyword list can then be used with the EnScript posted on April 28th.

Download here

Maine State Police - Keyword Search & Export EnScript

Maine State Police Keyword Search and export EnScript – v1.0
April 28, 2009
EnCase v 6.13

This post is an update to a previous post here. This is an updated EnScript with new features and an official v1.0 project release. The following description is from the instruction document in the zip file linked below.

1. Introduction

This EnScript was born out of a concept from Sgt. Glenn Lang with the Maine State Police. Sgt. Lang needed a way to quickly and effectively identify known multimedia files that are commonly possessed by persons trafficking and possessing child pornography.

2. How it works

Sgt. Lang had an application named "harvester" written for the purposes of extracting a 10-byte string of hex values from inside any file. The thought was that instead of relying on file headers, to instead grab 10 hex values from the middle of a known video file or graphic file as a "mini" known signature for that specific file. The "harvester" program creates a simple text file with one 10-byte keyword per line (CRLF delimited). Investigators can use the "harvester" program to scan all their known bad media files and extract a mini "signature" for each of them, placing them into a small text file.

This EnScript was designed to read the text file created by "harvester" (or by any other means) and then begins searching the disk for those keywords. TheEnScript was designed to work in two ways. The first way is to search unallocated space, the second it to search all areas of the disk(s) (allocated files and unallocated clusters).

3. Configuration

When you start the EnScript, the investigator is presented with the following initial screen :



A. The first option asks for the text file where the keywords are stored. This text file should be a simple ASCII text file, one 10-byte keyword per line, in the format of:



B. This is the offset into the known file where the keyword was harvested from. The EnScript will search and export using this offset.

C. Total size of export - When a keyword is found, the EnScript will back up “x” bytes, as dictated by the offset value described above. The EnScript will then export from that offset (presumably the beginning of the file) for a total of “x” megabytes, as indicated by this value.

D. File Extension - When a keyword is found and the data around the keyword is exported (as described above), the exported data will be placed into the case default export folder and given the extension as indicated by this value. This is so if the investigator is searching for movie files and the data is carved from unallocated space into the default export folder, the investigator can quickly double click and use a viewer, such as VLC, to view the contents.

E. Comprehensive search - This checkbox dictates how the EnScript will search for the keywords. The normal built-in keyword search process in EnCase searches every byte of the disk (or unallocated cluster object). This EnScript, in an effort to speed this process up, by default, will search for the keyword only at the specified offset of each cluster, then move to the next cluster and look at the specific offset in that cluster and then move again to the next cluster. A typical Windows installation uses the NTFS file system and defaults to a cluster size of 4096 bytes (8 sectors per cluster). This means you are only searching 10 bytes out of those 4096 bytes, effectively only .2% of a cluster. The purpose of this is speed. If you think about how a file will always be saved on disk starting at a cluster boundary, then the keyword your looking for will always be found at the offset you specified in option B into a cluster. Searching the other areas of the cluster is unnecessary.

By checking this box (comprehensive search), the EnScript will instead search every sector. The reason for this option is in case the target drive had some files you are searching for and then the volume was formatted at some point in the past. The formatting process may inadvertently either change the number of sectors per cluster (i.e. was FAT, now is NTFS) or the boundaries of the volume have changed. Therefore, by selecting this option, the EnScript will search for the 10-byte keyword at a specific place in the sector, then move to the next sector and search again at the specific offset. This will increase the amount of time it takes to complete the search, but is still faster than a traditional keyword search where every byte of every sector is searched.

F. Bookmark - This will cause the specific keyword hit to be bookmarked when it found. Check in the bookmarks folder for a folder named “Found keywords in Unallocated – DATE & TIME”.

G. Search all files - The default is for this EnScript to only search unallocated space for the supplied keywords. Checking this box forces the EnScript to search unallocated, as well as every file in the case (allocated files).

4. Console - Real-time information is displayed in the console as the EnScript is running. If a keyword is found, the offset as well as full path of the file of where it was found is displayed.



5. Alert Sound - The EnScript will automatically check for the presence of a .wav file named "alarm.wav" in the “C:\Program Files\EnCase6\” root folder. If this file exists, this .wav file will be played every time a keyword is found during the search process. If the .wav file does not exist, the alert sound function will be skipped, but real-time information is still displayed in the console tab of EnCase.

Project information:
Sgt. Glenn Lang, Maine State Police
glang (at) mcctf.org

Download Here

Keyword List

Video demonstration #1
Video Demonstration #2

Filter to remove duplicates for export

A reader emailed me about needing a solution to remove some duplicates to then export some files. The scenario was that a keyword search was run and thousands of files were found that were responsive to the keywords. The reader tagged the files and then found that some of the files were duplicates, even though they were named or located in different places on the evidence. So to reduce the number of files that needed to be exported, he needed a way to remove the duplicate files.

EnCase comes with a standard filter that is named "remove duplicates by hash". This filter does exactly what he needed, except it did it against all files. He only wanted to remove the duplicates from the selected files. By adding one quick line, the following filter will remove duplicate files, based on the hash value, of the SELECTED files. So if you have 100 selected files and some of those files have the same hash value and then run this filter, what will be left will be only unique selected files.

You can create a new filter and paste the following code:

--------cut here------------

class MainClass {
NameListClass HashList;
bool UserCancel;

MainClass() :
HashList()
{
if (SystemClass::CANCEL ==
SystemClass::Message(SystemClass::ICONINFORMATION |
SystemClass::MBOKCANCEL, "Unique Files By Hash",
"Note:\nFiles must be hashed prior to running this filter."))
UserCancel = true;
}
bool Main(EntryClass entry) {

if (UserCancel)
return false;

if (entry.IsSelected()){
HashClass hash = entry.HashValue();
if (!HashList.Find(hash))
new NameListClass(HashList, hash);
else
return false;

return true;
}
else
return false;
}
}
------------------ cut here----------------

EnScript to obtain DHCP and Static IP Address information

Per a reader's request, here is an EnScript that will recurse through all evidence in a case and parse the SYSTEM registry hive located in the \system32\config folder. It will then display any DHCP or static IP address information for all the interfaces found in the SYSTEM registry hive.

The EnScript will also parse any SYSTEM registry hives found in the XP System Restore Points (System Volume Information Folder - "_REGISTRY_MACHINE_SYSTEM") and display those as well. This EnScript is compatible with Windows 2000/XP/Vista/2003.

All output is in the console tab for review. Example of output:
Reading file: Case 1\Fiske\C\System Volume Information\_restore{F7B7E177-A202-4882-ADC2-D0A88A676F63}\RP3\snapshot\_REGISTRY_MACHINE_SYSTEM

Interface GUID: {FA987DAF-1C7E-40E2-B570-8EBF1FFFA371}
IPAddress: 0.0.0.0
DhcpServer: 192.168.1.1
Lease: 86400 seconds
LeaseObtainedTime: 08/22/03 08:25:45PM
LeaseTerminatesTime: 08/23/03 08:25:45PM
DhcpIPAddress: 192.168.1.101

Reading file: Case 1\Fiske\C\System Volume Information\_restore{F7B7E177-A202-4882-ADC2-D0A88A676F63}\RP4\snapshot\_REGISTRY_MACHINE_SYSTEM

Interface GUID: {2AF8F12B-22F6-4FAE-974D-564BA481D3FF}
IPAddress: 0.0.0.0

Interface GUID: {FA987DAF-1C7E-40E2-B570-8EBF1FFFA371}
IPAddress: 0.0.0.0
DhcpServer: 67.21.13.74
Lease: 43200 seconds
LeaseObtainedTime: 10/08/03 08:56:49AM
LeaseTerminatesTime: 10/08/03 08:56:49PM
DhcpIPAddress: 68.66.201.16

Download Here

Count unique domains in email list

This EnScript was written by request for someone doing an email spam case and he needed to parse a large list of email addresses and then extract only the unique domain names.

So in this case, he had a very large ASCII file containing thousands and thousands of email addresses, some of which came from the same organization and had the same domain, but different email address. He needed a way to just create a list of just the unique domain names. This EnScript takes an ASCII file, with one email per line, line-delimited with a CRLF like this:

john@test.com
dave@test.com
steve@test.com
mike@mydomain.com
tom@mydomain.com
joe@mydomain.com
etc...etc...etc...



The output of the EnScript in the CONSOLE tab would be:

test.com (2)
mydomain.com (3)

This is a pretty specialized EnScript, but others may have a use for it as well.

Download Here

Recovering video files in unallocated space

Recently, Sgt. Glenn Lang from the Maine State Police contacted me regarding an EnScript request designed to export some data from keyword hits where he was searching for movie files in unallocated. Sgt. Lang is the ICAC coordinator and does a lot of child exploitation investigations. He has had great success in building some excellent GREP keywords to find movie files in unallocated.

The GREP keywords are usually characters that are located at various offsets inside the video files, not at the beginning. He needed a way to quickly export the suspected video files and view them.

By modifying the previous "export x bytes from a search hit" EnScript, I created an EnScript that will export x bytes in front of the keyword hit and then specify the total number of bytes to export:



It then saves the data into a file named after the original filename where the hit was found (usually unallocated) the search term, the offsets and then you can specify a extension for the export:



You can then double-click and use your registred viewer to view (vlc in this example).

Sgt. Lang has put together some basic videos demonstrating this technique and they can be viewed here:

Adding keywords and starting a search.wmv
Recovering Movies Located Using Harvester Key Words.wmv

Download GREP keyword list here (Import into EnCase Keyword tab)
Download EnScript here

Export files with selected search hits

So this EnScript was a suggestion from a reader named Scott (you know who you are). The premise behind this is many times examiners are asked to run several keywords (sometimes hundreds) then export the files here the keyword were found and produce them for review.

This EnScript automates the export process by allowing you to select the search hits in the "Search Hit" tab and then running the EnScript. It will then go through all the selected search hits and export all the files that contain those search hits into folders named after the keyword. For example, if I searched for "lance", "mueller" and "lance mueller",and selected the root of each one of these search hit results in the Search Hit tab, a root folder named "Exported Search Hits - 04.07.09 07.24.29AM" will be created in the default export folder specified for the case. Inside this folder will be subfolder for each keyword: "lance", "mueller" and "lance mueller".



Inside each of these folders will be all the files that contain that specific keyword. An index file is created in the root folder that specifies the keyword, hit offset, original path of the file in the evidence and the new path of that file in the export folder tree.





In the example below, if you select the "enscript" and/or "\e\n\s\c\r\i\p\t" search hits, two folders would be created will all the files that contain those keywords.



A few comments:
1. Duplicates - If a keyword such as "lance mueller" is found in several locations in a particular file, it is only exported once into that specific keyword folder. If the file ALSO contains another keyword, then it will also be exported once into the folder for that keyword. If a keyword is found in multiple locations in the sam file, it is only exported once, but all the hits and offsets are referenced in the index. The last column will indicate the file was previous exported, but the hit offseet will reference the current hit.



2. File naming - The exported files have a number appended to the original filename to prevent multiple files that have the same name, but reside in different locations in the evidence to be exported into the same export folder and overwrite themselves. A number is places at the end of the name stem, before the extent ion. The original name and path is noted in the index file with the corresponding new name as it exists in the export folder.

3. GREP searches - keywords that are used that contain illegal directory name characters, i.e. /,\.:, etc. are stripped and replaced with a bullet: "·"
The original keyword is specified in the index file.

Download here

Amazon's Kindle

This post is kind of off-track from my normal posts, but I figured I would follow-up and explain my use of the Kindle. I recently had a conversation with Harlan Carvey about the Amazon Kindle, as the 2nd edition of his Windows Forensic Analysis book is coming out soon and I was asking him if the publisher planned on releasing it in the Kindle format.



For those of you who are not familiar with the Kindle, it is basically a eBook reader. You can read more about it at Amazon's site here. This is the coolest little device. I am not really a book reader, other than technical books. I don't really read fiction or other non-technical publications, but I had a friend who had the first generation Kindle and he showed it to me, and I was impressed. I quickly envisioned how I could load it up with technical books to read on planes. As it turns out, after loading it up, I have used it more at client sites or when talking to people about forensics than reading on planes, and that says a lot since I am on planes a lot! ;)

So basically, I load the thing up with technical books and it has a bookmark and search function. When I come across a section that is important or I feel I will need to later reference, I can bookmark it and then later get back to it quickly, without needing to remember where it was or what book it was in. I also wanted to mention that the Kindle has the ability to subscribe to blogs, magazines and newspapers. Everyday the Kindle can download your favorite blog, newspaper or magazine (if available through their service) and have it delivered to your Kindle. How is it delivered? That is the coolest part! Amazon has an arrangement with Sprint to supply free cellular data service to the Kindle. The Kindle has a built in radio that communicates on the Sprint network anywhere in the US. Best of all, its free, you don't pay anything other than the initial purchase price for the device! You can open a limited web browser on the device and browse books, magazines or blogs and then buy them right then and there, and then they are downloaded via the cellular network within about 60 seconds, all free (other than the purchase price for the book, which is much lower than the print version).

The Kindle v2 came out at the end of February. It holds even more books (1500) and is even smaller. It has its own email address that you can send PDFs or other documents to the device through its cellular data connection and then read it on the device at your leisure. It also has a usb connection that the device shows up in Windows and Mac as an external storage device. So you can download books via your computer and load them onto the device that way.

I travel A LOT. I have been out of the country since January. When I received the new Kindle, I was out of the country and the website says the cellular data connection does not work, therefore you will have difficulty loading ebooks onto the reader. Well, following the instructions here, I am able to connect the Kindle to my laptop and then have it use my laptops internet connection to get the books, blogs and newspapers I subscribe to. Not as convenient as having it done everyday automatically via the Cellular connection, but it works while I am overseas!

So for those of you who are regular book worms or like to have a full library of technical books, I cannot recommend it enough. As Harlan mentioned on this blog post earlier today, On Amazon's site when you view a book, there is a link that says "Tell the publisher" you want it available on the Kindle if its not already available. Right now, there about about 30% of the technical forensic books available via the Kindle. Hopefully as more people use it and tell publishers they want the book in the Kindle format, more books will become available. Just from a price point perspective, it pays for itself after a dozen books or so. Take the "File System Forensic Analysis" book for example, by Brian Carrier. you can buy the printed version from Amazon for $54.99 or the Kindle version for $34.01, thats a 43% savings! So take that $25 savings, multiple it times a dozen books and you have paid for the device. With its search and bookmarking capabilities, it makes it a absolutely necessity for work/reference, and thats exactly what I am gonna tell the IRS when I claim it as a business expense! ;)

Stay tuned, forensics of the Kindle is coming soon! ;)

For those that can't wait, here is a peek:

Detecting timestamp changing utilities

Harlan Carvey recently posted an update on his blog, and he included a link on Time based forensics and it reminded me about a post I wanted to make.

I was just working a case this past week where I ran into some "anti-forensics". Now, some of you know my position on "anti-forensics" and the soapbox I usually climb onto when that word gets brought up. I am not really a subscriber to the word "anti-forensics". There are certainly tools that attempt to make it more difficult to detect wrongdoing, but "anti-forensics"? c'mon.. Anyway I digress….

So in this case, I ran into an attacker who changed some timestamps on some executables to try and hide their presence. The attacker placed the executables in a system folder and named them very similar to legitimate executables (mistake #1). The attacker then used a utility to change the timestamps of the executables to show a creation date in 2001 (mistake #2 & #3). So this is more an "anti-sysadmin" technique than anti-forensics.

As most of you are aware, the $MFT tracks (4) four datestamps, created, accessed, written & entry modified. There are at least two places in each MFT record that that contains these stamps, the Standard Information Attribute (SIA) & the Filename Attribute (FNA). The timestamps from the SIA are the ones EnCase (and all other tools) shows you in the table pane (upper-right). The second set is somewhat redundant. All four timestamps in the FNA are typically stamped with the same date/time that refers to when the file is created on that volume. There are undocumented circumstances as to when the timestamps in the FNA are changed; the most notable one is renaming a file. Anyway, absent those circumstances, when you look at an MFT record of a file, you will typically see the creation date of that file on that volume in the standard place (SIA) and it will be displayed to you in the created column in EnCase. An exception to this is when you CUT and PASTE (aka move) a file from one volume to another. The creation date on the original volume “sticks” and is also used on the new volume. But when a file is copied (aka downloaded, pushed, transferred, etc.) the creation date on that new volume will reflect the date it was copied. This is nothing new and the standard caveats apply here).

Now, when that file lands on the new volume, that second set of timestamps are also initialized with the date it was copied onto the volume. The attacker, trying to by sly, thinks he will change the timestamps so it "blends" in with other files, so he/she uses a tool to alter the timestamps, like "stamp", "filetouch", "timestomp" or any of the other timestamp modifying tools. The tool changes whatever timestamp you want; created, accessed, written or entry modified. But the tool only changes the timestamps in the SIA, not the FNA.

What you have now is what we call a "BIG RED FLAG". You now have a creation timestamp in the SIA that predates the one in the FNA, how is that possible? Now, there are times when this can occur naturally without any malice. The most common is when the file was contained in an archive that preserves the original datestamps. Microsoft CABS are one of those types of archives that can do this so you have to look at the file(s) carefully and the surrounding files to assess "is this normal?".

I did a presentation on this topic a few years ago at the DOD cyber conference. Here are two screenshots that show examples:





Below is an EnScript that will bookmark the timestamps from the SIA and FNA and also write to the console just the created dates for a quick compare. Select whatever files you want the two sets of timestamps from and then run this EnScript, then check the bookmarks:



You can see in the example above that the first set is from the SIA and reference dates in 2006. The second set all show January 15, 2009. This is actually the date this file was created on the volume. In this case I used "filetouch" to set the timestamps back.

Download EnScript here

* Comments on mistakes:

#1 - system folder? This has got to be the first place any forensic examiner will look? how about something interesting? System Volume Information?

#2 - 2001? How many files on a Windows 2003 server have a creation date of 2001???

#3 - setting the timestamp back in the first place. The proceedure I describe above clearly shows the alteration. Hiding in plain sight is a better tactic.

Windows Event logs

In the past when I have had a need to parse Windows Event logs, I would usually use the built-in EnScript (case processor) or use the native Windows event log viewer (eventvwr). The latter does not work exceptionally well when you have fifty machines to look at. The following discussion and ideas are things that have worked for me in the past and some of the problems I have encountered. This discussion only applies to the traditional Windows event logs and not the BXML format used by Vista and new Microsoft Operating Systems.

The current version of the EnCase case processor script includes a module to parse Windows event logs. In the past, I have relied on this to parse many event logs. Currently, it seems to have some problems that cause it to fail to properly finish processing the event log files. It either hangs and never completes or crashes on some of my event logs.

Harlan Carvey recently released a Perl module named Readevt.pm that can be used to parse Windows event logs using that perl module. he has made it available through his CPAN directory here. Using this module, you can list all the event and even customize your own perl script to parse multiple evt logs and output the data into whatever format you wish. The nice thing about this Perl module is it is can be used on any platform that supports Perl.

Mark McKinnon took this one step further in a post here that describes how to use Harlan's Perl module and a perl script to parse all the windows event logs and then dump them into a SQLite database. I have used this method as well and it is very handy when you have many logfiles and want to run different queries against all of them. The method Mark describes is very simple and straight forward and it works very well.

Harlan is soon to release a version that parses out the event logs to XLS spreadsheets (watch for it in his WFA 2nd edition). This option also works very well and creates a nice uniform output format that can be viewed by just about anyone. The only limitation I ran into here were event logs that generated more rows than the 65k row limit in Excel. You may need to download some required Perl modules to make this method work, but it's fairly simple and hassle free.

A quick shell script such as the one below and it will go through and parse as many .evt files as you need and kick out a corresponding XLS spreadsheet for each event log.

for file in `find . -type f -iname '*.evt' -maxdepth 10 -print 2>/dev/null`
do
echo $file
perl ./evt2xls.pl -e $file -o $file.xls
done

In my case, I had 50+ machines, each with at least three event logs, some with more. Each machine had its own directory, so the shell script above recursed each directory parsed all the evt files and left the XLS spreadsheet with the same name as the original, in the same directory as the .evt file.

All of the above options parse the event logs in a 'dead' static state. While this is okay, there are some things you can potentially miss, most are contextual when using the above descibed method(s).

Windows event log entries contain references to messages and other important information that is pulled from .dll files and other sources when the system is running and the event log is viewed. So when looking at an event log entry using the techniques above, you may see the text "PSKILL" in the message field, and that it. If you were to actually look at that event in event viewer, it would parse that event fully and you would actually see other text in the message such as:

"The PSKILL service was successfully sent a start control"

Not this may seem subtle, but context is everything. So I find myself using the techniques above to help me locate log entries of interest, then viewing them in the windows event viewer application so I can make sure and see them in their native format.

Commonly, you will run into the the dreaded "corrupted windows event log" problem when trying to view an exported event log in the Windows event viewer. This is most commonly caused by imaging the system while live, or shutting the system down hard (pulling the plug) before imaging. There is a roaming header that is changed when the event logging system is active, and then changed again with the system is shutdown.

There is a pretty easy way to fix the corrupted logs with a simple hex editor, but again with 50+ machines, totaling over 150+ event logs, that did not seem appealing to me. So below is an EnScript that you can use to select (blue-check) all the event files you want repaired and it will do all the editing for you and export them into the default export folder. Each exported .evt event file will be sequentially numbered to avoid overwriting similarly named log files from multiple machines. You can then load them up in the native WIndows event viewer and see the entire native message(s).

Download here

Basic eBlaster forensic analysis

eBlaster is computer monitoring software offered by SpectorSoft. They also make a product named Spector Pro, which is very similar. The main differences between the two is eBlaster is designed for remote installations and reports of activity to be delivered by email, whereas SpectorPro is designed for someone who has physical access to the monitored computer to review the reports.

eBlater and Spector Pro are very powerful. The software is frequently changed so it remains undetectable by common anti-virus software. The following is some basic oberservations of a forensic analysis of a computer with eBlaster installed.

eBlaster can be installed remotely (SpectorPro cannot) by preconfiguring it with all the necessary options and then sent or given to someone to be installed. The main function of the program is to record all user activity such as screenshots, emails, instant messages, etc. and then to send a report of that activity via email:



Installation of eBlaster is fairly simple and merely requires a registration key and an email address to where the activity reports will be sent.

The eBlaster program uses some random folder/file naming techniques to make it a little more difficult to detect or locate. In all of my testing the software always installs some of the required files into a randomly named subfolder located in the "\windows\system32" folder. There are eight files installed into this folder during the installation, of which one is an executable (admin control panel), while the rest or either .dll's or files with misleading file extensions. The image below is an example of a folder randomly named "subitvox" under the "\windows\system32" folder:



The eighth file is in the subfolder named "canunsec" seen above. Each installation I performed, caused all of these files and folders to get random names. Additionally, there are several .dll files dropped into the "\windows\system32" folder.

One of the easiest ways to "detect" whether eBlaster has been installed, is to attempt to locate a simple text logfile that is created by the program. The file is always in the root of the randomly generated folder under "\windows\system32". The log file is a simple ASII text file and commonly had a .dll file extension. The log file has some very predictable text can easily be detected using a grep search:

11/27/2008 12:56:00: (AGT,EXPLORER) Initializing process for file C:\WINDOWS\explorer.exe Recording App 1 Blocking App 1
11/27/2008 12:56:00: (EBR,EXPLORER)
11/27/2008 12:56:00: (EBR,EXPLORER) Start Monitor - User lance on REG-OIPK81M2WC8
11/27/2008 12:56:00: (EBR,EXPLORER) Build Number 3067. Serial Number 1234567890
11/27/2008 12:56:00: (EBR,EXPLORER) Windows XP Home Edition Service Pack 1 (5.1.2600)
11/27/2008 12:56:00: (EBR,EXPLORER) IPC Message pump started.
11/27/2008 12:56:00: (SHR,EXPLORER) PacketProcessorEB::CreatePacketXML: Sending settings to server.

Some of the lines above have been word-wrapped by the blog, but normally each line in this text file will begin with the datestamp then the timestamp. The datestamp format is always "mm/dd/yyyy". The timestamp format is always "hh:mm:ss:". A simple GREP search of "##/##/#### ##:##:##:" would find this logfile, regardless of it's name, with minimal false positive hits.

The above method is the simplest manner to locate active logs generated from eBlaster, as well as fragments in unallocated, MFT records and $LogFile.

The eBlaster software itself is all coontrolled by several .dlls that are loaded via the registry. A random GUID is generated and placed in the HKLM\Softwae\Classes\CLSID key. Here is an example from one of the installations:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7E116682-4410-4969-B8FA-5C3CCAE78026}\ProgID\: "Winoscmd"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7E116682-4410-4969-B8FA-5C3CCAE78026}\InprocServer32\: "C:\WINDOWS\System32\chmucfav.dll"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7E116682-4410-4969-B8FA-5C3CCAE78026}\InprocServer32\ThreadingModel: "Apartment"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{7E116682-4410-4969-B8FA-5C3CCAE78026}\: "Comivjob"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{AE256AD1-14D6-428F-BAEE-59B158AFFA0F}\InprocServer32\: "C:\WINDOWS\System32\midexkey.dll"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{AE256AD1-14D6-428F-BAEE-59B158AFFA0F}\InprocServer32\ThreadingModel: "Apartment"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{AE256AD1-14D6-428F-BAEE-59B158AFFA0F}\: "sapiclan"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Winoscmd\CLSID\: "{7E116682-4410-4969-B8FA-5C3CCAE78026}"
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Winoscmd\: "Comivjob"

From a network perspective, upon initially booting the machine, a DNS request is made to a domain of "d2a1376gf-43ty-245a.com". That domain has the following registration information:

Registrant:
Spectorsoft Corp.
1555 Indian River Blvd
Bldg B-210
Vero Beach, FL 32960
U.S.

Registrar: DOTREGISTRAR
Domain Name: D2A1376GF-43TY-245A.COM
Created on: 23-MAY-07
Expires on: 23-MAY-09
Last Updated on: 10-APR-08

That domain currently resolves to the IP address of "209.61.133.199". This IP address is registered by a company named:

OrgName: Robust Technology
OrgID: ROBUST
Address: 12178 Fahr Park Lane
City: St Louis
StateProv: MO
PostalCode: 63146
Country: US

NetRange: 209.61.133.192 - 209.61.133.223
CIDR: 209.61.133.192/27
NetName: RSPC-22301-0007111720
NetHandle: NET-209-61-133-192-1
Parent: NET-209-61-128-0-1
NetType: Reassigned
Comment:
RegDate: 2000-07-12
Updated: 2000-07-12

After the DNS request, there is an initial posting of data to the remote server, most likely for licensing validity. This network traffic is sent via TCP port 443 in an SSL wrapper. Although you cannot easily see the contents, an initial or periodic communication to that IP address would be excellent indication that eBlaster is installed. The program will periodically send activity reports to that IP address based on how its been configured.

When in doubt simply booting a copy of the machine in question in a controlled network environment (no Internet access!) would yield some instant communications that would tip you off. Here is a screenshot of the initial communication upon booting the system (between 192.168.214.1 <> 192.168.214.134 on port 443):



The above testing wa done on the latest release of eBlaster as of 11/2008:

My current impression of cell phone forensic tools

As part of my work, I recently put together a fairly comprehensive cell phone forensic course. As part of the development phase of this project, I had a chance to use most of all the common cell phone forensic tools and put them through the paces with over 50 different phones, most of which were international models.

In opinion, the forensic industry is nowhere near where we are today with cell phone forensics compared to computer forensics. Mostly because it is a fairly new sub-field of digital forensics and the tools just have not been around long and have not yet evolved to the state where the current computer forensic tools are at.

I also think it is due to the complete lack of standardization by phone manufacturers. With computer forensics, you have different makes and models of computers and it generally has little effect on the analysis phase because how they each operate is standardized and follow a set of design specifications. Whereas in cell phone forensics, each cell phone manufacturer could be using their own proprietary operating system and each phone may operate completely different from other models by the same manufacturer. This makes developing an all-inclusive tool that can support all the manufacturers and models of phones very difficult and is something like hitting a moving target traveling at 200mph. By the time you develop a tool to deal with a specific phone, 5 more new ones have been released that don't follow the same standard(s).

**** I have no association with any of these vendors****
The following is just my experience and impressions of the current state of these tools, future version releases could improve or worsen their performance.

The tools I used and evaluated are as follows:

Cellebrite
http://www.cellebrite.com/

Neutrino (Guidance Software)
http://www.guidancesoftware.com

Mobile Phone Examiner (AccessData)
http://www.accessdata.com

Secure View (DataPilot)
http://www.datapilot.com

XRY
http://www.msab.com

XACT
http://www.msab.com

Paraben
http://www.paraben.com

Fernico ZRT
http://www.fernico.com/zrt.html

Project-a-phone
http://www.projectaphone.com

To first summarize my experience and findings, I would rate my top three tools as:
Cellebrite
DataPilot
XRY

The reason for rating these tools as my top three tools is based on this criteria:
Functionality
Supported phones
Ease of use

Cellebrite
Currently, the only tool evaluated that can handle iPhones. This was not a deal-maker/breaker for me, but it is worth noting. This is a very simple to use hand held device that can be brought out into the field. I would love to see it have an internal battery to facilitate true in-the-field information gathering. This device handles many different phone models. It supports cable connections to phones as well as bluetooth. It cannot be any simpler to use, clear & easy menu driven screens guide the operator through the acquisition phase. Information can be sent immediately to an attached computer or saved to a USB flash drive, so it can be handed to an investigator for review.

DataPilot (Secure View)
Nice compact kit. Comes with an excellent cable kit that supports many different phones. This is a software solution that really only involves cables and a security key to enable to software. The software is simple to use. Generates nice clean reports.

XRY
XRY is a kit that comes in a fairly large box (suitcase). It comes with several cables, but not as many as Cellebrite or DataPilot. The XRY device itself is fairly small and self-explanatory with clearly labeled ports and connections. The device can be powered by a wall plug or by USB port, making field acquisitions very easy. The software interface is very simple to use and it supports a large number of phones.

For the rest of the devices I used and evaluated, the following are some of the findings and experiences that were relevant to my rating of these devices:

Neutrino
This device is an add-on to EnCase. It comes in a very large case. The biggest downside to this product is the lack of support for phones. The number of phones this device supports and can extract data from is very low. The ability to read non-US models is also very very low.

AccessData MPE
Notwithstanding all the known and previously discussed issues with FTK 2.0, I found this product to be very "clunky" and not too intuitive. I had common problems with the licensing of the MPE module and it not recognizing phones that were connected. Phone support it also very low. Ease of use is very low.

XACT
XACT is the only tool that is focused on getting a physical image of a phone. I was very excited to see this product and try it out. The hardware and software is almost identical to XRY. The biggest disappointment I had with this product is that it just didn't work or support many phones. Even the phones it said it supported, I had trouble with and later found out that it only supports phones with certain firmware. So if the documentation says it supports a Motorola SLVR L7, it may not work if that phone is using a certain firmware version. XACT can parse the "physical" image of some phones and break out the data into categories and show logical data, such as SMS, photos, etc, but this does not work on all models of phones. I didn't mind this because I could still look at the physical image, but unfortunately many of the phones I tried simply would not work because the firmware version was not supported. I was very happy that an old Motorola SLVR L7 that I examined, XACT was able to pull a physical image, but not parse the data. A manual search of the data resulted in several SMS messages that were deleted and were from 8-9 months in the past. The bummer was that when I tried three more Motorola SLVR L7 phones, a physical image could not be obtained because of an unsupported firmware version on these phones.

Paraben
This device suffers from many of the drawbacks as Neutrino. It does not support many common phone types. As Neutrino, it needs drivers installed for many of the phones.

Fernico ZRT
This really isn't a forensic tool, but rather a solution to process phones manually. It includes an awesome desk clamp, camera, microphone and software so that if you need to process a phone that isn't supported by one of the above tools, you can manually go through the phone and record everything as you do it. This is hands down my tool of choice when having to process or deal with phones that a forensic tool cannot process or when I want to manually capture something on a phone.

Project-a-phone
This tool is similar to Fernico, as it is used to manually process a phone and record right off the phone's screen as the investigator cycles through the phone screens. I found this product to be very low-quality and cheap looking. The camera image is very poor and not very usable. I would not recommend using this product at all.

If you could have any EnScript or filter, what would it be?

So I might be opening a can of worms with this post, but what the heck, I am bored. My question is if you could ask for any EnScript to improve your process, speed things up, or just give you a feature you don't natively have in EnCase, what would it be? It could be eDiscovery related or forensic related or just a general utility (tetris anyone?). It also does not need to be a stand-alone EnScript, it could be a filter/condition.

I am interested in hearing what the most popular request will be. Please post your "favorite request" in the comments of this post so others can see it, expand on it, tweak the idea or just echo your vote.

Let the wish-list begin....

SANS Forensic & Incident Response Summit in Las Vegas

SANS held a Forensic & Incident Response Summit last week (Oct 13-14) in Las Vegas. It was really nice to go and put so many names and people that I have communicated with in the past via email, with a face. It was a pretty interesting crowd that attended and some very informative presentations.

I did a presentation at the end of the first day to talk about some basic simple forensic & incident response tools and methods that seem to work well for me. I have posted the PDF of my presentation here.

For those of you that have not tried out the F-RESPONSE tool, you are really missing something quite useful. The founder of F-Response, Matthew Shannon, who was at the summit, announced on day one of the summit that version 2 of the F-RESPONSE tool was being released and it now supports access to physical memory on a remote machine. This means that using the F-RESPONSE tool you can image any and all physical disks on a remote machine, as well as the physical RAM on that machine, all while the machine is running!! You can read more about their latest verison here.

Aaron Walters also presented on how Volatility can utilize the F-Response tool with a new spin-off of Volatility that he created called "Voltage". A very cool tool to analyze the memory dump and show you what was going on at the time of the memory capture. The really cool thing is that Voltage can look at the memory live, in real time using the F-RESPONSE tool, meaning that you can look at it now and then refresh the page 2 minutes later and what you are seeing is the live reresentation of the memory contents 2 minutes later, not a captured image of it. As Aaron likes to say, he can actually watch the clock tick on the remote machine in memory!! VERY COOL!!! You can read about Volatility here.

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) int he 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