|
Mar 05
2010
|
|
Mar 05
2010
|
|
Jul 07
2009
|
Too often we come across systems that the traditional tools just can’t handle. For example, if you have ever had to deal with a NetApp you know that you can’t just pull out the disks, image them, and then try to rebuild the RAID later. One option when you can’t remove drives is to try and get a shell on the appliance, but many times that is not an option either. When the only documented access to data is through a Microsoft network share, one of the best options is to use Microsoft’s robocopy utility. robocopy allows you to copy files across the network via mapped shares making it a great solution to this ever-growing problem of proprietary network storage systems. And it allows you to maintain time stamps and does its own limited data verification.
Download the Windows Server 2003 resource kit from the following location:
When you install the resource kit, be sure to read the End User License Agreement (EULA) and ensure that your use will not violate the agreement.
Because we are going to write out files directly to another disk and not into a forensic image file format you will need to ensure that you have properly prepared a target drive to store the files on. Prepare your target hard drive by wiping it with the hex pattern \x00 and verifying that the data has been successfully wiped. Once the process of wiping and verification has completed, format the drive with the NTFS file system.
The next step is to turn off or disable all applications that might scan or affect the data that is being written to your target drive. In particular you will want to turn off active scanning of files by your anti-virus software and disable any power saving features, such as allowing the system to turn off hard disks or putting the computer to sleep. The ultimate goal here is to make sure that the process is not interrupted and that the data is transferred in as pristine a state as possible.
The easiest way to copy files from a network drive using robocopy is to first map the drive on the local system. Be sure to keep good notes on how you mapped the drive such as server name, share name, IP address, user name, etc. It is not necessary to record the password to the share, and if you do, it should be changed so it does not pose a security risk to your organization or client.
On your target drive, create a folder named after the server that you are copying the data from. Inside that folder create another folder with the share name. This structure allows you to copy files from multiple shares on the same server preserving relationships and structure.
For this scenario we have mapped the source \\co_fileserver\profiles to drive letter s:\. Our target drive was connected via USB and was automatically assigned drive letter t:\. On our target drive we created the folder structure t:\co_fileserver\profiles for us to point robocopy to.
The following command will copy everything from the source drive s:\ to the target drive path t:\co_fileserver\profiles:
robocopy s:\ t:\co_fileserver\profiles /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE
Here is the breakdown of the options that were used
/E Copy everything including empty directories.
/COPY:DAT Copy the Data, Attributes, and Timestamps of the files and folders.
/R:3 If a file is locked retry copying a total of three times.
/W:3 Wait three seconds between each retry when retrying to copy a file.
/V Provide verbose logging.
/TS Include the timestamps of the files in the log.
/FP Provide the full path of the files in the log.
/NP Do not display progress. This will fill up your log if left out.
/LOG+:t:\co_fileserver\profiles.log Create a log of the activity in the path t:\co_fileserver\profiles.log. The + tells robocopy to append the log. If you leave this out robocopy will overwrite the log if it already exists. By leaving it in you don’t accidentally overwrite any of your previous work.
/TEE Output the progress to the screen as well as the log. This is a good option so you can see that the application is making progress.
You MUST review the log before leaving the site. If there was a file locked open by another user during the copy process, robocopy will fail to copy that file and will log the result. You will have to get the user to release control of the file and rerun robocopy again, this time specifying the file that you want to copy. An example of when you will most likely run into this is with PST files. If a user has Microsoft Outlook open the PST file will be locked because it is being edited. Have the user close the application and retry copying the file again using the same syntax as before, only this time add in the full path to the file. It may require some investigation to determine who has the file open if it is not within a specific users file share.
Search through the log for the following entry: ERROR: RETRY LIMIT EXCEEDED.
Just above this entry you will see what caused the failure. You may also want to search through the log for the word ERROR in general just to be sure there were no other issues.
2009/06/30 17:51:47 ERROR 33 (0x00000021) Copying File s:\suzie\Email\archive.pst
The process cannot access the file because another process has locked a portion of the file.
ERROR: RETRY LIMIT EXCEEDED
Rerun robocopy once you have taken steps to unlock the file, this time you only need to grab the file archive.pst. You can simply do this by putting the filename in after the destination, but this will cause robocopy to rescan the entire drive looking for files named archive.pst that haven’t been copied yet which, depending on the size of the drive you are scanning, could take a while..
robocopy s:\ t:\co_fileserver\profiles archive.pst /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE
robocopy will not recopy a file that already exists, so you don’t have to worry about collisions. The recommended way is to be more specific and put in the full path information for source and destination.
robocopy s:\suzie\Email t:\co_fileserver\profiles\suzie\Email archive.pst /E /COPY:DAT /R:3 /W:3 /V /TS /FP /NP /LOG+:t:\co_fileserver\profiles.log /TEE
Once you have gone through your log and ensured that you have successfully copied all of the failed files then your collection is complete.
The final step
As soon as the copy is complete disconnect the target drive from the computer and reconnect it to your examination workstation via some means of write protection. Fire up EnCase, FTK or your preferred imaging application and preview the drive. Create a logical evidence file of the contents of the drive if possible. Both EnCase and FTK have given us issues when there are large numbers of files, so you may want to create multiple logical evidence files, one for each share. Additionally, you can also create a full disk image such as an EnCase evidence file (E01) for the entire drive and use that for preservation / analysis. This is one of the more critical steps in the process as this becomes the baseline of your collection. Provided you properly wiped the drive before hand, there should not be any data on the drive other than what was copied by robocopy.
|
Jun 18
2009
|
Forensic Imaging of RAM on live Linux systemsPosted by Chris Pavan in RAM, linux, imaging, Forensics, acquisition |
During CEIC this year I had a couple people come up to me and ask how to create an image of RAM on a Linux computer. Recently there have been a lot of tools created that gets the job done in Windows, but there is nothing really out there for Linux.
I created a knowledgebase article that goes into detail on how to handle imaging RAM on a Linux system. I also cover how to use netcat to send the image across the network to a remote computer. The article can be found HERE.
The basic command you are going to run is:
dd if=/dev/mem bs=4096 conv=noerror,sync | tee >evidence.dd | md5sum >evidence.hash
By using tee the data is written out to a file as well as passed down the pipeline so it can be hashed. Once your image completes, run md5sum against the output file and compare that to the hash originally created. If they match you are good to go.
If you want to send the data across the network get netcat listening on your target computer:
nc -l -p 5000 >evidence.dd
On the source computer use the following command:
dd if=/dev/mem bs=4096 conv=noerror,sync | tee >(nc -w 5 target_ipaddress 5000) | md5sum
Make sure you record the MD5 hash value when the process completes and then hash the output on the target computer and compare the two.
There are also some issues with block sizes that you may run across that I cover in the knowledgebase article.
Incidentally, you can do the same thing with disks, just change the device (e.g. /dev/sda) and now you are taking an image of the serial attached hard drive sda. I am working on another KB article that will cover imaging hard drives on live systems with dd.