Live System Forensics

[Soda_Popinsky]

It wasn't in the OP, but I wanted tools to observe the behavior of an executable. I wasn't very clear on that, sorry.

Short of reverse engineering the file, I was looking for ways to see what parts of the OS were touched so I would know how to clean up.

In my case, I wouldn't be analyzing the entire system, only a binary provided to me. So you folks may be debating about different situations (comprimised system, single file)

[catch]

Nihil, that is what is known as a process with no maturity whatsoever.

cheers,

catch

[Tiger Shark]

Soda:

Did you see this

[donmurdo]

A few thoughts.

First - WFT is a GREAT tool. There isn;'t anything else like it that allows you to collect realtime process data on a system in a forensically sound manner. Secondly, anyone scoffing at WFT OBVIOUSLY hasn't read the configuration file. If you had any idea how much time it takes to defin all of the commands in the config file, to make sure they work, and to find better (and sometimes best) tool that collects a spcific amount of information, then you would know what a valuable tool it is.

Second - anyone scoffing at live system forensics hasn't worked in a preassure cooker like a University where we get whacked boxes frequently. Live forensics allows us to make an inspection and within a half an hour make the "rebuild/remediate" decision w/ some intel. WFT has proven itself amply well over the past year here at my school. So much so that I developed a course for my sfaff on live system forensics, and now I have my job back.

To wrap =>

IF you need a tool, buy Encase and then use WFT.
If you want to know where to look w/ Encase, than run WFT first, else you will spend three days analyzing the system becuse you don't know where to look based on current data.

End of Line.

[Negative]

Foolmoon: 5 messages is starting to sound a whole lot like spam... if you want to do it the right way, submit your link here - that's what it's for.

[phishphreek]

Negative: I think he only posted to two threads here. He posted a total of 5 times on various boards... if I understand correclty. I only saw two posts here...

Both threads that he posted in are relevant. maybe he just didn't know that they would be bumped up to the main page. a new thread would have been appropriate... but whatever. I'm happy that he posted the update here.

[RP305]

Encase has a version for live forensics.

Encase enterprise edition

The general public version is the Enterprise Edition and is used to protect an EnterPrise network.

It is expensive, but works well for documenting rogue processes, rogue ports along with being able to view the true file system. It understands many common filesystems such as NTFS, EXT,HFS, UFS, BSD.

RP

[catch]

anyone scoffing at live system forensics hasn't worked in a preassure cooker like a University where we get whacked boxes frequently. Live forensics allows us to make an inspection and within a half an hour make the "rebuild/remediate" decision w/ some intel. WFT has proven itself amply well over the past year here at my school. So much so that I developed a course for my sfaff on live system forensics, and now I have my job back.

Anyone praising live system forensics is wasting their organization quite a bit of money in training, time, and just all around inefficient system configuration.

At my work, all the desktop systems are set up identically, if a system has a problem it is shut down, a spare preconfigured drive is plugged in and the system is returned to a live status. All in five minutes on the outside.

The other drive can then be analyzed outside the scope of its security policy when time permits. This approach is faster, cheaper, and higher assurance.

cheers,

catch

[nihil]

catch Once again I think your argument is sparked by semantic and terminological differences, at least I certainly hope so

No-one in their right mind is going to leave a suspect compromised machine on their network. Over here, that is what we call the "production environment". It is just the same for a hardware failure, you pull the defective kit from the production environment and replace it. That lets the user get on with what they are supposed to be doing.

As for "live forensics", that would be understood to be a system running in its normal configuration, but obviously not in the production environment. Other approaches would include examining hard drives on a forensics machine or in a lab, decompiling malware, and examining malware induced system changes.

The actual theme of this thread is not about security, it is about tools that let you run malware, and tell you what it tries to do. That is "live" forensics, as opposed to a post mortem, a biopsy rather than a necropsy Obviously all that takes place in a controlled laboratory environment.

[catch]

Nihil, live forensics is by definition on a live system or "a system running in its normal configuration" which is still flawed as it is possible for the security policy (or elements of the user interface for that matter) to interfere with such forensics. This means that in order to ensure a clean system you must perform the forensics on the system in a dead state.

The ONLY reason you'd need to look at a live system is to figure out exactly where the problem was IF you don't have a map of what the system should look like. Having the system baselined beforehand completely removes the need for live forensics and should be used in all production environments.

cheers,

catch