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

Additional Bitlocker Incident Response tips

In January, I posted some Incident Response tips on how to deal with a Vista system with Bitlocker enabled. You can read the initial post here. I was recently doing some training and we discussed Bitlocker techniques in depth and decided to post a follow up with some additional tips.

The first thing you must do when you roll up on a system running Vista is to determine if Bitlocker is enabled. Remember that Bitlocker is only available in the Enterprise and Ultimate editions of Windows Vista. A quick look at the system properties should tell you what version you are dealing with:



There are a couple of easy ways to determine if Bitlocker is enabled. The first method is to simply open Windows Explorer and look at the logical drive list. Bitlocker requires two logical volumes. One for the OS and user data files and the second is a small boot partition 1.4GB in size, that is not encrypted. By default, Windows assigns the logical drive letter "S" to this small boot partition:



Also, NTFS is the required filesystem on the logical volume encrypted with Bitlocker.
The second method to determine if Bitlocker is enabled is to simply look at the Bitlocker configuration from the Control Panel:



Finally, you can open an Administrative Command Prompt and use the following command to check the status of Bitlocker:

"cscript manage-bde.wsf -status"



This last option tells you that the logical volume "C" is encrypted with Bitlocker and that an external key (USB) and a numerical password are being used as protectors. This tells the investigator that there must be an external USB device with a key on it (.BEK) extension and that there may be a numerical password written down somewhere. The password is very long consisting of eight groups with six numbers in each group, such as: "363319-629200-548735-017523-429363-314292-005962-259380". The status output also tells you if Bitlocker is currently enabled.

Once you have determined that Bitlocker is in fact installed and enabled, the investigator now has to decide how to handle this volume so later analysis can be performed. There are a couple of options available at this point. The investigator could use a live response CD and make an image of the logical drive while the system is running. It is important to understand that a LOGICAL image must be taken, because it uses the Windows API in order to obtain the decrypted data. If a physical image is taken, you will end up with a full image of the hard drive in its encrypted state and then you will have to deal with decrypting it later in order to perform an analysis.

Another solution is to disable Bitlocker. Disabling Bitlocker does not decrypt the data, in turn altering each file. Instead, it stores the key on the disk so that it can be decrypted the next time it is booted or accessed without the need for the startup key or numerical password. The following command shows how to disable Bitlocker from the command line:

"cscript manage-bde.wsf -protectors -disable c:"



The above command will disable Bitlocker (not decrypt) and if later attached to another Vista machine using a write blocker, all the data will be visible and available for imaging.

The investigator should also obtain the numeric recovery password as a safety measure to ensure later access to the drive for imaging. The following command will display the numerical recovery password:

"cscript manage-bde.wsf -protectors -get c:"



Here is a video showing all the above commands:

XOR entire file or selected text

XOR is a common and simple symmetric encryption algorithm. It is commonly used by malware to 'hide' certain identifiable information in a data file or executable. It is a very simple algorithm, so there is very little processing power needed to quickly encrypt or decrypt data, making it a popular technique.

Some software vendors also use it to 'obfuscate' data. Norton Antivirus uses it to store identified malware files in the quarantine folder. When Norton AV detects a virus, it will XOR the virus with a constant key and then place it in the quarantine folder. I had previously written an EnScript to extract files from the quarantine folder in Norton version 7.5 so they could be examined in their native form. Norton also stores its logs encrypted using XOR (most versions). I wrote this EnScript specifically so I could quickly decrypt Norton logs within EnCase when doing an investigation so I could see what kind of virus activity had recently taken place, but then I quickly found other uses for the EnScript.

The EnScript allows you to simply highlight (highlight, not check) a file in the table pane (upper right) of EnCase and then supply a hex value as the XOR key.



You can have the resulting XOR data displayed in the console, or if dealing with binary data, such as with a malware executable, you can have the data written to a local file that you can then examine with some other 3rd party tool.

Download here (EnCase v6)

Export IE Internet History from unallocated for use with 3rd party processors

A user recently contacted me about an old v4 EnScript that was used to export Internet Explorer Internet history from Unallocated so it could be processed with NetAnalysis. She asked if I would update the EnScript to work with v6 since she explained that she used NetAnalysis with almost every case and they have become accustomed to the output.

I have updated the EnScript to work with V6. Simply select (blue check) and file(s) you wish to search for IE Internet History (Unallocated, pagfile.sys, hiberfil.sys, etc.) and then run. If any history is found, it will be exported to a file that can then be parsed by NetAnalysis (or other 3rd party tool).

Download Here

Ghost - Part Deux - How to detect its use

I decided to keep going a little farther with my research and see what I could come up with to detect ghost was used either in the past or to make an image that was being provided to an examiner. Plus, I had already shot half my weekend, so why not finish the whole thing off!

The first thing I will mention is the "fingerprint" that ghost can leave behind. A reader left a comment asking about using "-FNF" command line switch when making an image so that the ghost application does not mark the hard drive(s). I did not use the "-FNF" switch at any time when I made any of my images and as long as I used the "-IR" switch, an exact duplicate was made of the source disk each time and ghost did not modify the original hard drive. BUT, I was asked at the time ghost started up if I wanted to mark the hard drives with the following screen:



I answered "Continue without marking drives".

A hash baseline was taken of the source drive before ghost was ever used and the before and after hashes of the source remained constant regardless if I used the "-FNF" command line switch or not. When I did specify the "-FNF" switch, I was still prompted with the screen above. As long as I answered "Continue without marking drives" The original remained untouched.

By answering "OK" to the screen above, ghost DOES MARK ALL DRIVES it detects! Now obviously the source drive would most likely be connected via some type of write-blocking device so ghost would not be able to write this change to the source, but it may mark other drives connected to your system that you don’t want marked. If you do answer "OK" a "fingerprint" is placed one sector prior to the volume boot sector, typically at physical sector 62:



Once marked, ghost will stop asking the question at startup if you would like to mark the drives. I have not yet deciphered the “fingerprint” data written to this sector yet, but it appears the first dozen or so bytes remained constant between different markings, but the rest of the data changed each time I marked the drive, indicating some type of possible date stamp. When creating the image using the "-IR" command line option, if the source drive is marked, then the destination image will be marked as well.

The second part of my testing involved looking at how ghost copied files from one drive to a destination drive, either directly or through a ghost image file. If ghost was used with the "-IR" command line switch then ghost leaves everything in the same place as the original. My main focus was inspecting the changes with the default option of ghosting a source drive and then restoring it out to another drive like a typical user or IT professional would do. When I created a ghost image of a source drive and then restored that image, all the internal file system creation dates remained unchanged from the source's timestamps.



Looking at the screenshot above you can see the timestamps of the internal file system objects from the original drive have carried over to the ghost copy. This was true if I made a disk to disk image or a partition to partition image.

The only obvious artifact that ghost was used is the file extents field. The file extents field indicates how the file is fragmented. You can see in the original that the "Unallocated Clusters" object represents all of the unallocated clusters across the logical volume. In the source, there are 700+ "patches" of unallocated sprinkled around the drive. In the new ghost image, there are only three. The first is a small area consisting of 16 sectors immediately following the $AttrDef internal file. Then there is a large gap immediately following the $MFT, which is considered the "MFT zone" and is usually about 12.5% of the volume size. This area is reserved for use by the MFT as it grows. Immediately after the MFT zone are all the other remaining files on the volume, with no unallocated gaps in between them. Not all files are contiguous on the ghost image, but there are no files with unallocated before or after, except the ones I mentioned. The following screenshot is of the original source drive showing obvious signs of fragmentation:



Here is another contrasting example by viewing the file extents of the Unallocated Clusters object:



The newly ghosted drive only has the three aforementioned areas of unallocated space. There are still files present on the newly created ghost image that have multiple file extents (fragmented), but there are far fewer than on the source drive. This screenshot is of the drive that received the ghost image:



Summary:
Although there are a few indicators such as the presence of the "fingerprint" that indicated ghost has "marked" that drive at some point in the past, there is no surefire way to detect the use of ghost with certainty. As indicated above, the lack of unallocated area being fragmented around the drive would certainly be suspicious, but as the system gets used after a ghost image was restored, the system will begin to fragment like before, and so it will depend on the timing of the seizure. I would certainly look at the timestamps on the internal file system files, coupled with the date in the registry as to when the OS was installed to give me an idea of how long that file system and OS have been operating and then compare that with the absence of file fragmentation to help support the idea ghost was used.

Video demonstratinig adding an uncompressed ghost image file (.gho) into EnCase and then manually adding the VBR to have EnCase parse the volume then you can image like any other device.

Ghost as a forensic tool

If you have not figured it out yet, I read several forensic listservs (great way to learn and kill half my weekend ;) and I often find myself picking a topic I read about on one of the listservs and then blogging about that topic.

So this weeks topic is about using Symantec's Ghost utility as a forensic tool. The ghost utility has been around for many years and is most commonly known for and used by IT professionals to create baseline images of workstations and servers for quick deployment. I doubt that at its inception, that ghost was ever designed to be used as a forensic tool. But somewhere along the way, Symantec added some functionality into the ghost utility to make "forensic" copies of hard drives specifically for law enforcement purposes.

Many years ago I remember going to training and hearing that ghost was an unacceptable tool to use to create a 'forensic' copy as it did not create an 'exact' image and changed a few bytes so you would never get the same hash as the original. I remember performing an exercise and creating a ghost image and comparing the hash values of the original and the ghost image to see that they did not match. As I mentioned, somewhere along the development path of the ghost utility, the ability to make an exact forensic copy was included. The best I can tell, it started with ghost v5.1, circa 1999. From the "Whats new.txt" included with that version:

"-ID (Image Disk) is similar to -IA (Image All), but also
copies the boot track, as above, extended partition
tables, and unpartitioned space on the disk. When looking
at an image made with -ID, you will see the unpartitioned
space and extended partitions in the list of partitions.
The -ID switch is primarily for the use of law enforcement
agencies who require 'forensic' images."

Then in Ghost 2002, the command line switch "-IR" was included:
"-IR The image raw switch copies the entire disk, ignoring the partition table. This is useful when a disk does not contain a partition table in the standard PC format, or you do not want partitions to be realigned to track boundaries on the destination disk. Some operating systems may not be able to access unaligned partitions. Partitions cannot be resized during restore and you need an identical or larger disk."

(ftp://ftp.symantec.com/public/english_us_canada/products/ghost/manuals/ghost2002.pdf)

So what do these command line options do and which is appropriate to use?
I have tested several image files created using the various ghost command line switches and here is a summary:

-ID
This command line option appears by description to create a bit-level image (they call it a sector-by-sector) and it in fact does. If an hard drive image is created using the "ghost -ID" switch, then a bit-level image is created. The problem with this switch comes when you restore this image back out to a hard drive. This switch will cause ghost to adjust the partition boundaries on the destination drive if they are not standard. So for example, if the source HD has 32 sectors per track (SPT) and ghost image is created, when the image is restored back out to a hard drive, ghost will adjust the partition boundaries if the disk geometry is different on the destination drive and make appropriate changes in the partition table. This will obviously result in different hash values being generated. This command line option is configurable in the actual ghost application under the options->Image/Tape tab:



-IR
This command stands for "image raw" and it too makes a bit-level image resulting in an exact duplicate. The difference in this switch is that ghost will ignore the disk geometry on the destination drive when the image is restored and create the image exactly as it was on the source. An image created with the -IR switch will result in the same overall drive hash as the original, ASSUMING it is restored out to a hard drive of the same exact size. This option does NOT appear in the ghost options tab and is a command line switch only.

Ghost (with any switch) DOES not make an image file (.gho extention) that is a raw bitstream image like 'dd' does. A look at a ghost image file in a hex editor will show you that there is a header with information that ghost uses to restore the image correctly and was not on the source drive, typically the first six sectors of the image file. Then the actual bitstream copy of the source drive follows and the footer used by the ghost utility is at the end of the ghost image file. Ghost allows you to compress the image of the source drive when the image is made. This has no effect on the data when it is restored; it only affects the data as it sits in the ghost image file (.gho).

The only appropriate command line option for use when making a forensic image is the "-IR" option. Although not a common forensic tool and often believed to be unacceptable for forensic use, current versions of ghost can make an exact duplicate of a hard drive when the -IR command line option is used.

The only other problem is that there is no easy way to tell which switch was used when the image was created. If you try and look at an image that was created with the -ID or -IR switch with Ghost Explorer, an error message will appear stating that one of those command line options was used, but does not tell you which:



If you look at the details pane when restoring the image, a disk image created using the -IR command line switch will say "RAW DISK IMAGE":



An image created using the -ID command line switch will just show the file system type:



There is also no way to validate the image's integrity. I opened a ghost image file with a hex editor and erased several references to a file and ghost happily restored the image without reporting an error. Since there is no way to generate hash values for blocks or the entire HD source from within ghost, you would have to take a baseline hash BEFORE ghost is used. Then when restored that baseline hash could be compared to the restored drive hash, again using an external tool outside of ghost.

To summarize, the important things to remember if you are using ghost to create an image or if you accept a ghost image are:

If using ghost to create an image:
Create a baseline hash of the source drive before using ghost
Use ghost with the "-IR" command line switch
Make a ghost image of the "disk" not just a partition
Hash the .gho file for reference (convenience)

When accepting a ghost image file:
Ask for documentation on which command line switches were used
Verify via the details pane when restoring the image
Verify it is an image of the entire disk, not just a logical partition
Ask for a baseline source hash from before ghost was used
Verify the restored image hash to the baseline

*Note - all testing and screenshots were done using ghost 2003.

Create 'dd' image file from EnCase evidence and redact certain files

***Updated verion 1.1 - Sanity checking on deleted, overwritten files, files with invalid clusters and folders

This project started out as a request from a blog reader where they were ordered to provide a copy of an evidence file to another party, but redact certain files. He had already figured out a way to do this with a 3rd party tool, but wanted to dump a text file of the offsets and lengths of the files that were selected so they could be read by a 3rd party tool and then some automated wiping could take place.

Back in July of 2007, I released an EnScript to make a 'dd' image file from an EnCase evidence file (original post is here). I started thinking about how easy it would be to incorporate that feature to that EnScript. An hour later, here is a modified version of the original "export to dd image" EnScript, with the ability to redact selected items.

Basically the way it works is that you load up one piece of evidence and then select any item(s) you want redacted. You can select anything, including unallocated space, which will then be written as all zeros in the 'dd' image file. The selected filename and metadata are all maintained, just the data contents are redacted. Check the console for some logging information.



Now this obviously has some interesting uses, with the most obvious being why I originally set out to make this EnScript, but after working on it and playing around with it, I came up with several other very useful uses, especially when making example evidence files for students. The cool part is you can load up an evidence file, select unallocated, and then when its done, load up the 'dd' image file and then quickly reimage and the resulting evidence file is much smaller since the wiped data is stored as sparse data. So when working with sample evidence files where the pagefile, unallocated or other files are not needed, you can quickly wipe them out and reduce the overall size of the evidence file significantly.

Before (now you see it):



After (now you don't):


All other files remain intact and all other individual file hash values verify between the original and the 'dd' image.

Download Here

Bypassing a Windows login password in order to boot in a virtual machine

I have seen several recent posts on the forensic list servers asking about how to get by a Windows logon password in order to boot an image in a VMware machine. Normally the approach I would take is to extract the SAM and the SYSTEM registry hive and then use a tool to load rainbow tables and try and obtain the password. If there is no Lanman password in the SAM file, this can put a serious dent in my plan because I currently don't have any large NT rainbow tables to use.

As a refresher, Windows 2000/XP/2k3 stores two hashes of a user's password by default. The first is the weak Lanman hash and then the second is the stronger NT hash. It is the Lanman hash that most rainbow tables are built for because of their inherent weakness and how they are stored, they are the quickest to attack. Windows Vista does not store the Lanman hash, only the NT hash. Windows 2000/XP/2003 will only store a Lanman password if the password is < 15 characters. So if a user sets a password greater than 14 characters, no Lanman hash is stored. In addition, there is a security policy that can be changed to stop storing the Lanman hashes even with passwords of any length.

Many people use Nordahl's password recovery boot disk to either change or blank out a password. This technique works very well and I have used it many times.

I discovered two additional ways to get around passwords when the passwords are either too difficult for rainbow tables or when there is only a LM password and a brute-force attack will take too long. The techniques I am going to describe will not recover the password. It will merely let you login to the system with a specific user account. Getting access to the system using these techniques will not let you access any files that are protected via EFS in Windows XP or Vista since the password is used as part of the encryption/decryption process.

The first technique is embarrassingly easy and simply involves deleting the SAM file. In seems that in Windows 2000/XP/2003, if you simply delete the SAM file a new one is created upon boot with only the two normal built-in Administrator and Guest accounts, neither with a password. A variation to this is to simply rename the original SAM file and replace it with the one that is in the repair (2000/XP/2K3) or regback (Vista) folder. This copy of the SAM is from when the system was originally installed and the user accounts that were present at that time may not have had any passwords set. You could also try and use the ones from the various Restore Point captures to see if there is a capture of a time when no password was set for a specific user and then use that SAM file to boot.

The second technique simply involves faking Windows out. To do this, you open the SAM file up with a hex editor and find the data that represents the V file for the particular user account in the SAM file that you want access to. There is a data field in that data structure that represents or indicates if a password is set. Normally it have a value of 0x14 if a password is set. Simply change that value to 0x4 and then boot the machine. Even though there is a password hash present, it will login with no password entered. I have used this technique with Windows 2000, XP & Vista and it works well. I have encountered a few instances where the flag that indicated if a password is present (0x14) already had the value of (0x04). I am not sure if the SAM.log or transaction log changed the changes and used values stored elsewhere when the system was running to determine if a password was set, but the above technique will obviously not work in that situation.

In that case, I have been able to take a password hash from another user account that I was able to either crack or is blank and then "transplant it" into the V record of the account I want access to. By doing this, you are effectively swapping the password hash with a know password hash.



In the screenshot above the one-byte highlighted values of 0x14 are the length indicators representing that the lanman is 20 bytes in length and the NT is also 20 bytes in length. To bypass, simply change these to 0x4 with a hex editor. The highlighted data at the bottom of the screenshot is the Lanman and NT password hashes.

I need to do some more testing on all the various versions but to date, this has worked for me everytime without a problem.

An excellent resource for learning the data structure of the SAM file can be found here.

Here is a general guidline on how to determine if a password is set from inside EnCase:

1. A user in Windows has potentially two password hashes that are stored
(only one password, but two different hashes are generated). The lanman
hash and the NTLMv2 hash. Lanman is legacy and not always stored based
on either the local security policy or the domain policy (or registry
hack).

2. The "V" key in the SAM registry hive under the user's SID is where
the password is stored (remember that this is not a straight hash of the
users password, but rather a DES encrypted version, encrypted again
using the SYSKEY).

3. Starting from the very beginning of the V key, sweep 156 bytes. The
next 4 are the offset to where the lanman hash is stored in the V key
relative to a constant offset of 204. So for example if you look at
offset 156 and there is 64 01 00 00, which equals 356 in decimal, you
would add 356 + 204 = 560. Then, make note of the next 4 bytes (starting
at offset 160, which will either be 04 00 00 00, or 14 00 00 00). This
represents the length of the hash that is stored including a 4 byte
header. If the size is "4" then just the header is present and no hash
is stored (i.e. no password). If the length is "14" (20 decimal) then a
hash is stored, as well as the header (4 byte header, 16 byte hash) =
20.

4. Then from the beginning of the V key, go 560 bytes (the sum of the
length + the 204 constant) and the next four bytes are the header (I
have seen 01 00 01 00 & 02 00 01 00 as headers) then the next 16 are the
lanman password hash, if present.

5. For the NTLM hash, start at the beginning of the V file again and
sweep 168 bytes. The next four are the offset to where the NTLM hash is
relative to offset 204 and then the next four are the length. Same rules
apply as above. If the length is "4" then no NTLM hash is stored and
only the header is present. If the length is "14", then there is a 16
byte password hash and a 4 byte header present. You would follow the
same procedure as step 3 above and take whatever value is at offset 168
+ constant of 204 = the offset to where the NTLM hash begins (actually
the header begins, then the hash)."



Good luck!

USB Device History EnScript - Updates

James recently emailed me to tell me that he had taken the USB Device History EnScript and modified it to display additional/different information. So in the spirit of sharing and with the author's consent, here it is:

From James Habben -
The output is now modified to go into the Records Tab of EnCase so you can sort it and it is part of the case bookmarks

Download Here

From Edge -

- Semicolon separation of all information pulled from the registry so
it can be pulled into IDEA, Access or Excel.
- Dump of ENUM\USB including VID, PID, Serial_Num, Device_Description,
Location_Information, Manufacture and ParentIDPrefix.
- Updated ENUM\USBSTOR to also output the date the registry key for
that device was created (i.e. the date the USB device was first plugged
in).
- Added James Habben Records Tab feature.
- Fixed issue with Mounted Devices not producing the serial number for
some fixed drives i.e. C Drive.
- Made Mounted Devices more conducive to Excel/Access/IDEA.
- Fixed my stuff up with Manufacturer and Location_Information
ordering.
- Changed console output format slightly to reflect James's layout.
- Special Thanks to James for fixing an interesting issue I was having
with mountVolume method and for making his source code available.

Download Here

Server Outage

**UPDATE - Everything should be back to normal. If you have any trouble, please let me know, thank you.

The server that hosts all of the EnScripts/EnPacks will be down starting Feb 13 until no later than Feb 17. The blog will continue to be functional, but the links to download any of the provided EnScripts will be down.

If you have an urgent need for one, you may contact me at the email or number listed on the main page.

Decode/Bookmark Base64 text in EnCase

I had a recent need to examine some php pages that were used to compromise a web server. Several of the php pages were obfuscated using base64 encoding to avoid detection. Therefore, I needed a quick way to decode base64 text and then bookmark the decoded text for later review.

The first step is to sweep the base64 text:



Next, run the EnScript and check the box if you want the decoded text bookmarked:



Once the EnScript is completed, you can check the console tab for the decoded text as well as look at the bookmark if you chose that option.





Remember that the length of the base64 encoded text should always be divisible by four. This is because four bytes of encoded text actually represents three decoded characters. This is why sometimes base64 text contains "=" characters at the end, which are used as null padding to make the length of the string divisible by four. The EnScript checks the length of the selected text and warns if you have selected either too many characters or too few:



Download here

Forensic Practical #2

I have posted some answers to the first forensic practical here. Based on the lack of answers/feedback on the first one it was either too difficult or nobody was really interested, so I will post an easier second problem and see how this one goes.

Scenario:
An employee named Castor Troy has just abruptly left a software company that he has worked at for the past 5 years. His departure was sudden and somewhat suspicious. Co workers said he came in very early the day he quit and seemed "panicked".

Due to his tenure, he had access to some critical intellectual property. When he left, the IT department assumed control of his computer and briefly examined it pursuant to an HR request. They found several zip files in the user's home folder containing some critical information. HR has referred this to legal counsel and you have been retained to provide whatever information you can about what happened and what, if anything may have left the company when the employee quit. The information found in the user's folder is critical IP information, but the employee had access to even more sensitive information deemed very secret.

Inside Counsel would like to know if any of that information was accessed or copied. Your mission, if you choose to accept, is to conduct a forensic examination and provide whatever factual information you can to counsel so they can decide if further legal action is necessary.

Good luck, have fun, and as always, if you are caught I will deny any knowledge of your existence.

Download Here

Forensic Practical #1 - Answers

A few weeks ago I posted a forensic practical along with a basic scenario. You can review it here. A few readers posted some comments, some of them on target, but not nearly in-depth enough. Here is a summary of key points that should have been observed.

1. WINDOWS/system32/inetsrv/rpcall.exe is malware and would be identified by an AV scan. The behavior of this malware is to scan for additional vulnerable machines, which is what caused the network traffic. This executable is set to run at boot through the HKLM\Run key.

2. Looking at the creation date of rpcall.exe should reveal some interesting things, most notably is that every file in the parent folder (\windows\system32) has the same created date/time. This is not normal and is indicative of some sort of timestamp manipulation tool.

3. Sorting by filenames would have revealed a prefetch file was created 06/18/04. Sorting on creation time on that file would show several other files of interest were started near that same time:

ping.exe
cacls.exe
cmd.exe
sms.exe

4. Looking for sms.exe would result in finding no executable named that, but there must have been one at some point if there was a prefetch file, right?

5. An exam of the User assist keys shows several programs run by the user account of "vmware". One of which is "UEME_RUNPATH:C:\System Volume Information\_restore{00D8A395-89D5-46B8-A850-E02B0F637CE5}\RP2\snapshot\Repository\FS\sms.exe" What the heck is a user doing executing something out of a system restore point folder?

6. Searching in unallocated for "sms.exe" in Unicode would reveal some interesting results

7. Searching the $Logfile would also reveal some interesting results for the keyword of sms.exe, including a complete MFT record for that file and the MAC timestamps. In addition there is an interesting fragment of text from what appears to be a batch file named del10.bat.

8. A search of del10.bat would reveal several hits, including a complete MFT record in the $logfile with timestamps and the appearance in two prefetch files, sms.exe & cmd.exe.

9. reset5setup.exe is a crack used to bypass Windows activation.

There are more artifacts, but the above listed ones are a good start.

Search for Windows 64 bit TIMESTAMPS

The NTFS file system is pretty verbose and redundant. With the introduction of Windows Vista, there is even more file system redundancy with the Volume Shadow Service (VSS). Windows uses a 64 bit timestamp to track most file system events (created, accessed, written, modified). This 8 byte value represents the number of 100-nanosecond intervals that have passed since midnight UTC, January 1, 1601.

There have been many times where I have found myself searching for these Windows timestamps in the various internal files. EnCase and most of the other forensic tools show you the contents of the master file table (MFT), but what if the reference to the file and folder is no longer there?

On several occasions I have found references to files/folders in the $LogFile and unallocated space that were of interest. Most times I found them because I was searching for a specific filename and I uncovered the record or I stumbled across it. In those cases, I found myself trying to craft a GREP expression to then lock onto any other Windows TIMESTAMPS that were for the time frame. As an example, the screenshot below is of an MFT record that is in the $LogFile:



This EnScript basically takes a starting date/time combination and then an ending date/time combination and generates an appropriate GREP search expression for that date range. It then searches any selected (checked) files for that date range and then bookmarks the findings. Because Windows timestamps are very granular and accurate down to a 100 nanosecond interval, exact date/time matching is impossible, but its very close depending on the size of your date range. Smaller date ranges (a couple of days) will be much more accurate than large date ranges (several months).



The option at the bottom allows you to look for consecutive timestamps, i.e. a timestamp matching your date range, followed by another timestamp, not necessarily in your date range. This is if you want to specifically look for orphaned MFT records in unallocated or the $Logfile, since an MFT record has eight timestamps, a group of four consecutive timestamps and then another group of four, then setting this option would only find those types of records.



This EnScript bookmarks any found timestamps and then reads the timestamp and places it in the comment field for sorting purposes. The timestamp in the comment field is GMT and your case settings have no effect on it. If you choose to sweep the timestamp and view it through the bookmark styles, then your case timezone setting applies.



Download here

Searching for encrypted keywords in Yahoo Messenger

**UPDATED Version 1.1 - fixes a problem with boomarks in multiple files

The Yahoo Messenger client has the option to save chat conversations to a text file. The default is to save all conversations until the Yahoo Messenger application is closed and then the logs are purged, thus leaving them in unallocated space.

Yahoo Messenger does not store the chat conversations in plain text, but instead uses the low-level XOR encryption technique to obfuscate them. This thwarts the technique of doing a keyword search for something that may have appeared in the chat conversation to find a conversation or fragment of the log in unallocated.

Yahoo Messenger uses the screen name of the person logged in using the Yahoo client as the XOR key. That key is then applied to all chat text and the resulting ciphertext is stored in the logs. If you use the built-in Yahoo archive viewer, the text is decrypted and displayed, but as it sits on disk, it is encrypted.

I have written an EnScript that asks for two primary things, the screen name of the person using the local Yahoo client and then the keyword or phrase you wish to search for. The following is an example of how the chat conversation is encrypted by the Yahoo Messenger client.

For example, lets assume the local user has a screen name of "localuser" and the remote user has the screen name of "remoteuser". The localuser sends the following message to the remoteuser:

"lets meet tomorrow and talk about how we are going to murder her"

If you think about the XOR process similar to doing addition, the localuser screen name is applied to the above text in the following way:

lets meet tomorrow and talk about how we are going to murder her
localuserlocaluserlocaluserlocaluserlocaluserlocaluserlocaluserloca
------------------------------------------------------------------
resulting ciphertext resulting ciphertext resulting ciphertext

The resulting XOR ciphertext would be the result of XORing the top "l" with the bottom "l", then "e" with "o", "t" with "c", and so forth. So from this example you can see that if you were searching for the keyword of "murder" you would have to XOR it with "aluser" in order to search for the correct cipher text (it may not be aligned properly in the above display).

This EnScript basically takes the keyword or phrase you enter and then XOR's it every possible way depending on how long the screen name is. Using the example above, searching for the keyword of "murder", there would be nine possibilities (because the screen name of "localuser" is nine characters long). So this EnScript creates all the possible ciphertext keywords and then searches the selected (blue checked) file for the ciphertext and bookmarks any findings.



Currently, I consider this EnScript in BETA form. It seems to work and find the keywords I have search for, but I have not thoroughly tested it yet. In addition, it simply bookmarks the found ciphertext, but leaves further decoding to you. I may add that in future releases and will most likely add additional information to the bookmark in the near future. I welcome any feedback, comments or feature enhancements.

Download here

Incident Response - Recovering a BitLocker Recovery password before system shutdown

This post is just a refresher for those of you who may encounter a running Vista machine that has BitLocker enabled. The following command will display the recovery password in a command prompt so it can be recorded (a photo) for later use by the examiner.

When initially looking at a running Vista machine, one easy indication that bitlocker is installed is the presence of two volumes. The main volume labeled "C:", and a second volume labeled "S:" (Of course this labeling is by default and could be changed).



The second volume labeled "S:" is a small boot partition that is created when BitLocker is enabled and is typically 1.46GB in size. The contents of this volume is minimal and will at a minimum contain the following files & folders:



If you suspect BitLocker is installed, and even if you recover a removable flash drive that you suspect contains the startup key, the following command is recommended. Start a command prompt with escalated privileges by right-clicking on the command prompt option from the Start menu and choosing "Run as Administrator". Once the command prompt starts, it should say "Administrator: Command Prompt":



Once you have this prompt, the best practice would be to insert your Incident Response toolkit CD-ROM that you previously built (you did previously build it, right?) that contains two WMI scripts that can be found on a default installation of Vista with Bitlocker enabled. These two files can be found in the system32 folder of a BitLocker enabled Vista installation and are named:

manage-bde.wsf
manage-bde.ini.en

You should copy these two files along with the cscript.exe interpreter to your incident response CDROM, you know, the one that's in your incident response toolkit and ready to go....:(

These files are installed by default when the BitLocker feature is enabled, but you shouldn't use the ones on your suspect's installation of Vista. Yes, you are already using the suspect's untrusted operating system, but this is about minimizing risk.

The command to obtain the BitLocker recovery password is:

"cscript manage-bde.wsf -protectors -get c:"



The best method is to take a photo, but verify the photo is not blurry or washed out by the flash before you proceed. Alternatively, you could pipe this information to a text file on a floppy or an inserted flash drive (remember you are going to create registry keys, so document).

You can then shutdown the system and remove the drive to be later imaged in the lab. Once connected to a write-blocker, EnCase (with the EDS module) will recognize the volume as a BitLocked volume and ask for the recovery password. You can then enter the recovery password as it was displayed and make a complete decrypted copy of the data at the logical level (if you look at from the physical level, it will still be encrypted because the data is still encrypted as it sits on the disk).

Alternatively, you can connect the drive to a write blocker (better yet, make a bit level copy and use that) and then connect it to a forensic machine that has Vista installed with BitLocker enabled. Vista will see the volume as a foreign encrypted volume and ask for the recovery password. Once entered, Vista will then mount the volume and assign a drive letter. You can then fire up your favorite trusty imaging application and image the logical volume in a decrypted state.

Both methods will make a decrypted copy of the data so from that point forward, BitLocker is removed from the equation.


*NOTE: There are two primary methods of implementing BitLocker. The first is with the use of an onboard TPM chip. The second is currently the more common implementation and only involves a removable flash drive (a third method exists that involves using both a TPM chip and removable flash disk, which is considered the more secure implementation). The above described commands will succeed for all the different BitLocker methods, but if a TPM chip is installed and used, the decryption process when attempting to image the volume will not work because it relies on the TPM hardware component as part of the decryption process. In theory the only solution in that scenario would be to connect a bit-level copy of the original hard drive to the original suspect's computer and then provide the recovery password at boot and then image the visible volume off to a external drive. I have not yet had the opportunity to test this because I do not yet have a TPM enabled computer. If someone has used or tested this method, please advise.

Keyword search with exclusion list - Beta

**Updated version now available - v1.5 (case sensitive & user-definable bookmark folder name)

An EnCase user contacted me about a problem he was having searching for a fairly common keyword and how he could exclude certain preceding or proceeding words that were adjacent to the core keyword.

Regular GREP expressions allow you to do this, but the EnCase version of GREP currently does not support using the NOT operator ("^") against multiple characters. So for example if you wanted to search for the keyword of "install". When the search was done, you may have thousands of hits, but see that the majority of them are a word like "clientinstall", and/or 10 other combinations of the keyword of "install" like windowsinstall, installapp, applicationinstall etc.. The EnCase version of GREP DOES allow the NOT character to be used such as this example:

[^t]install

This would find the keyword "install" as long as there was no preceding "t" character before it. This example would eliminate the term clientinstall" as I indicated above, but it would also eliminate all other possible keyword hits that may have the letter "t" preceding the keyword of "install", such as "statinstall", which I may want.

So to get around this scenario, I wrote an EnScript that asks for a keyword. It then also asks for a list of exclusion words (it can be pasted into the window). The EnScript then search ALL SELECTED items for ANSI and UNICODE occurrences of the keyword. It then reads the characters before and after the keyword hit to see if the hit is one of the exclusions you provided, if so, it skips the hit and moves on to the next hit. If the characters before and after do not match what you provided in the exclusion list, then it will bookmark it.

Using the example above, I ran the EnScript and entered "install" as my keyword. I then entered a list of exclusion words, such as:

productinstall
uninstall
appinstall
installapplication

Here is a screenshot of the three fields that require input:



The results exclude any keyword hits that are part of the exclusion list:



This is a beta version and it has not been tested completely. Please feel free to download and try and post any comments, bugs, suggestions.

Download v6 version here

Basic System Volume Information EnScript

I was recently contacted by Hans Heins in the Netherlands, who had some EnScripts that were written in v4 by a student trainee. The EnScripts parse out basic information from the System Volume Information, Restore Point files. He posted these EnScripts to his website listed here.

I have ported these over to EnCase v6 EnPack format.

The first one parses the rp.log for basic information on when the restore point was made. To use, select (blue check) one or several rp.log files and then run the script. A small text file with the information is created in your default export folder. You can download the v6 version here.

The second one parses the change.log and lists the files that are in the restore point. To use, select (blue check) one or several change.log files and then run the EnScript. A small text file with the information is created in your default export folder. You can download the v6 version here.

Thanks to Hans for sharing the EnScripts.

Forensic Practical

I run several honeypots and I decided to take some of the malware found on the honeypots and install it on clean computer systems and watch its behavior. To take it a step further for those of you who like to hone your forensic skills, I have decided to post an evidence file of the machine with the malware, and describe a simple scenario that a first responder or examiner would likely face in examining this evidence.

SCENARIO:

A user in a company is using WinXP Home (just go with me on this ;) and he notices his computer is acting funny. He calls the IT staff over and after some digging around they determine something is definitely wrong. When they do a netstat they see hundreds of connection attempts. They pull the machine offline and image it. They did happen to speak to their netsec people before they pulled it offline, who captured a small amount of network traffic regarding the WinXP system.

The image is provided here in the EnCase evidence format (400mb).

A network capture in tcpdump format is provided here (230kb).


This is not rocket science people, it is fairly simple exam, but it is a a good training example and a very common scenario. Please feel free to download and examine the evidence file/network capture and the post any comments on what you find.

EnScript Tutorial IV

It has been several weeks since my last EnScript Tutorial, so I decided it was time for the next installment in the EnScript tutorial series.

In the last tutorial, we learned how to recurse through all the evidence in EnCase and select a specific object (file or folder) based on its name matching some specific text. In this tutorial, we will learn how to read data from a file, commonly referred to as File I/O.

In this tutorial, we will recurse through all the evidence to find a file named "boot.ini". Once we find this file, we will open it so we can read specific data from it. We can also bookmark a small portion of the file in the same manner as an examiner may sweep certain text in a file and bookmark only that data. We start with the following basic code:



The third line of code recurses through all the evidence loaded in EnCase in a loop. Line four compares the name of each object to see if the name matches exactly "boot.ini". If the name matches that text, then it writes the full path to the console. When this EnScript is run, we get the following output in the console:

"Case 1\C\boot.ini"

So the EnScript successfully ran, recursed through all the evidence and found one file that has the name of "boot.ini", which is located in the root of the volume named "C".

The next step is to "open" this file so we can read data from inside the file. We first need to create a variable of the proper type to hold a pointer to the file so we can then reference that specific file and perform operations. The proper class type is the EntryFileClass. We need to first create a variable of this class type. To do this we can use the following line of code:

EntryFileClass file();

This creates a variable named "file" that is of the EntryFileClass type. The open and closed parenthesis immediately after the variable name initializes the variable and prepares it to be used. Instead of using the parenthesis, you could create the variable object alternatively using the following code:

EntryFileClass file;
file = new EntryFileClass();

This code alternatively creates a variable named "file" of the EntryFileClass type, but does not initialize it. Then the next line initializes the variable and it can then be used. Either way works, the first example just uses one line of code as opposed to two.

Once we have created the proper variable type and initialized it, we can now use it and open the file we found so we can read data from it. To open the file, there is a member function of the EntryFileClass named "Open" (that's intuitive!). We can use this function to open the file so we can move a pointer around in the file and read data. The following code "opens" the file:

file.Open(entry, 0);

This function accepts two options. The first is an EntryClass object that is a pointer to the file you want to open. Line three above causes the EnScript to recurse through each object and temporarily assigns each object to the variable named "entry". Line four then compares the name property of the entry object to the text "boot.ini". The file.Open function needs to know what EntryFileClass object you wish to open. In this example, since we are using a conditional IF statement, the EnScript will open the "entry" object as long as its name property equals "boot.ini".

The second parameter specifies if you want to open the file with some options, such as include SLACK space, don't treat an erased file as consecutive clusters or if you want to write to the file. This brings up a good point that needs clarification. You cannot write to a file in the evidence file. EnCase does not allow you to alter evidence in any way. The WRITE option is used if you want to open (create) a file on your forensic machine and then write data to it.

Once you open the file, you have to tell EnCase how you want to read data from that file, for example as UNICODE, ANSI, UTF7, etc. To do this, we use the following function, which is a member of the FileClass. If you look at the EnScript Type tab in EnCase and examine the EntryFileClass type, you will notice at the very top it states "inherits:FileClass". This means that this class inherits all the functions and properties that the FileClass has. The FileClass has a member function named SetCodePage. Since EntryFileClass objects inherit functions from the FileClass, you can call this function on a EntryFileClass object. Therefore, the following code can be used to tell EnCase how we want to read the data:

file.SetCodePage(CodePageClass::ANSI);

This tells EnCase we want to read the data as simple ANSI text, one byte at a time, as opposed to UNICODE, which would read two bytes at a time.

When a file is opened for reading, a pointer is created and placed at the very beginning of the file at offset zero. As you read data the pointer moves along through the file so that if you read data again, it knows where to continue from and it won’t read the same data again, unless you explicitly instruct it to do so. Let’s assume we want to only read a specific line in the boot.ini file. If we know where that line is we could move the pointer to where we want to read the data. For example, if we knew that the data we wanted to read started at offset 100, we could use the following function to move the pointer:

file.Seek(100);

This would move the pointer to offset 100 in the file and if we then began reading data, it would start at offset 100. But what if we don't know the offset or it changes dynamically based on the computer system and how it is configured? We could read through the file and then make a decision base don what we read. In this example, we are opening the "boot.ini" file, which is used as part of the boot process on a Windows system to decide if it is capable of multi-booting different operating systems. The boot.ini file I am using in this example looks like the following:



Lets assume we want to read the line of data that specifies what the default boot location is if the user does not specify otherwise at boot time, specifically this line:

"default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS"

One way to accomplish this is to read each line and then decide if its the one we want. In this case, there is some static text in the line we want that can be used to help us identify and decide if its the data we want. We already have the file open and ready to be read. The next step is to begin reading data. We have two options here, we could read one byte at a time or we can read a string of data. In this case, we can read each line and then decide if its the line we want. The following code can be used to accomplish this:

file.ReadString(text, -1, "\x0d\x0a");

This function reads a string of data until a carriage return (0x0d in hex) and line feed (0x0a in hex) are encountered and places the text into the "text" variable. Here is the entire code with comments:



Line 8 opens the file
Line 9 sets the code page to ANSI
Line 10 creates a variable of String type to hold a line of data as we read it
Line 11 enter a DO loop to read one line at a time until the end of the file is reached or until we find the line we are looking for
Line 12 read one line of text and place the data into the "text" variable
Line 13 if the data in the "text" variable contains "default=" then this is the line we are looking for.
Line 14 print the entire line we just found
Line 15 break out of the DO loop since we just found the line we were looking for
Line 18 End of the loop, which we will exit if we have reached the end of the file

If we run this code, we get the following output in the console:

"Case 1\C\boot.ini"
"default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS"

Tthe first line is the result of the first Console.WriteLine statement (line 5). The second line is the result of finding the text we want by checking if the text "default=" is in the string we just read.

The example EnScript can be downloaded here.Please feel free to post questions, comments, complaints or the upcoming winning lottery numbers.