±Forensic Focus Partners

Become an advertising partner

±Your Account


Forgotten password/username?

Site Members:

New Today: 0 Overall: 36783
New Yesterday: 0 Visitors: 158

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

evidence collection methodolgy for forensic investigation

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page Previous  1, 2, 3, 4, 5  Next 

Senior Member

Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 16, 05 20:32

- phius
This is a good discussion & is a subject which is growing in importance. Some excellent points have been made in this thread... however it only serves to highlight that this approach is still in its infancy.

We are developing procedures and methodologies for our investigators & I would like to share some of our findings for comments.

In our experience (probably does not apply to all, but rather will depend on your circumstances) the reasons for live forensics are twofold: Firstly of course in situations where we cannot turn off the target system for business continuity reasons. Secondly and most commonly is where we are investigating malware such as BotNets or live hacking incidents. These cases require live data to be effectively investigated. This includes a traffic capture (normally we use ethereal), transfer of active data (open ports, processes, users logged on, RAM etc etc), followed by the acquisition (or partial acquisition) if necessary.

I 100% agree with this sentiment. There are times when a machine can not be taken down, however if you discover that there is merit in what Robert Rowlingson discusses in the 10 steps to forensic readiness, we can state that if an environment is configured with a model that supports forensic readiness, minimal business impact can be achieved and a business critical machine can be taken off line if necessary. A common occurance for me is responding to an incident where a domain controller has been compromised. Normally, taking down a DC is an "over my dead body" situation, however if a BCP is in place, there are redundant servers in place to step up to take the role of the affected system. Forensic purists typically don't get involved in network architechture, system&network security, BCP/DRP, however, in a corporate-type situation, forensic investigators are looked on to provide a solution to those problems. If a forensic investigator states "I need to take this machine offline immediately" then that forensic investigator should provide an alternate means of keeping the company running. The awful truth is that if the system and network admins followed best practices, those methods would already be in place, and we as investigators could arrive on scene and perform our jobs unimpeded. In addition, if proper NSM is in place ahead of time in an environment, collecting network data has already been done.

None of this is to say there isn't a point in collecting live information. Live data recovery is extremely important, however when it comes to botnets and malware, most of the work to discover the who,what, when, where and why and how of it is done offline in IDA pro, or from another machine where the botnet is penetrated by the investigator to collect evidence and yet another machine that contains sandboxes to investigate how the malware works.

Now, the last point is a key issue. Data transfer rates for live forensics are typically very slow (abt 5GB per hour in our experience) so wherever possible, we will do an aquisition by shutting down a system after the live data has been captured. If not possible to shut down, then we need to selectively copy files or folders. A full live copy is only a very last resort.

We have a large number of investigators with a high workload, and we need to provide straightforward tools to do this job in a standard and automated way as efficiently as possible. I know the purists will shudder at this, but that is reality. We have some programmers working on a possible solution, but we would prefer a methodology that becomes widely accepted and used rather than an in-house one.


Out of curiosity, you state you have a programmer, why not have them code up something that automates this process? It wouldn't take long at all to write something that uses trusted binaries. Of course it all depends on if you investigate *nix machines.  

Senior Member

Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 16, 05 21:04

Boot your acquisition system with HELIX Forensic CD ROM. You can use GRAB to acquire a live system over the network. It took me some time and effort to get comfortable with it but once you have mastered the commands, it is second nature.
I own Prodiscover as well. Depending upon the client's budget and depending on the situation and the investigation, I use Prodiscover and GRAB from HELIX accordingly.
I am currently playing with Symantec Livestate which lets you image over the network as well. I am struggling with the fact that it deploys an agent thus modifying evidence, which I am not comfortable with. But it might work well in private/enterprise/corporate enviornments where you have the agent as a part of the basic image for the workstations and is predeployed. So technically there would be no modification.

Why am I playing with Symantec LiveState? Recently I was hired for a case where the private company suspected that there was some Instant Messenger usage directly from a Windows 2003 Server. The group policy (GPO) enforced on the XP workstation did not allow for instant messenger to run. So how could this be? Because the group policy (GPO) applied on the server was different and did not retrict Instant Messenger. So some smarty pants on 2nd or 3rd shift who must be entirely bored figured he would find a way around it. What he was doing is that he would remote into the server via Dameware Mini Remote Control from his workstation. Started his session and chat away.

I told the client that I need to get a image of the server so I would need 2 - 3 hours downtime. Well, that was not welcomed at all. The server facilitated some reports that remote users ran over VPN, it was also the accounting server with Solomon loaded on it. I noticed (when i was checking in add/remove programs for AIM, Yahoo etc.) that Ghost 9.0 was loaded on the server for some reason. They did not want to spend money on Prodiscover. I chose to use the existing Ghost software to get a live image of the server to my externally connected usb drive.

I was able to acquire the ghost image (sector by sector copy by disabling smart sector copying). When I tried to import it for analysis in Access Data FTK, it was not recognized. But I have discoverd a trick.
I loaded Ghost 9.0 on my forensic workstation. Ghost 9.0 lets me mount the image I acquired as a logical drive. Then I used FTK imager to get a raw image of the mounted ghost image. Hope this works.
It did. I was able to get a raw image from mounted ghost image. I decompressed the raw image to a external usb and made it bootable.
Now I had the server from the image as I would have if I took it down and imaged it locally.

Fruitful end result. I was able to gather evidence without taking the server down. I also successfully finished the analysis and determined the guilty party and case was closed.

Lesson learned.
It is possible to acquire evidence in a forensically sound manner as long as you follow a methodical process even if you are challenged with a enviornment that would challege gathering sound evidence. You cannot expect to walk into any enviornment and expect to gather evidence like every other case. It will vary case by case basis.

PS: I have duplicated this successfully in my lab and am able to reproduce same results. Sorry for the lengthy post. I am not in CHAT MODE like our guilty party was. ;~)  


Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 17, 05 09:17


Paul...I'd greatly appreciate knowing a bit more about who "we" are (in your post you mention "we" several times). Particularly b/c I am very hesitant to use the words "live" and "forensics" together myself, mostly due to the purist stance that live isn't forensics.

Can you specify the live data that you collect from systems, and perhaps even the methodology and order of that data?

"we" simply refers to the organisation that I work for. As for "Live Forensics" as a terminology, I have no desire to get into semantics with you (I have enough arguments with the "purists"in my office). Whilst I will continue to call it that here in my office, if you provide me with alternate terminology I will be delighted to use it to keep you happy Rolling Eyes

OK.... that out of the way, as for the order that we conduct our live <unnamed> this is how we are approaching (Windows) malware investigations at present:

1. Consult Sysadmin if we can use the switch Span port - if so, we plug in an analysis notebook with Ethereal with filters to to sniff the traffic for the target machine. If a busy machine, we will filter out normal traffic. Length of time for sniffing will depend on the circumstances ~ 1/2 - 2 hours is about as much as we can normally afford.

2. If Span port is not available, we plug a hub into the switch and very briefly disconnect the target system before reconnecting it to the switch via the hub. We can then connect the analysis notebook into the hub and sniff traffic as per the above. This is not particularly advisable unless unavoidable as even a couple of seconds break in network traffic could cause data corruption.

We have had good success in following the TCP streams to identify the upstream BotNet controller. As Hogfly rightly points out, this can also be identified by reverse engineering the malware, but by doing the live part you can confirm that it is active and you can also pinpoint the malware - something that may not be so easy on a dead machine.

3. The next step we (currently) use is then to run Helix on the target system and send all the live data (using WFT) to the acquisition machine using Windows shares on a separate hard drive attached to the acquisition machine via firewire.

4. Similar to the above, we then acquire the RAM using Helix

5. At this point there are alot of variables, depending on time available and the case circumstances. Most servers are configured with a small system drive and a large data drive. If that is the case, then we would normally just acquire the system drive as that is where the malware will reside. If we have time to quickly analyse the live data, then we can try to pinpoint the malware and simply extract this.

Now, although I am referring to Helix in the above, as I mentioned in my previous post we are looking at ProDiscoverIR and I have been very impressed with using it in situations involving Windows systems... however, we are still unable to get it to function with Linux systems.

I believe that the ProDiscover model is the way forward for us. Simply inserting the PDServer disk to autorun in the target system is a great method that is easily used by any of our investigators and can be very simply explained. All the analysis is then done on the investigators computer. I particularly like the compare hash function, which allows quick identification of "known" malware or rootkits on a target system.

Ideally, a combination af the nice presentation and detailed analysis of Helix's WFT with ProDiscover's methodology would really suit us.

To Harlan, I have bought your book & it is a good piece of work. However, for reasons stated above, we have not considered using your scripts in actual investigations.

Uh...thanks. But what were the reasons again? I'm curious, as the FSP operates in a manner similar to ProDiscover, collecting data using the FRU and sending it out over a socket to the FSP. I'd be interested to hear your thoughts on why you have not considered using the scripts.

Harlan... The reasons I implied were simplicity. Compare the ready made PDServer disk which our investigators have to do nothing except insert a CDROM and then click commands on the ProDiscover interface to retrieve data - an interface that is quite intuitive and fast and efficient. At the end of the day, that is what we need. I am encouraged to hear that you wll be working with ProDiscover, because the extensive nature and output presentation of your scripts is something that could definitely enhance this tool.

Hogfly... you once again make some good points in your post & wouldn't it just be perfect if every system aministrator was ready for such investigations :D. For the time being though, we will stick to conducting live <unnamed> wherever possible, as this provides us with enough data to investigate most cases, and we use standard operating procedures which can suit most cases - at least until our investigators develop more experience anyway.

As to programming our own tools - we have unsuccessfully been down that road before & have learned some important lessons. Probably the most important being that in legal proceedings it is better to use a tool that many others are using if you want acceptance and an easy life!! real life dictates that wherever possible you avoid discussion/arguments over tool or technique specifics... very sheep-like I know, but once again it is reality!!

Arashiryu... that was a good post. I will try & reproduce some of your methods when I have time!!

Thanks for all the feedback... we have a long way to go before live <unnamed> becomes mature & these discussions are very healthy!! We are certainly open to making changes to please let me know if you think we are going about this the wrong way!!



Last edited by phius on Nov 17, 05 16:13; edited 1 time in total


Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 17, 05 10:23

what you can do is, combining the dd and nc command (from your own cd of course) , and send the drive image over through network to your examination pc. However, your binaries must be able to run in the Unix system of your choice. E.g, Sun or HP-UX  

Senior Member

Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 17, 05 10:46

I would like to propose a term to be used instead of live forensics. Typically, forensics is used as a blanket term for forensic science(purist forensics) and incident response. However, this doesn't encompass what we are discussing which is infact a combination of the two. So, why not call it forensic incident response(TM)?

One of the most lacking areas regarding forensic incident response is a tool that provides correlation of discovered data from a live system. Anyone have ideas on that subject?

As a side note in identifying botnets, an nmap scan that probes the ports of the affected systems helps immensely. Not only will you get a banner response from most, you will get a port signature that can be used to detect other similarly affected systems. In addition, network signatures(like JOIN|NICK etc commands) captured via tools like ngrep help as well.  


Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 17, 05 12:26

Hogfly... I like the Forensic IR name. However, I think the issue that most "purists" have is with the use of the word "Forensic" (although a quick look at dictionary.com shows the definition to be The use of science and technology to investigate and establish facts in criminal or civil courts of law)

I like your idea of running NMap - this information can be correlated with the open port info from the WFT report. As for NGREP, I have to confess that this is the first that I have come across this tool & have just downloaded it to test... thanks for the info


Senior Member

Re: evidence collection methodolgy for forensic investigatio

Post Posted: Nov 17, 05 21:13


One of the most lacking areas regarding forensic incident response is a tool that provides correlation of discovered data from a live system. Anyone have ideas on that subject?

Check out my book. I include a Perl script that correlates collected information, displaying everything in PID-delimited format. This sort of thing is something I haven't seen done anywhere else.


Page 3 of 5
Page Previous  1, 2, 3, 4, 5  Next