***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.
Thursday, February 28, 2008
***Updated verion 1.1 - Sanity checking on deleted, overwritten files, files with invalid clusters and folders
Friday, February 22, 2008
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
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) =
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)."
Friday, February 15, 2008
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
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
- 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
- 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.
Wednesday, February 13, 2008
**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.
Saturday, February 2, 2008
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: