±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 36583
New Yesterday: 6 Visitors: 138

±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 Previous  1, 2 
  

skip
Senior Member
 

Re: corpus delecti

Post Posted: Mar 08, 07 21:17

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?  
 
  

skip
Senior Member
 

Re: corpus delecti

Post Posted: Mar 08, 07 21:24

- user24
- skip

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

keydet89
Senior Member
 

Re: corpus delecti

Post Posted: Mar 09, 07 02:39

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

skip
Senior Member
 

Re: corpus delecti

Post Posted: Mar 12, 07 18:16

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

keydet89
Senior Member
 

Re: corpus delecti

Post Posted: Mar 12, 07 18:51

> 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  
 

Page 2 of 2
Page Previous  1, 2