SANS Digital Forensics and Incident Response Blog

First forensics work - Part 2: Sure it's big enough ... but look at the location.

So you've managed to calm your nerves some. As we discussed in Part 1 of this series, you managed to collect memory and disk images from computers you could walk up too and touch using Helix. You have external hard drives filling up with images to be looked at. You have been going down the list of systems that you need to image and things are going smoothly.

Until now.

You have discovered, things are slightly more complex for the next system. One of the computers you have to take an image of is located in Seattle.

Nice city. Space Needle webcam is cool. OK weather, if you're a duck. They do call it the Rain City for a reason.

But there is just one small problem.

You are in Cleavland. Why, I'm not sure, but you are. And in Seattle you have an office of 10 people, and nobody there is really technical, and you can't ask anyone there to help out.

First thoughts: Have plane, will travel!

Second thought: Ya right... as if the boss will go for that.

Now you start to think to yourself "How the heck am I going to get that image from Seattle?". How indeeed. The plane thought would be easy, as then you could just use Helix when you get on site. But that would not be the most effective use of your time. So you sit back and take stock of what you have:

  • Is there a network connection between here and there? Yup, a dedicated pipe. Good.
  • Are network accounts used in Seattle? Yup, everyone uses the corporate AD. Good!
  • Do you have a known good source for your tools on a CD? Yup, you have your Forensics 508 course DVD at your desk. Extra good!
  • Can you have a domain administrator account created for you? Yup, you have authorization. Really good!
  • Is there a laptop or stand-alone system you can use? Yup, you have a laptop at your desk. Excellent!

That's about all you need. And, depending on the speed of your links, you may need just a little bit of patience and time.

In order to start imaging on a remote system, I personally like to have a command shell on that system. Is it needed? No, but it's my preference. You could do this through psexec, so choose your own preference.

I start by loading up my 508 DVD in a stand alone system and share out the DVD. I also put in a USB HD on this system and share it. Normally I try to use a laptop that isn't joined to the domain. Why you ask? I prefer this, as domain policies and corporate software can sometimes cause issues , so I like to remove that as a potential source of problems. You also can easily disable any software that you need to on a stand alone system. Not necessarily as easy with a GPO controlled system.

I also prefer a stand alone system for another reason. If needed or I'm concerned about possible infection/compromise on that computer, it gets re-imaged . And it isn't the system I use every day and have all my tools configured on.

After sharing out the drives, I launch a command prompt from the course DVD. This is located in D:\IR\<Windows OS> which is the OS of the system you need to have the command shell on. This is done from an administrator account I have logged into this system with.

After launching the command shell, I then run the cmdenv.bat file that is also on the course DVD. This is a quick batch file that sets up the paths to run only the tools from the DVD and not from the underlying OS. Once I have the command shell on my local system, I run the following command to get a shell on the remote system

psexec —u user —p pass \\remote_ip cmd "/C net use x: \\local_ip\cdrom & x:\ir\<windows OS>\cmd.exe"

  • user the username domain administrator account you had created
  • pass the password of this account
  • remote_ip the IP of the system you wish to have the command shell launched on
  • local_ip the IP of the local computer you are working on and have the DVD shared on
  • <windows OS> the os of the system you are connecting to (e.g. if it is a Windows 2k server, use 2k)

This should open up, barring any problems, a command shell for you. You now are on the remote system, so remember everything you type is leaving a footprint there. I run the cmdenv.bat script within this remote system shell, and then I normally map over the USB HD I shared out from laptop next, by using the net command.

net use z: \local_ip\hd

Now before increasing the footprint much more, I do a memory image with the win32dd.exe or win64dd.exe program, located on the FOR508 DVD as well. To do this, run

win32dd.exe /f z:\memory_image.img

Then you should have appearing across the network, a memory image of the remote system. After this is completed, I then run the dd command to get a copy of the hard disk. Remember though, that you will need to image EACH of the drive mappings (e.g. C:\ D:\ etc) on the system, instead of the entire physical disk. To image and send to the mapped drive you setup, run the following command

dd.exe if=\\.\C: of=Z:\evidence\disk_image.img —cryptsum md5 -verify -cryptout=Z:\evidence\disk_image.md5 -localwrt

This will provide you with a copy of the local C drive, and store it out to your mapped Z drive, give you the MD5 hash of this image file.

After all this, you should have a copy of the memory image and the disk image for the remote system you were accessing. Some things to note with this process

  • The username and password you use with the psexec will be passed over the network in clear text. So I recommend that you create an account that will be used only for this investigation and then disabled. Mike Pilkington goes into more details on psexec and some alternatives in his recent blog posting, so I recommend taking a look at that posting located here. You can also go and read more on the psexec webpage
  • If your company uses personal firewalls or IPS sytems deployed, you may need to either white list the IP you perform your evidence acquisition from or disable these systems. The psexec command, etc. may not be allowed into the remote computer to start your evidence acquisition process. I find that whitelisting a static IP assigned to your IR laptop removes the issue and avoids having to shut down protection measures when you don't have the time.
  • As mentioned in Part 1, make sure you keep excellent notes on what you are doing, what commands you are running and on what systems. You'll need this later on when you are doing analysis.

If none of the above is working, or if you don't have access to the remote at all, then all you can really do is get the hard disk sent to you so you can image it once you have it with a USB to SATA converter (or whatever drive format it is). No you won't have the memory image of the system, but at least you'll have something to work with.

Is this the only way to do this work? Not at all. You could use netcat, Helix with listeners, and probably a dozen other ways. But this is what works for me.

Does your head hurt? Don't worry. This takes time especially if you are just starting out. If you've taken 508, go back and look in your Day 2 book, this is where this is covered.

Next up, Part 3, starting some analysis.

Jonathan works as a Senior Technical Specialist in IT Security for the Canadian federal government. He is a SANS mentor, a GIAC question writer and he holds numerous certifications including GCFA and GWAN. When not working, his spare time is filled by his 3 young daughters.


Posted June 15, 2010 at 2:38 PM | Permalink | Reply


if you obtain images through a psexec shell with a domain admin account over the network, aren't these images regarded as "tainted" from the get-go? You can't prove that you haven't first uploaded "evidence" before taking the image. You also don't have the checksum from the drive you took the image from to prove that it was the original disk and the image is a correct representation of it.
Just a few thoughts ''

Posted June 16, 2010 at 1:03 PM | Permalink | Reply

Dave Hull

Taking images from running systems is acceptable, it may not be perfect, but in some cases, it is the only option. Make a note of it in your investigation. Careful analysis of system artifacts such as file system time stamps, prefetch, registry, etc. can be used to show that no evidence was added to the system. Also for opposing counsel to introduce the idea that the evidence has been tampered with, they have to have actual evidence that supports that claim, the burden is on the party making the claim. The party that collected the evidence has no burden to demonstrate that they didn't taint the evidence.
As soon as the image has been collected from the live system, take a hash of the collected image (md5 or sha-1,256,512). As long as you can demonstrate at the end of your investigation that the hashes still match, you can show that the evidence has not been changed from the time of collection to the time of trial.
Collecting images of live systems is analogous to red light cameras. The cars are moving when the images are taken, yet the evidence is still admitted. Opposing counsel could claim that the photos have been modified, but not unless they have evidence to support that claim.

Posted June 17, 2010 at 1:13 PM | Permalink | Reply


Although theoretically this is sound, the likelihood of successful imaging is not so good.
This presumes that the remote target machine will be running for the length of time required to transfer the data, throughput for the connection is sufficiently high, network does not generate errors, and some carrier will not decide your 100+ GB of streaming data is annoying . . . at the last 2 MBs''
A slightly better solution would be to image memory remotely, then Fedex the laptop for local imaging.

Posted June 17, 2010 at 11:22 PM | Permalink | Reply

Jonathan Risto

I agree that you would not want to stream the data across a network if your connections were on a DSL link, but connectivity out to a remote site that is a dedicated connection of any form (fractional T1 @256k, 512k etc) would work just fine. Yes it could take some time.
Most corporate standard system that I have worked with come with small HD's in them (eg Dell's with 60 GB) which can I feel be handled this way. 60GB over a 768k connection would take under 3 hours if you had the entire pipe'' realistically it would be closer to 5 hours to complete with other traffic on the pipe.
With a dedicated connection, service providers, at least based on my experience working for them here, do not care on the data amounts being pushed through on the dedicated connections. You paid for it, you can use it how you want.
The image memory and Fedex the system locally would work just fine, but the issues I have run into there are:
1) when arriving locally, you need to log into the system with an account that isn't on the system, which on the windows side creates a whole wack of files for that new account. That's a lot of changes on the HD before you get to image it, and a large amount of data that could be lost.
2) HD dead on arrival at your end since it was shipped out.
3) the delay in the time it ends up at your side to even be imaged.
4) having someone send in a laptop alerts them that something is going on, since they were having no problems with the computer. Productivity could also be lost while you are getting a new device out to them.
You could use a connector cable to hook up the drive directly and image that way (avoids the problems in 1) ) which would work as well, and limit the amount of extra items placed on the laptop.
And yes, Cleveland.. I noticed as soon as the post went live, but I am unable to correct things when out of draft or pending state. So my spelling mistake lives on in perpetuity.