Join Us!

evidence collection...
 
Notifications
Clear all

evidence collection methodolgy for forensic investigation  

Page 1 / 3
  RSS
ellac
(@ellac)
New Member

Hi all,

I am a student and am new to this community. Currently I am working on a paper which I would like to develop an evidence collection procedure for live forensic investigation. My target audience is small/medium-sized firms where taking the compromised system offline is not possible. This means that evidence collection has to be done while the system is running.

Since small or medium sized firms usually have a very limited IT budgets, I would like to propose a low cost but efficient way to gather evidence.

For this paper, I am only concentrated on UNIX operating system. Any help/suggestion would be greatly appreciated.

Thanks,

Ella

Quote
Posted : 15/11/2005 12:25 am
arashiryu
(@arashiryu)
Active Member

Best comercial product for live system imaging is Prodiscover Investigator. It is around $6000.
http//www.techpathways.com/ProDiscoverIR.htm

Check out the article below for examining 'live' systems.
http//www.informit.com/articles/article.asp?p=417509&rl=1

Also download and try HELIX, F I R E bootable linux distros that have utils to acquire live systems via TCPIP. Grab on the HELIX cd rom works great to acquire a live system.

ReplyQuote
Posted : 15/11/2005 1:07 am
ellac
(@ellac)
New Member

Thanks arashiryu!
The two links are very useful.

For the first one, I am not sure how many small companies are willing to spend 6000 dollars on this kinda of software. However, it allows me to find out what components i need to include on my paper.

I am trying to come up with a how-to guide so that people will know how to respond when they need to collect digital evidence that can be presented to the court if needed.

Thanks again.

Ella

ReplyQuote
Posted : 15/11/2005 1:22 am
arashiryu
(@arashiryu)
Active Member

Here is another one.

http//www.shebeen.com/win32-forensics/

ReplyQuote
Posted : 15/11/2005 1:48 am
andy1500mac
(@andy1500mac)
Member

Hi ellac,

Good article describing incident response as well as some info on the authors batch file …which is simple and handy.

http//www.e-fense.com/helix/Docs/Jesse_Kornblum.pdf

Andrew-

ReplyQuote
Posted : 15/11/2005 2:08 am
fatrabbit
(@fatrabbit)
Active Member

I've just found this article which contains a wealth of information including some first responder guides under the guidelines and standards section.

http//staff.washington.edu/dittrich/forensics.html

ReplyQuote
Posted : 15/11/2005 2:20 am
keydet89
(@keydet89)
Community Legend

While some good info has been posted, I do think that it's important to point out that the original poster (ella) specified Unix as the operating system to be dealt with. This is important, as there are some major differences in how one would conduct live response (either volatile data acquisition or image acquisition) over Windows.

Some important process-oriented concepts to keep in mind include

Locard's Exchange Principle
http//www.profiling.org/journal/vol1_no1/jbp_ed_january2000_1-1.html

RFC 3227 - Guidelines for Evidence Collection and Archiving
http//www.faqs.org/rfcs/rfc3227.html

For the most part, similar principles apply regardless of platform…however, the tools you use to employ your methodology will differ. For example, it is possible to create statically-compiled tools for Unix systems, so that the investigator does not have to rely on possibly subverted libraries on the system.

Interestingly enough, the Forensic Server Project[1], while written on Windows, is in essence platform independent. The server component can be run on any system that supports Perl, and as long as the protocol is followed, platform-specific versions of the First Responder Utility (FRU) can be written in just about any language.

I hope that helps a bit,

Harlan

[1] http//www.windows-ir.com/fsp.html

ReplyQuote
Posted : 15/11/2005 6:26 pm
arashiryu
(@arashiryu)
Active Member

Ella needs to clarify.

Is the machine to be examined a Unix box?

OR

The tools used for the examination are Unix based regardless of what platform the box to be examined is on?

ReplyQuote
Posted : 15/11/2005 7:05 pm
keydet89
(@keydet89)
Community Legend

arashiryu,

Ella needs to clarify.

Is the machine to be examined a Unix box?

OR

The tools used for the examination are Unix based regardless of what platform the box to be examined is on?

Ella's query seemed pretty clear to me…

"My target audience is small/medium-sized firms where taking the compromised system offline is not possible. This means that evidence collection has to be done while the system is running."

As the system needs to be live and running, the use of Unix tools would clearly obviate Windows systems. Even a bootable Linux CD is out of consideration, as for the CD to be used, the system will no longer be live. Also, using Unix tools to examine a Windows image is obviated, for the same reason.

IMHO, the question was pretty clear. After all, ella went on to say, "For this paper, I am only concentrated on UNIX operating system."

Also, ella further stated
"Since small or medium sized firms usually have a very limited IT budgets, I would like to propose a low cost but efficient way to gather evidence. "

Data gathering is easy…even trivial. Should the data need to meet a standard of "evidence", the by it's very nature, the local IT shop shouldn't be collecting it at all.

Either way, collection is the easy part…its always been analysis that's the hardest, and the most often prone to error.

Harlan

ReplyQuote
Posted : 15/11/2005 8:14 pm
ellac
(@ellac)
New Member

I agree that evidence collection is the easiest part in the forensic investigation. That's why i picked that part.

However, I have to make sure whatever procedures i am going to use will gather evidence that can be presented in court.

Thank you everyone. I have got many useful links from you guys. I am sure I will post some questions later. )

ReplyQuote
Posted : 15/11/2005 10:48 pm
arashiryu
(@arashiryu)
Active Member

Good job Harlan. That is why you are a senior member.

I have one question though. You have never ever used a *nix tool to grab an image of a live windows or unix box over the network? This is directly related to evidence collection.

ReplyQuote
Posted : 16/11/2005 12:04 am
hogfly
(@hogfly)
Active Member

From an operational stand point, I would have to say that any small/medium sized business would be best served if a system was taken offline. Consider the small/medium sized company that has an upcoming IPO. During this time frame, some confidential data is leaked through a critical server. The best interest of the company is served if that machine is taken immediately offline rather than attempting a live forensics investigation.
In addition, taking a NY state company that deals in private information(CC# or SSN) for example, they are now bound by notification restrictions, as well as other federal regulations that impose strict business practices if a compromise occurs and sensitive data is at a reasonable risk of unauthorized disclosure. $6000 is a small price to pay when facing a slew of lawsuits, fines and government sanctions.

That said, it's a unix box…dd,cat and netcat is all you need. Following the order of volatility is straightforward, so dumping registers,cache,memory and so on still only requires dd and netcat. A methodical process that is step by step, is easily reproducable, tested and documented should suit your needs as something that is admissable in court.

Looking at products, ATC-NY(Odyssey Research) located in Ithaca sells onlineDFS for roughly $1500 if memory serves me. I can give you a contact name over there if you like, so you can discuss details.

BTW, what school are you attending?

ReplyQuote
Posted : 16/11/2005 2:31 am
phius
(@phius)
Junior Member

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.

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 studied Helix and ProDiscoverIR. Both have their merits. For the capturing of live information about the running system, both do a good job (when dealing with Windows systems). Helix though requires you to issue all commands directly on the target system (albeit through a trusted command shell from the CD), and passes the information either via a Windows share or by using Netcat. On the other hand, ProDiscover simply runs a server autorun CD on the target system which opens a communication port, and the commands are then issued on the investigation system (kind of a SubSeven model!!). In my opinion, the latter approach is probably simpler to explain to a court. In addition, the hash comparison feature in ProDiscover is a very effective means of identifying target files or malware. Helix'big advantage is of course that it is free!!!

ProDiscover is also supposed to work with Linux, but with our limited testing so far we have been unsuccessful in using it. In fairness, we have only started the testing though & it may be due to errors on our part. We seem to be able to make the connection, but the previewing and other commands are not reaching through.

I understand Hogfly's comments about extracting the live information using well documented Linux commands, but this is not a route we want to go down. 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.

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. However, I do like your work and look forward to seeing how it develops.

I know this doesn't exactly address Ellac's original posting, but I hope this thread can be used for a more indepth discussion on this subject. Grateful for your views.

Paul

ReplyQuote
Posted : 16/11/2005 3:27 pm
keydet89
(@keydet89)
Community Legend

arashiryu,

You have never ever used a *nix tool to grab an image of a live windows or unix box over the network?

Nope. I have used ProDiscover to do so. In the case of using bootable Linux CDs, I don't think I'm entirely clear on how one would image a live Windows system over the network…

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 have a large number of investigators with a high workload…

I like the fact that you brought that up. Sometimes the realities escape us in the face of how we feel things should be.

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.

However, I do like your work and look forward to seeing how it develops.

Well, stand by! A lot of my work since the book was published has centered around analysis, and I work with ProDiscover quite a bit.

Harlan

ReplyQuote
Posted : 16/11/2005 4:34 pm
hogfly
(@hogfly)
Active Member

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.

Paul

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.

ReplyQuote
Posted : 16/11/2005 7:32 pm
Page 1 / 3
Share: